From paul at prescod.net Tue Jun 1 00:11:01 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:38 2004 Subject: Namespace URI address resources References: <3.0.32.19990531124552.01284c40@pop.intergate.bc.ca> Message-ID: <3752FA19.8AD53D9B@prescod.net> Tim Bray wrote: > > No, that's not a "formal logic" change, that's a huge basic semantic > change. If the IETF had wanted to forbid people using these for > other purposes, they should say so. Okay, fine: "A Uniform Resource Identifier (URI) is a compact string of characters for identifying an abstract or physical resource." Normatively referenced RFC 2396: http://www.faqs.org/rfcs/rfc2396.html You can also read the section that begins "URI are characterized by the following definitions." Paul's Fudamantal Law of URIs (PFLU): If a string does not identify a resource then it not a URI. But we could also just use our common sense here. If someone write a spec that normatively references the XML specification they cannot later say: "Oh, we didn't mean for you to interpret the term 'element' as XML does. In our system, elements are text substitution macros and Note that one of the co-editors > of the URI RFC is one T. Berners-Lee, who among other things signed > off on the namespace spec. That doesn't change the content of either spec. Anyhow, the namespaces spec. is logically complete (AFAIK): why shouldn't he sign off on it? That doesn't mean that we can now use the namespaces spec. as an excuse to defy the URI spec. > Uh, namespace URIs do not designate resources. The namespace spec > is crystal-clear on this. They serve as names, that's all. "An XML namespace is a collection of names, identified by a URI reference." A resource is something identifiable by a URI. Therefore a reasoanble interpretation is that an XML namespace is a resource (an abstract resource) designated by its URI. I'm prepared to write this off to ambiguous wording -- you meant "identified for the purposes of this specification but not for the more general purposes of the World Wide Web." But even so, we can't get around PFLU. Here's another way to think of it: You could argue that the XML namespaces spec does not care about the resource but if the string is a URI then there must be a resource (perhaps abstract). That follows from PFLU. An http: URI is a statement that there exists a resource that can be retrieved using the HTTP protocol: otherwise it isn't a URI but rather just a string that looks like a URI. If it is just a string that looks like a URI then it isn't guaranteed unique. Which isn't good enough for the namespaces spec. So obviously the strings are actually URIs. Which means that they must refer to abstract or concrete resources which (in the case of URL-addressed resources) can be retrieved according to the URL specification. > That analogy is bogus - the semantic of a URL, when used in a web hyperlink, > is well-defined. It doesn't have to be an HTML/XLink hyperlink. I could just have a text file: """ This document conforms to RFC2396 and uses the Appendix E conventions for delimiting URIs. (you cannot use HTTP to fetch this). """ The document is paradoxical. Plus, it is DAMN CONFUSING, just as URL-based namespaces are! > We are not specifying that the namespace URI be used as > anything but a string, for comparison purposes. There is no convincing > evidence that this violates the letter or spirit of any standard > anywhere. -Tim If you wanted it to be just a string then you shouldn't have made normative reference to a specification that defines the syntax and semantics of the string and that requires the existence of http-retrievable resources. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Alabama's constitution is 100 years old, 300 pages long and has more than 600 amendments. Highlights include "Amendment 393: Amendment of Amendment No. 351", "Validation of Laws Regulating Court Costs in Randolph County", "Miscegenation laws", "Bingo Games in Russell County", "Suppression of dueling". - http://www.legislature.state.al.us/ALISHome.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Tue Jun 1 00:35:34 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:12:39 2004 Subject: Namespace URI address resources In-Reply-To: <3752FA19.8AD53D9B@prescod.net> Message-ID: On Mon, 31 May 1999, Paul Prescod wrote: > Tim Bray wrote: > > > > No, that's not a "formal logic" change, that's a huge basic semantic > > change. If the IETF had wanted to forbid people using these for > > other purposes, they should say so. > > Okay, fine: > > "A Uniform Resource Identifier (URI) is a compact string of characters for > identifying an abstract or physical resource." > > Normatively referenced RFC 2396: http://www.faqs.org/rfcs/rfc2396.html > > You can also read the section that begins "URI are characterized by the > following definitions." > > Paul's Fudamantal Law of URIs (PFLU): If a string does not identify a > resource then it not a URI. A string can be 'for' identifying an (abstract or physical) resource without any URI-string to resource bindings currently being in effect. for example, might be a URI whose purpose is to identify an abstract resource which is a set of documents on my server about a specific topic. This seems a reasonable use of an identifier. Seems odd to say that the string stops being a URI for those periods when no documents fall into the appropriate category. BTW this has all been much discussed on the WebDAV WG recently. See archives at http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/ for details, in particular the BIND Proposal thread. In general, I see no problem with a server managing a resource but (at some point in time) there being no generally agreed binding from a URI to that resource. At other points in time there might be several. The would-be-indentifying string remains a URI regardless. If... > "A Uniform Resource Identifier (URI) is a compact string of characters for > identifying an abstract or physical resource." ...read "string of characters _which_ identify an..." the situation would be different. As things stand the definition is about intent, not whether the URI does currently identify any resources. Dan -- Daniel.Brickley@bristol.ac.uk Institute for Learning and Research Technology http://www.ilrt.bris.ac.uk/ University of Bristol, Bristol BS8 1TN, UK. phone:+44(0)117-9287096 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Tue Jun 1 01:34:32 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:12:39 2004 Subject: Paul has volunteered (was Re: Overloaded URIs must GO!) References: <805C62F55FFAD1118D0800805FBB428D0106AE9A@cc20exch2.mobility.com> <14162.43529.767446.988311@localhost.localdomain> Message-ID: <009e01beabbe$40c5e6c0$0300000a@cygnus.uwa.edu.au> > Actually, that's not it. The point is that ordinary people (not just > domain-name owners, or book publishers, etc.) need to be able to > construct Namespace URIs, and those URIs have to be guaranteed unique, > at least at the moment that they construct them. Which is why my idea involves a URI scheme that has a schema-specific part that corresponds to HTTP. What I am suggesting is that if one has the right to http://www.sprynet.com/megginson/MyNamespace then one has the right to: hname://www.sprynet.com/megginson/MyNamespace The only difference is one is explicitly stating in the latter that it is irretrievable. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Tue Jun 1 01:39:43 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:12:39 2004 Subject: Just require URLs References: <805C62F55FFAD1118D0800805FBB428D0106AE97@cc20exch2.mobility.com> <199905311704.MAA06138@rgate2.ricochet.net> Message-ID: <00a101beabbe$f7df6020$0300000a@cygnus.uwa.edu.au> > Turn it around-- it would be intrinsically good to require > all namespaces to reference a retrievable document. But this is what started my whole point. How do you distinguish the "thing" from the "retrievable document"? It isn't so much a problem with namespaces because the "Creator" of a namespace is pretty much going to be the "Creator" of the descriptive document.But consider your example of using: http://isbn.org/isbn/1-57595-180-0B to refer to a book *and* to the MARC record. The "Creator" of the book is the author but the "Creator" of the MARC record probably someone else. But THEY HAVE THE SAME URL! James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cfranks at microsoft.com Tue Jun 1 02:26:29 1999 From: cfranks at microsoft.com (Charles Frankston) Date: Mon Jun 7 17:12:39 2004 Subject: Status of XML-Data Message-ID: As Daniel Veillard has already pointed out, submissions to the W3C are effectively frozen in time and don't get updated or corrected. However, although the XML-Data submission was not revised, work did continue on XML-Data concepts. The XML parser that ships with IE5 supports validation against a schema language that is descended from (and a subset of) XML-Data. See http://msdn.microsoft.com/xml/XMLGuide/schema-overview.asp (bonus points if you can identify the typos there as well). This language has also been used as one of the inputs to the W3C XML Schema work that is currently ongoing. > -----Original Message----- > From: Oliver Becker [mailto:obecker@informatik.hu-berlin.de] > Sent: Monday, May 31, 1999 6:10 AM > To: xml-dev@ic.ac.uk > Subject: Status of XML-Data > > > Hi, > > could anyone tell me the current status of the XML-Data working draft? > http://www.w3.org/TR/1998/NOTE-XML-data/ > > The usage of namespaces is out of date, furthermore I encountered > some bugs/typos, but there's no link to an errata page. > Will the work on XML-Data be continued or is it obsolete and will > be replaced by other working drafts or recommendations? > Does any kind of (free) software exist which checks XML documents > against XML-Data 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 1 04:50:09 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:39 2004 Subject: Paul has volunteered (was Re: Overloaded URIs must GO!) In-Reply-To: <3752CB9E.F8D16B5@prescod.net> Message-ID: <000201beabd8$87924bb0$1b19da18@ne.mediaone.net> Paul Prescod wrote: > > > Jonathan Borden wrote: > > > > A namespace URI does not point to a resource. The URI is used only as a > > unique identifier. > > It does not *need to* point to a resource. But it may. The URI > specification does not say that it must not point to a resource. > Let me clarify. As per the XML namespace specification, the URI is used only as an identifier, the XML namespace specification does not ever use the URI in a way that resolution to a document is at all meaningful. Hence, the fact that the URI may or may not point to a resource is completely irrelevant as far as XML namespaces are concerned. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Tue Jun 1 04:54:13 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:39 2004 Subject: Paul has volunteered (was Re: Overloaded URIs must GO!) In-Reply-To: <3752DD68.A839F1FD@prescod.net> Message-ID: <000301beabd9$1ad76810$1b19da18@ne.mediaone.net> Paul Prescod wrote: > > > Tim Bray wrote: > > > > At 12:47 PM 5/31/99 -0500, Paul Prescod wrote: > > >> > Using HTTP for URIs sounds intrinsically bad to me. ... > > > > >Well, the first problem is that it is wrong: it is in violation of IETF > > >specifications about the semantics of http: URLs. Personally, > I think that > > >standards incompliance should be argument enough. > > > > No. The IETF docs explain how a URI may be used to reference a resource > > on the Web. They further say that URIs are in fact designed to > facilitate > > this process. There is nothing in there I've seen stating that > they *must* > > be so used, nor that they may not be used for other purposes. Or am > > I missing something? -Tim > > I'm talking specifically about the definition of HTTP URLs. > > "The HTTP URL scheme is used to designate Internet resources accessible > using HTTP (HyperText Transfer Protocol)." > > (I guess from a formal logic perspective it should end with "and no > others") > > If you use them to designate non-Internet resources NOT accessible by HTTP > then I consider that an obvious abuse, even if the HTTP spec. isn't > sufficiently anal to disallow the practice from a formal logic > perspective. > I still fail to see what actual, current and/or practical problem this creates with respect to XML namespaces? > > If we take advantage of this formal logic loophole then the elephants can > come barging through. > What elephants will come barging through where and what will they do when they get there? Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Tue Jun 1 05:33:18 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:39 2004 Subject: Just require URLs In-Reply-To: <199905311704.MAA06138@rgate2.ricochet.net> Message-ID: <000c01beabde$94b93e10$1b19da18@ne.mediaone.net> Carl Hage wrote: > I think the URI identifying namespaces and DTDs should be URLs > not URNs. An XML document without retrievable documentation on > the DTD should be considered non-compliant. By definition XML namespace URI's are URNs *not* URLs regardless of which URI scheme/namespace they use. Quoting from RFC 2396 (note that this supercedes the definition of URL!!!): A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network "location"), rather than identifying the resource by name or by some other attribute(s) of that resource. The term "Uniform Resource Name" (URN) refers to the subset of URI that are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable. ... A URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier. That identifier is drawn from one of a set of defined namespaces, each of which has its own set name structure and assignment procedures. The "urn" scheme has been reserved to establish the requirements for a standardized URN namespace, as defined in "URN Syntax" [RFC2141] and its related specifications. Note that when the string "http://www.w3.org/xxx" is used as an XML namespace URI this is a URN not a URL by definition (the scheme remains "http"). Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jackandgina at mindspring.com Tue Jun 1 05:45:32 1999 From: jackandgina at mindspring.com (jackandgina@mindspring.com) Date: Mon Jun 7 17:12:40 2004 Subject: A Proposal for Refactoring SAX References: <000801bea783$06a3b920$ab20268a@pc-lrd.bath.ac.uk> <14156.24493.914825.911719@localhost.localdomain> Message-ID: <37535A47.1D3F2492@mindspring.com> I was initially frustrated with SAX's lack of support for accessing the DTD. Unlike the other XML efforts (XSchema, XSL, etc.) DTDs are not written as XML and it would be nice to access the DTD's internals as well as. I've come to understand you point about SAX being low level, but I'm still not sure I agree with it to the point of excluding DTD handling. So I'm rolling my own library for DTDs similarly to the way SAX is meant for the actual xml documents. Regards, Jack Bolles ThoughtWorks, LLC David Megginson wrote: > ... > By the way, how many SAX implementors have ever used the SAX 1.0 > DTDHandler interface in a real-world installation? The XML 1.0 spec > requires processors to report the information in that interface, but > I'd be very interested to know about actual usage patterns. > > All the best, > > David xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jun 1 06:34:04 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:40 2004 Subject: Namespace URI address resources References: Message-ID: <3753597E.6B5C8E02@prescod.net> Dan Brickley wrote: > > A string can be 'for' identifying an (abstract or physical) resource > without any URI-string to resource bindings currently being in effect. According to RFC 2396, A URI is a sequence of characters with a restricted syntax that can act as a reference to something that has identity. If the something doesn't exist then it cannot and is thus not a URI. > for > example, might be a URI whose purpose is to identify an abstract > resource which is a set of documents on my server about a specific > topic. This seems a reasonable use of an identifier. Seems odd to say > that the string stops being a URI for those periods when no documents > fall into the appropriate category. The abstract resource is a list which is current empty. There is no problem here. In HyTime terms the result of your query is the empty nodelist. In SQL terms it is an empty recordset. That's not the same as not referring to *anything* which is what some people are claiming about namespace URIs. > In general, I see no problem with a server managing a resource but (at > some point in time) there being no generally agreed binding from a URI > to that resource. At other points in time there might be several. No, there can be only one resource identified by a URI. It may be a list-y resource but it is a single resource. > ...read "string of characters _which_ identify an..." the situation > would be different. As things stand the definition is about intent, not > whether the URI does currently identify any resources. Even so it would be wrong to use an HTTP URL without intent to point to something which is retrievable by HTTP. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jun 1 06:34:01 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:40 2004 Subject: Paul has volunteered (was Re: Overloaded URIs must GO!) References: <000201beabd8$87924bb0$1b19da18@ne.mediaone.net> Message-ID: <37535C58.3B445A5F@prescod.net> Jonathan Borden wrote: > > > Let me clarify. As per the XML namespace specification, the URI is used > only as an identifier, the XML namespace specification does not ever use the > URI in a way that resolution to a document is at all meaningful. Hence, the > fact that the URI may or may not point to a resource is completely > irrelevant as far as XML namespaces are concerned. I agree 100%. According to the intention of the namespace specification editors the fact that a URI *must* point to a resource is not relevant to the namespaces spec despite some ambiguous wording that might make it seem that it did. But there are specifications being built on top of the namespaces specification that make use of the URI. These specifications are not right or wrong -- the namespace spec is silent about what happens if you dereference the URI. When these specifications are deployed, software will attempt to dereference namespace URIs. That software will not know whether to report inaccessible URLs as errors or retry on the hope that it is available now or merely assume that that namespace doesn't have an associated document. Do we report an error or merely continue? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jun 1 06:44:40 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:40 2004 Subject: Just require URLs References: <000c01beabde$94b93e10$1b19da18@ne.mediaone.net> Message-ID: <37536142.203BB28A@prescod.net> Jonathan Borden wrote: > > Note that when the string "http://www.w3.org/xxx" is used as an XML > namespace URI this is a URN not a URL by definition (the scheme remains > "http"). That string is not syntactically a URN. Please see RFC 2141. It is quite explicit: All URNs have the following syntax (phrases enclosed in quotes are REQUIRED): ::= "urn:" ":" If I'm right on this issue (and what room is there for dispute) and you are right that it cannot be interpreted as a URL in the context that we are discussing (more subtle but still, I think right) then you must agree with me that this is not a URI *of any sort* and thus in violation of the namespaces specification which is both clear and consistent in this regard. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jun 1 06:45:01 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:40 2004 Subject: Paul has volunteered (was Re: Overloaded URIs must GO!) References: <3.0.32.19990531110744.00a04410@pop.intergate.bc.ca> <3752DD68.A839F1FD@prescod.net> <14162.64310.589514.658642@localhost.localdomain> Message-ID: <37535FAC.226B362B@prescod.net> David Megginson wrote: > > In the case of namespace URIs, we're looking at a different use domain > (naming XML elements and attributes), not just a logical loophole. If a spec makes a normative reference to XML then it gets whatever semantics are embedded in the XML specification. If the infoset was part of XML as it may be one day then they would get those semantics. And if there is an entity reference then they can't complain if a parser for their app makes a network transaction to resolve the entity. If they wanted to use only the syntax and override all or some of the semantics (e.g. ignore entity references) then they could do that. But the namespaces spec builds on the semantics of URIs -- it is the very semantics of URIs that make them unique. Without those semantics I could build an http://www.megginson.com/foo namespace URI without impunity. "It's just a damn string", I would cry, "ignore what the URL spec. says it means!" -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From guy-murphy at easynet.co.uk Tue Jun 1 07:18:10 1999 From: guy-murphy at easynet.co.uk (Guy Murphy) Date: Mon Jun 7 17:12:40 2004 Subject: Using XLink for locator grouping.... Message-ID: <001701beabee$1e366500$e579fea9@fusax> Hi. I am interested int he opinion of anyone interested. Then I got to thinking, that maybe the following might be more appropriate, in that it is more descriptive.... All the anchors specified are related in that they are all participating resources. Within the context of this content model however, they do not have any relationship between each other. Does anybody have strong feelings on this matter? Any opinions would be greatly appreciated as to date I've only looked at XLink for gathering reources for presentation, such as bringing together XML documents and XSL stylesheets for transformation and presentation. Cheers Guy xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From branjan at wipinfo.soft.net Tue Jun 1 07:35:33 1999 From: branjan at wipinfo.soft.net (Balaji Ranjan) Date: Mon Jun 7 17:12:40 2004 Subject: A Proposal for Refactoring SAX In-Reply-To: <37535A47.1D3F2492@mindspring.com> Message-ID: hi, is it possible to access the DTD structure using DOM api. thanks in advance balaji ranjan On Mon, 31 May 1999 jackandgina@mindspring.com wrote: > I was initially frustrated with SAX's lack of support for accessing the DTD. Unlike the other > XML efforts (XSchema, XSL, etc.) DTDs are not written as XML and it would be nice to access > the DTD's internals as well as. I've come to understand you point about SAX being low level, > but I'm still not sure I agree with it to the point of excluding DTD handling. > > So I'm rolling my own library for DTDs similarly to the way SAX is meant for the actual xml > documents. > > Regards, > > Jack Bolles > ThoughtWorks, LLC > > > David Megginson wrote: > > > ... > > By the way, how many SAX implementors have ever used the SAX 1.0 > > DTDHandler interface in a real-world installation? The XML 1.0 spec > > requires processors to report the information in that interface, but > > I'd be very interested to know about actual usage patterns. > > > > All the best, > > > > David > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From francis at redrice.com Tue Jun 1 12:57:58 1999 From: francis at redrice.com (francis) Date: Mon Jun 7 17:12:40 2004 Subject: Status of XML-Data References: <199905311309.PAA19546@mail.informatik.hu-berlin.de> Message-ID: <3753BC5E.94F83653@redrice.com> Hi Oliver, Oliver Becker wrote: > Does any kind of (free) software exist which checks XML documents > against XML-Data DTDs? IE 5 includes support for validating XML documents against a subset of XML-Data Schemas. For the rest of us, I am right now writing a partial meta-validator for xml Schema [1] in XSLT [2], along the lines I suggested in an earlier note [3]. When run against an xml Schema schema, it generates an XSLT validator for validating the structural content of an XML document against the constraints of the original schema. (xml Schema also supports data typing of individual elements but that will need RegExps in the XSLT processor at the very least.) I've switched from IE5 as my target XSLT processor to James Clark's XT [4], which will actually run code snippets straight from the XSLT WD - the benefit to us of making him the editor. Incidentally the use of XSLT as a meta language to generate XSLT seems to me to pass the Leventhal challenge [5], in that I doubt it could be done as cleanly, compactly or effectively in, say, javaScript (though it certainly *could* be done - javaScript's OO features are wonderfully over-powered for use as a scripting language). Thanks - Francis. [1] xml Schema - http://www.w3.org/TR/xmlschema-1/ [2] XSL Transformations (XSLT) - http://www.w3.org/TR/WD-xslt/ [3] generating XSL validators - http://www.redrice.com/ci/generatingXslValidators.html [4] James Clarks' XT - http://www.jclark.com/xml/xt.html [5] the Leventhal challenge - http://www.xml.com/xml/pub/1999/05/xsl/xslconsidered_1.html -- Francis Norton. Air Rage - a "flight *and* fight" reaction? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Tue Jun 1 13:12:35 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:40 2004 Subject: Namespace URI address resources In-Reply-To: <3753597E.6B5C8E02@prescod.net> Message-ID: Hi Paul, Paul said: According to RFC 2396, A URI is a sequence of characters with a restricted syntax that can act as a reference to something that has identity. If the something doesn't exist then it cannot and is thus not a URI. Didier says: Exactly. A URI represent something. It is a U_niform R_esource I_dentifier. It provides identitity to a resource. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Tue Jun 1 13:12:00 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:40 2004 Subject: Just require URLs In-Reply-To: <000c01beabde$94b93e10$1b19da18@ne.mediaone.net> Message-ID: Hi Jonathan, Jonathan said: Note that when the string "http://www.w3.org/xxx" is used as an XML namespace URI this is a URN not a URL by definition (the scheme remains "http"). Didier says: Not exactly. The string http://www3.org/xxx cannot be considered a URN it is a URL based on the HTTP scheme. The example below is a URN: urn:tns:ZDNet:Magazines:InternetWorld To be qualified as a URN the string should be structured as follow: urn:: :: Name space identifier :: any string constructed as defined in RFC 2141 (some characters like "/" needs to be encoded for resolution but not for human display) To see the difference let's take LDAP. URL---> LDAP://ldap.itd.umich.edu/c=us URN---> urn:ldap:c=us In a URN we tend not to include a domain name witch is absolutely required for URL but not for URN. In fact, to include a location dependent context in a name jeopardize the permanency requirement. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jun 1 15:14:41 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:40 2004 Subject: A Proposal for Refactoring SAX In-Reply-To: <37535A47.1D3F2492@mindspring.com> References: <000801bea783$06a3b920$ab20268a@pc-lrd.bath.ac.uk> <14156.24493.914825.911719@localhost.localdomain> <37535A47.1D3F2492@mindspring.com> Message-ID: <14163.56538.209965.327529@localhost.localdomain> jackandgina@mindspring.com writes: > I was initially frustrated with SAX's lack of support for accessing > the DTD. Unlike the other XML efforts (XSchema, XSL, etc.) DTDs are > not written as XML and it would be nice to access the DTD's > internals as well as. I've come to understand you point about SAX > being low level, but I'm still not sure I agree with it to the > point of excluding DTD handling. > > So I'm rolling my own library for DTDs similarly to the way SAX is > meant for the actual xml documents. That's a great idea, and SAX2 will support such extensions itself, if you want. I should mention, however, that we have discussed adding some further DTD support to SAX2 in the form of optional handlers set using the SAX2 setProperty() method. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Tue Jun 1 15:26:07 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:40 2004 Subject: Just require URLs Message-ID: <02ad01beac31$671a1490$0b2e249b@fileroom.Synapse> Paul Prescod wrote: >Jonathan Borden wrote: >> > >> Note that when the string "http://www.w3.org/xxx" is used as an XML >> namespace URI this is a URN not a URL by definition (the scheme remains >> "http"). > >That string is not syntactically a URN. Please see RFC 2141. It is quite >explicit: > >All URNs have the following syntax (phrases enclosed in quotes are >REQUIRED): > > ::= "urn:" ":" > >If I'm right on this issue (and what room is there for dispute) and you >are right that it cannot be interpreted as a URL in the context that we >are discussing (more subtle but still, I think right) then you must agree >with me that this is not a URI *of any sort* and thus in violation of the >namespaces specification which is both clear and consistent in this >regard. > My reading of RFC 2396 suggests that the intention is to supercede the definitions of both URLs and URNs. Interestingly 2396 defines 'resource' as either an abstract or physical entity, an example of an abstract entity would be a namespace. A physical resource would be a document. What is not explicitly specified is whether the same URI may 'point' or name 2 separate resources, 1) an abstract resource e.g. namespace, property etc, and at the same time 2) a physical resource e.g. schema document. Clearly however, when used in XML namespaces and if the namespace URI *does* point to a schema document (this is outside the namespace spec) the URI does denote 2 distinct resources. Under the definition of URN in 2396, a URN is any URI whose intention is to reference an abstract resource, act primarily as a name, and/or not be retrievable via a network. Under the definition in 2396, "urn" defines a scheme/namespace (URI namespace) whose intention is to serve *only* for URNs, however the spec suggests that any scheme e.g. "http" can serve to define a URN, given the definition of URN in 2396 (part of which my earlier message quotes). So, my reading of RFC 2396 and the XML namespace spec leads me to conclude that all URIs used as XML namespaces are properly URNs regardless of the URI scheme prefix. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Tue Jun 1 15:37:06 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:40 2004 Subject: Namespace URI address resources Message-ID: <02b701beac32$f129bfe0$0b2e249b@fileroom.Synapse> Didier PH Martin wrote: >Hi Paul, > >Paul said: >According to RFC 2396, A URI is a sequence of characters with a restricted >syntax that can act as a reference to something that has identity. If the >something doesn't exist then it cannot and is thus not a URI. > >Didier says: >Exactly. A URI represent something. It is a U_niform R_esource I_dentifier. >It provides identitity to a resource. > Yes but 'existence' can mean abstract existence, i.e. existence as a concept or existence as a name. Hence any syntactically legal URI when used only as a name, identifies a resource. This abstract resource is the name itself. Under this definition of resource (explicit per RFC 2396) I completely agree that every URI identifies a resource. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jun 1 16:52:07 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:40 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java Message-ID: <14163.61975.304542.267110@localhost.localdomain> There is an alpha version of SAX2 for Java available for download from http://www.megginson.com/SAX/SAX2/ Be warned that this is very early, and that everything is subject to change. I'd like to thank everyone on this list for their input, and I hope that all contributors will see at least some of their suggestions implemented (even if they're annoyed that others have been passed over). You also need the SAX 1.0 distribution to use SAX2. SAX2 does not replace SAX 1.0, but it does augment it by adding additional functionality for those who want it; for now, the feature/property setting and discovery is being handled through a separate interface. People are encouraged to start supporting SAX2, but SAX 1.0 implementations will not become obsolete. Here's what's in the SAX2 core: * package org.xml.sax - interface Configurable - class SAXNotSupportedException (extends SAXException) - class SAXNotRecognizedException (extends SAXNotSupportedException) * package org.xml.sax.misc - interface DeclHandler - interface LexicalHandler - interface NamespaceHandler * package org.xml.sax.helpers - class ConfigurableParserAdapter (implements Parser, Configurable) I've also hacked together a simple SAX2 wrapper for Microstar's AElfred SAX 1.0 driver, which more-or-less correctly reports what features are available (such as external entity expansion) and unavailable (such as validation). It is available through a separate download. Note that even SAX2 parsers are free not to implement any or all of the core features and properties. Thanks, and all the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Tue Jun 1 18:05:22 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:12:41 2004 Subject: XML Inclusion Proposal In-Reply-To: <374F3305.886A2B5B@prescod.net> Message-ID: <3.0.1.32.19990601120415.00e6c820@tiac.net> > XML Node Inclusion Mechanism > ============================ As it happens, I've been working on an application which fits the definition for "XML Processor" and have been thinking about inclusion. So this is quite timely, and I might even volunteer to be among the first to implement it in a real application! ;) An interesting philosophical question, first: if I make this inclusion mechanism available to authors of documents in my XML conformant language (which is not, I expect, a language which will be useful to any XML processor other than my own), would it be reasonable to omit support for general entity references? I have no need for validation at the processing end (that should be done at the editing/creation end of my system process), so I've had no need up to this point to bother reading the external DTD subset in my processor. Your proposed inclusion mechanism is SO MUCH simpler than doing the same thing in an external DTD subset; I know that my authors would prefer to use that. So, this question in a nutshell: If I implement this proposal, I don't need to implement support for general entities in external DTD subsets -- should I do so anyway, or are we really on a path toward letting them wither and die? Question 2: I think I understand your intent, but just to be sure: what do you *expect* the included document to look like? Does it start with: Would you expect it to have a DOCTYPE, or not? Since you used the word "text" I suppose you might have been implying that the included stuff isn't XML at all, but rather is just plain text, however the linking bit leads me to believe that this is not the case. I suspect I could just make my own rules for my authors (e.g., the included document must be well formed, must not includes a doctype, etc.), but I was wondering if you had a particular set of conventions in mind. In particular, a well formed document has only one root node, which might be kind of inconvenient in a lot of cases (take your copyright example: I might want to always include both a blahblah and if I require that the included doc is well formed, I'd have to wrap those together, right?). Question 3: I'm not familiar enough with the XLink/XPointer specs to understand this part: >Source Anchor: > >The source anchor may be identified as an anchor described in a locator >with the role "source". It must address a single node in the same >document as the link. If an inline link has no locator named "source", >then the local resource serves as the source anchor. > >Target Anchor: > >The target anchor may be identified by a locator with the role >"content". If the link has no such locator but it has only one single >remote resource then that resource may be used as the content anchor. Can you give examples of each kind of inclusion this can lead to? I'm having a lot of trouble with understanding what these two paragraphs mean, exactly. Does this mean that I can include some miscellaneous nodes buried in the included document? For example, can I have a document license.xml with various licenses, and then include the one in particular that I need by using these anchors? How would that look? Sorry if these are dumb questions in the context of XLink/XPointer history, but I'm not really familiar with any of that... -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 1 18:53:38 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:41 2004 Subject: Web Resource Identity References: <374EAFCB.249F2955@prescod.net> Message-ID: <37541066.A134E03E@locke.ccil.org> Paul Prescod wrote: > In the HyTime and object oriented > worlds, I believe that the defining characteristic of things with identity > is that you can take two references and determine if they refer to the > same object. This may be feasible in closed-world scenarios. In the Real (i.e. open) World, identity may be a very hard problem! It took the ancient Greeks centuries to figure out that Hesperos (the Evening Star) and Phosphoros (the Morning Star) were the same object, what we call "the planet Venus". Another famous example: Tully and Cicero are the same man, "but it is neither trivial to say so nor absurd to doubt it". (Saul Kripke, _Naming and Necessity_) On the other hand, we have the equally classical problem of "the ship of Theseus", preserved at ancient Athens. Eventually every atom of it was replaced, but its *identity* remained the same. > How do we know, other than common sense? Right now we don't. But RDF can easily handle the question by defining a property "canonicalURI": note that this might, perhaps even should, be an URN rather than an URL. > This is more disturbing. It makes robust, scalable hypertext linking > essentially impossible. Consider it from an RDF point of view. If I use > RDF to attach a hundred properties to one URL and someone else uses it to > attach a hundred properties to another one then our property groupings > cannot be merged. They can, but only if RDF has a notion of the identity relationship. Right now it doesn't, but such a thing can and should be built. RDF, after all, expresses properties of resources, not URIs, even though it uses URIs to refer to resources, > The only solution, if we assume a one to one correspondence between URLs > and objects is to have EVERY NON-CANONICAL name for the object explicitly > do a redirect to the canonical name. This need not, probably should not, be done at the protocol level (it would make mirrors pointless) but rather at the RDF level. > I believe that the Web needs a concept of a canonical URL, if it doesn't > already have one. Agreed, except that "canonical URI" is more like it; you implicitly accept this below by talking of UUIDs. > Retrieving a document or the HEAD for the document > should describe the canonical URL. That's plausible, especially if you store RDF metadata in the head. (What "head" means in general for non-HTML is a question.) -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Tue Jun 1 19:24:04 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:41 2004 Subject: Paul has volunteered (was Re: Overloaded URIs must GO!) Message-ID: <036101beac52$9811ed40$0b2e249b@fileroom.Synapse> Paul Prescod wrote: > >But there are specifications being built on top of the namespaces >specification that make use of the URI. These specifications are not right >or wrong -- the namespace spec is silent about what happens if you >dereference the URI. > >When these specifications are deployed, software will attempt to >dereference namespace URIs. That software will not know whether to report >inaccessible URLs as errors or retry on the hope that it is available now >or merely assume that that namespace doesn't have an associated document. >Do we report an error or merely continue? This is a very difficult problem without an easy solution. This problem will arise with most data whose lifespan is expected to be long. Short term problems include network outages as well as firewall issues. Longer term problems include changes in DNS ownership. Still longer term problems include changes in network protocols (i.e. when http becomes a legacy and/or unsupported protocol). The only good solution to this problem is to keep schemas/DTDs together with documents and not depend on any network protocol. URNs aren't a solution to this problem, because URN's don't allow dereferencing (otherwise they become another type of URL). Wouldn't it also be an error to attempt to dereference "urn:xxx..."? Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From carl at chage.com Tue Jun 1 19:27:06 1999 From: carl at chage.com (Carl Hage) Date: Mon Jun 7 17:12:41 2004 Subject: Just require URLs In-Reply-To: <000c01beabde$94b93e10$1b19da18@ne.mediaone.net> References: <199905311704.MAA06138@rgate2.ricochet.net> Message-ID: <199906011729.MAA27012@rgate2.ricochet.net> From: "Jonathan Borden" > By definition XML namespace URI's are URNs *not* URLs regardless of which > URI scheme/namespace they use. A URL can be a URN if the creator declares it to remain unique. From: "Mark D. Anderson" > But it would be great if there were a standard that also > allowed for greater precision, so that one could distinguish > the notions of: > - a URN > - a dtd or xml schema > - an english spec > - a document describing rights for some TBD rights protocol It's hard to tell if a URL has the intent to be permanent (is a URN), though if it is used in a context requiring a URN, one should assume it is. A META or LINK tag on an HTML document could declare a URL to be permanent. (In case of a redirect or access via mirror, the original URI must be stored in the retrieved document.) Using HTTP, a language specification and MIME type can be selected in a request (with the Accept). If the URI lead to an HTML document with a human-readable title page, the tag could identify the DTD, Schema, Copyright, alternative languages, etc. A could identify that page as a URI for use in an xml DTD. The HTTP server could return an HTML document for a namespace URI unless an Accept was received indicating XML, where an XML document could contain all the metadata encoded in XML. (Maybe in RDF). Such a scheme could provide all and more capabilities than a non- retrivable URN, plus is backwards compatible with browsers and search tools. From: "Didier PH Martin" > Why should URN usage for name space identification shouldn't > be used? Do you have a good argument against it? If so, let's > share it. I have an argument against URLs: location dependency. URLs are location independent via DNS and/or redirection. An unretrievable URN is location nonexistant. If you use a DTD in spam.org, your software deserves to fail. Instead of using some top-level IANA "urn: my:spam/carl.dtd", an http URI-space can be used with an http server behind it to receive queries. For example, "http://urn.xml.org/my/spam/carl.dtd" could act as a URN/URL registrant and redirect the /my paths to somewhere else, or return a filed document. I suspect www.cpan.org is more permanent than arbitrary IANA name registrations. URLs are permanent, persistent, non-reusable, and location- independent as long as the creator maintains it to be so. Anyone can create a URN registry based on http (e.g. purl.org). That doesn't mean people won't violate the URN requirements. We'd need an XML Crimes Tribunal in the Hague to fix that. From: Paul Prescod > urn:urn-:: [ : ] With the IANA URN scheme, it is not possible to retrieve anything given the URI unless you customize your software for each URN registrant. However, IANA could create an http URI space which could at least return the name of the registrant, and usually something better. The urn above can be converted into http://urn.iana.org/::: in order to make it useful. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Tue Jun 1 21:26:41 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:41 2004 Subject: Just require URLs In-Reply-To: <199906011729.MAA27012@rgate2.ricochet.net> Message-ID: Hi Carl, Carl said: A URL can be a URN if the creator declares it to remain unique. Didier says: False, it also as to conform to RFC2141 specs. Actually (until the next URN RFC) a HTTP URL cannot be considered as a valid URN for several reasons: a) non encoding of "/" b) no "urn" identifier at the beginning of the name. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Tue Jun 1 21:26:40 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:41 2004 Subject: Just require URLs In-Reply-To: <02ad01beac31$671a1490$0b2e249b@fileroom.Synapse> Message-ID: Hi Jonathan, Jonathan said: Under the definition of URN in 2396, a URN is any URI whose intention is to reference an abstract resource, act primarily as a name, and/or not be retrievable via a network. Under the definition in 2396, "urn" defines a scheme/namespace (URI namespace) whose intention is to serve *only* for URNs, however the spec suggests that any scheme e.g. "http" can serve to define a URN, given the definition of URN in 2396 (part of which my earlier message quotes). So, my reading of RFC 2396 and the XML namespace spec leads me to conclude that all URIs used as XML namespaces are properly URNs regardless of the URI scheme prefix. Didier says: This is not what RFC 2396 says. You are right when you say that a URI coudl be a URL or a URN. However a HTTP scheme cannot be considered as a URN because it is already part of the URL space. If however you create a name space having as NID "HTTP" then yes this would be a URN. However each "/" would have to be encoded. Thus, a URN cannot be with "/" as delimiters. Obviously we'll have to create a new RFC for hierarchical name spaces having "/" as delimiters but actually you would have to encode each "/". Thus your name space would look like: urn:http:domain.com%(hex for /)context%(hex for /)etc... The above URN confor to RFC 2141 specs. However the URL: http://domain.com/context/etc... do not conform to RFC 2141 and thus cannot be said to be a URN. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jlangdon at copeland.com Tue Jun 1 22:38:55 1999 From: jlangdon at copeland.com (Jeff Langdon) Date: Mon Jun 7 17:12:41 2004 Subject: Just require URLs Message-ID: <85256783.0071498C.00@mail.copeland.com> Is there a central repository for all RFC specs?? Carl said: A URL can be a URN if the creator declares it to remain unique. Didier says: False, it also as to conform to RFC2141 specs. Actually (until the next URN RFC) a HTTP URL cannot be considered as a valid URN for several reasons: a) non encoding of "/" b) no "urn" identifier at the beginning of the name. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Tue Jun 1 23:18:53 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:12:41 2004 Subject: How to create a new document with a DocumentType node (DTD) In-Reply-To: <30649320C177D111ADEC00A024E9F2971D230B@exchange-server.dega.com> (message from Ed Howland on Tue, 25 May 1999 12:49:27 -0700) References: <30649320C177D111ADEC00A024E9F2971D230B@exchange-server.dega.com> Message-ID: <199906011622.LAA01177@bruno.techno.com> > We got stuck. I know the DOM level 1 spec says that editing > DocumntType nodes is verboten, but can't you create one somehow for > new documents. What if you are writing an up translator, say from a > database and want to make it a valid document, by including either a > DTD URI or the complete DOCTYPE entry. What are we missing here? Please contact me, if you like, for a demo of GroveMinder, which can provide access to XML documents, including every aspect of their DTDs, as if they were SGML documents, according to the ISO-standard SGML Property Set, which was one of the inputs to the design of the (less comprehensive) DOM. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Tue Jun 1 23:20:00 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:12:41 2004 Subject: Groves? Please ::choke::.. In-Reply-To: <000701bea8d5$bcfdc280$e046fea9@fusax> (guy-murphy@easynet.co.uk) References: <000701bea8d5$bcfdc280$e046fea9@fusax> Message-ID: <199906012102.QAA01292@bruno.techno.com> > What exactly are "groves"? > > The clearest def I could get of them... > > [QUOTE] > Groves are the abstract representation of an underlying notation and the > in-memory realisation is constructed using a notation processor, for example > the grove for an SGML instance is built by the SGML notation processor. > [QUOTE] > > Now up until the last bit this sounds like DOM. Are groves just an object > model? > > Oh and if anybody reading this is responsible for writting HyTime > documentation... come the revolution you'll be among the first put against > the wall and shot!... right after those people at the ISO. > > Goodnight I'll try to remember to bring two blindfolds for myself, one for each of my well-deserved executions. Yes, the grove paradigm is an object model, while the DOM is not an object model, despite its name. If the DOM had been rigorously built on a formal definition of the information set of XML, then a document that was accessed via the DOM would be a grove. I'll try this another way: Assuming that we have a grove of an XML document, putting a DOM-conforming API layer over it is a trivial matter. And a third way: The DOM is only for XML. Groves, on the other hand, can be built according to any valid property set, not just the XML property set. Making everything accessible as a grove makes everything addressable, which is the secret of HyTime's claim that, via the grove paradigm, everything, anywhere, anytime, is addressable in any convenient terms. The "convenient terms" are selected when the property set is written. If anybody really wants to understand groves at a visceral level, they should ask me for a copy of the GroveMinder demo. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Tue Jun 1 23:19:03 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:12:41 2004 Subject: Lotsa laughs In-Reply-To: References: Message-ID: <199906011641.LAA01181@bruno.techno.com> [Didier:] > The DTD problem and document validation is only part of the problem > and we are actually facing a lot of issues to be resolved in order > that all parties recognize that a transaction is valid. XML.org, > resetta.net, eco and others try to create conventions on which all > parties will have to agree. One thing remain, a DTD is > insufficient. We also need: a) reliable repositories and document > specification conventions and references Sounds like the role of xml.org to me. > b) way to tell that this transaction is really from the one who > claim being the transaction initiator (The community have to agree > on an authentication method) Yup. Actually, we need an engine for this purpose, and, even more important, * the ability to plug that engine into our doc processing applications, and * the ability to inherit the information architecture that that engine understands into any other information architecture. Sounds like the proper role of the grove paradigm, with property sets for inherited architectures. XML Schema is getting there, but it's not quite there yet. > c) We won't have a simple universe, so there will be more than one > document specification for the same kind of transaction. So we'll > need official translation form a transaction format to an other and > repository where these rule are stored. What's really needed is a formalized property set for each information set that is conveyable by each information architecture. With such property sets, arbitrary conversions become possible, and hooking each architecture's engine to each other architecture's engine becomes a piece of cake. Yes, we certainly need a repository for such property sets. Sounds like the role of xml.org to me. > d) And finally interpreters or parsers+interpreters that can > validate a document and interface with back ends ERP. You're describing architecture-specific engines for creating property-set conforming groves from interchangable resources. Groves are, by definition, ready to connect to ERP or any other kind of application. > Actually DTD is insufficient to provide all necessary information, Right. You need not only an interchange specification, but also the abstract information set. That's what a property set is supposed to be. There is a lot of confusion out there. The simple fact is that we need BOTH an interchange spec AND an abstract information spec in order to efficiently interchange any particular kind of information in an application-neutral and vendor-neutral fashion. > Schema is not yet a recommendation. Time is clicking and corporation > want to take position in this new rat race. So...I am not so sure > that only DTD will resolve the problem especially when you > dynamically compose a new XML document from XML document (EX: a > transaction that includes a request for a catalog and a purchase > order - two different documents merged into one). The DTD would have > to be dynamically created as the document is. And that's a completely and easily supported scenario, given inheritable architectures, property sets, and groves. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Tue Jun 1 23:33:59 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:41 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java In-Reply-To: <14163.61975.304542.267110@localhost.localdomain> References: <14163.61975.304542.267110@localhost.localdomain> Message-ID: * David Megginson | | There is an alpha version of SAX2 for Java available for download from | | http://www.megginson.com/SAX/SAX2/ Great! I'm really happy to see SAX2 moving forward another step. Immediate reactions: it looks good, but filters seem to be missing. I think filters really should be in SAX2, for the following reasons: - the basic filter interface and concept is simple and fundamental - having a single basic standard for filters is important, as many different packages will probably/hopefully use them as pluggable components (MDSAX, SAXON, XSL processors, parsers etc) - it needs to be done anyway, and doing it in SAX2 saves us an extra layer of standards I'll start on translating SAX2 to Python now and accumulate more specific comments as I do so. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Tue Jun 1 23:36:33 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:12:41 2004 Subject: Just require URLs In-Reply-To: Message-ID: <000001beac76$bf6ef170$7e18a8c0@jsussna.quokka.com> There appear to be conflicts between RFC's 2396 (URI: Generic Syntax) and 2141 (URN Syntax). Interestingly, RFC 2396 is not specified as updating RFC 2141. In any case: *Both specs agree that a URN must be preceded by the scheme "urn". *RFC 2141 states that the forward-slash (and other reserved) character should not be used in unescaped form, as its "applicability" is (or was at time of writing, 5/97) still open to debate. *RFC 2396, on the other hand, states that forward-slash (and other reserved) character should not be used in unescaped form IF "the data...would conflict with the reserved purpose". This seems to imply that it's ok to use "/" unescaped if it denotes a hierarchical namespace. *RFC 2396 APPEARS to state that an "authority" must be preceded by double-forward-slash. It is not totally clear to me whether this applies to the NID component of a URN. First of all, I would be interested in opinions as to the above statements. Secondly, I would be interested in opinions as to the advisability of going ahead and using unencoded forward-slashes to denote hierarchy within a URN. I need to denote such hierarchy, and it seems hard to believe that forward-slash wouldn't be defined to denote such hierarchy. Thus encoding it seems like a waste of time, effort, and an unnecessary loss of readability. Jeff > -----Original Message----- > From: owner-xml-dev@ic.ac.uk > [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Didier PH Martin > Sent: Tuesday, June 01, 1999 12:12 PM > To: 'XML Dev' > Subject: RE: Just require URLs > > > Hi Jonathan, > > Jonathan said: > Under the definition of URN in 2396, a URN is any URI > whose intention is > to reference an abstract resource, act primarily as a name, > and/or not be > retrievable via a network. Under the definition in 2396, > "urn" defines a > scheme/namespace (URI namespace) whose intention is to serve > *only* for > URNs, however the spec suggests that any scheme e.g. "http" > can serve to > define a URN, given the definition of URN in 2396 (part of > which my earlier > message quotes). > > So, my reading of RFC 2396 and the XML namespace spec leads me to > conclude that all URIs used as XML namespaces are properly > URNs regardless > of the URI scheme prefix. > > Didier says: > This is not what RFC 2396 says. You are right when you say > that a URI coudl > be a URL or a URN. However a HTTP scheme cannot be considered as a URN > because it is already part of the URL space. > > If however you create a name space having as NID "HTTP" then > yes this would > be a URN. However each "/" would have to be encoded. Thus, a > URN cannot be > with "/" as delimiters. Obviously we'll have to create a new RFC for > hierarchical name spaces having "/" as delimiters but > actually you would > have to encode each "/". Thus your name space would look like: > > urn:http:domain.com%(hex for /)context%(hex for /)etc... > > The above URN confor to RFC 2141 specs. However the URL: > http://domain.com/context/etc... do not conform to RFC 2141 > and thus cannot > be said to be a URN. > > regards > Didier PH Martin > mailto:martind@netfolder.com > http://www.netfolder.com > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RDaniel at DATAFUSION.net Wed Jun 2 00:11:20 1999 From: RDaniel at DATAFUSION.net (Ron Daniel) Date: Mon Jun 7 17:12:41 2004 Subject: Paul has volunteered (was Re: Overloaded URIs must GO!) Message-ID: <0D611E39F997D0119F9100A0C931315C52F81F@datafusionnt1> Jonathan Borden says: > URN's don't allow > dereferencing (otherwise they become another type of URL). Wouldn't it > also > be an error to attempt to dereference "urn:xxx..."? > [Ron Daniel] I have seen some similar assertions that URNs are not to be resolved. That is not the case. URNs are meant to be resolved, but they do not specify a particular resolution procedure that must be followed. You are free to resolve them any way you want. The URN WG did define one resolution procedure that people could use as a fallback in case they came across novel URNs that their local resolution procedures could not handle. See RFCs 2168 and 2169 for that fallback procedure. (Truth in advertising compels me to say that I'm an editor of those two documents). Regards, Ron Daniel Jr. DATAFUSION, Inc. 139 Townsend Street, Suite 100 San Francisco, CA 94107 415.222.0100 fax 415.222.0150 rdaniel@datafusion.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 2 00:16:02 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:42 2004 Subject: URNs and SPAM Message-ID: <37545909.9263BDEC@prescod.net> John Cowan noted that an email-based URN mechanism could be harvested by both current and future spam-address collectors. There are three possible levels of defence that could be used separately or combined: 1. don't worry about it. We'll have other URN mechanisms soon and today's harvesters won't recognize urn:urn-22:foo@bar.com:blah anyhow. 2. Slightly obfuscate the syntax: e.g. change the "@" to a ":" Perhaps reverse the order of the domain name and the user name. 3. Massively obfuscate the syntax: use crypt. Even URN-smart bots won't be able to uncrypt them. Downside: this is complex and there is a really, really really, tiny chance of two email addresses generating the same crypted text. I am leaning toward option 2. By the time spammers have heard of "URNs" and figured out that some have email addresses in them we will have a bunch of other URN-definition mechanisms. They will probably be harder to use but will not have this particular flaw. Those who are worried about the flaw can use those other mechanisms. And of course we can update the spec. if it became a problem anyhow. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 2 00:27:33 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:42 2004 Subject: Just require URLs References: <02ad01beac31$671a1490$0b2e249b@fileroom.Synapse> Message-ID: <37541796.A971DD74@prescod.net> Jonathan Borden wrote: > > Interestingly 2396 defines 'resource' as > either an abstract or physical entity, an example of an abstract entity > would be a namespace. Tim claims that a namespace is not a resource of any sort. The namespace mechanism uses a string that happens to be a URI. The existence of the URI implies the existence of the resource but it does not imply that the namespace *is* the resource. I have pointed to terminology in the namespaces specification that could be used to support that view but it clearly was not the intent of at least one of the editors. It is clearly the intent of RFC 2396 that it be possible to differentiate between URLs and URNs based on syntax, not on context. Furthermore, 2386 does not claim to update or obsolete 2141 which says: "this document sets forward the canonical syntax for URNs" and says: "all URNs have the following syntax..." > Under the definition of URN in 2396, a URN is any URI whose intention is > to reference an abstract resource, act primarily as a name, and/or not be > retrievable via a network. Under the definition in 2396, "urn" defines a > scheme/namespace (URI namespace) whose intention is to serve *only* for > URNs, however the spec suggests that any scheme e.g. "http" can serve to > define a URN, given the definition of URN in 2396 (part of which my earlier > message quotes). It does not suggest any such thing. Rather it goes out of its way to justify its use of URLs as examples instead of URNs. If they could be interepted either way, why bother? URN "identifiers [are] drawn from a set of defined namespaces." *Defined URN Namespaces* -- as in draft-ietf-urn-nid-req > So, my reading of RFC 2396 and the XML namespace spec leads me to > conclude that all URIs used as XML namespaces are properly URNs regardless > of the URI scheme prefix. As David Megginson said much more eloquently, you can read as much into the RFCs and IDs as you can into the Bible. I have never heard a reading compatible with yours before so it certainly isn't a basis for interoperable behavior. If http://www.w3.org can be interpreted as a URN without some explicit statement in the containing context but based rather on the state of someone's neurotransmitters and "intent" then we have are destined to have a big interoperability problem. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RDaniel at DATAFUSION.net Wed Jun 2 00:30:39 1999 From: RDaniel at DATAFUSION.net (Ron Daniel) Date: Mon Jun 7 17:12:42 2004 Subject: Just require URLs Message-ID: <0D611E39F997D0119F9100A0C931315C52F820@datafusionnt1> A pedantic point to clarify some of the confusion over '/' in URNs and URLs. RFC 2141 (the URN syntax spec) says that forward slashes SHOULD NOT be used in their unescaped form. The pedantic point is that to really really really forbid this, the spec would have said MUST NOT. (And I know for a fact that the choice of SHOULD NOT vs. MUST NOT was deliberate in this case). The use of '/' gets bound up with the question of 'relative URNs' and whether they are meaningful. The working group did not reach consensus on that point, so the compromise was to discourage the use of '/' but not totally forbid it. RFC 2396 is correct here. You MUST use '/' to denote hierarchy. If you want to use them for something else you MUST %encode them. If you want to do URNs with hierarchical levels in them, you MAY use '/' but you SHOULD NOT. (The reason for that, as I recall, is that it is very easy to break relative URNs.) Speaking personally, if I were sure that I would not be doing relative identifiers, I wouldn't let the "SHOULD NOT" stop me from using '/'. regards, Ron Daniel Jr. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 2 00:35:35 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:42 2004 Subject: URNs and SPAM References: <37545909.9263BDEC@prescod.net> Message-ID: <37546096.CB7B87DA@locke.ccil.org> Paul Prescod wrote: > 1. don't worry about it. We'll have other URN mechanisms soon and today's > harvesters won't recognize urn:urn-22:foo@bar.com:blah anyhow. I suspect this is false, and that harvesters will recognize "foo@bar.com" embedded in any text. > I am leaning toward option 2. I like option 2 also. "I do not like this URNish spam! I do not like it, Sam-I-am!" "There was only one URN -- but that was URN-22." -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jes at kuantech.com Wed Jun 2 01:24:35 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:12:42 2004 Subject: Just require URLs In-Reply-To: <0D611E39F997D0119F9100A0C931315C52F820@datafusionnt1> Message-ID: <000201beac85$e2fafd00$7e18a8c0@jsussna.quokka.com> Thanks, your comments are very well put and helpful. I do not in fact intend to use relative urn's. I do, however, need them to be as human-readable/writable as possible, and hierarchy supports those requirements in my case. Jeff > -----Original Message----- > From: Ron Daniel [mailto:RDaniel@DATAFUSION.net] > Sent: Tuesday, June 01, 1999 3:33 PM > To: 'Jeffrey E. Sussna'; 'XML Dev' > Subject: RE: Just require URLs > > > A pedantic point to clarify some of the confusion over '/' in URNs > and URLs. > > RFC 2141 (the URN syntax spec) says that forward > slashes SHOULD NOT be used in their unescaped form. The > pedantic point is that to really really really forbid this, > the spec would have said MUST NOT. (And I know for a fact > that the choice of SHOULD NOT vs. MUST NOT was deliberate > in this case). > > The use of '/' gets bound up with the question of 'relative > URNs' and whether they are meaningful. The working group > did not reach consensus on that point, so the compromise > was to discourage the use of '/' but not totally forbid it. > > RFC 2396 is correct here. You MUST use '/' to denote hierarchy. > If you want to use them for something else you MUST %encode them. > If you want to do URNs with hierarchical levels in them, you > MAY use '/' but you SHOULD NOT. (The reason for that, as I > recall, is that it is very easy to break relative URNs.) > > Speaking personally, if I were sure that I would not be doing > relative identifiers, I wouldn't let the "SHOULD NOT" stop > me from using '/'. > > regards, > Ron Daniel Jr. > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Wed Jun 2 03:43:23 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:42 2004 Subject: Just require URLs In-Reply-To: <85256783.0071498C.00@mail.copeland.com> Message-ID: Hi Jeff, Is there a central repository for all RFC specs?? Yes http://www.ietf.org regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com - xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed Jun 2 04:06:49 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:42 2004 Subject: Just require URLs In-Reply-To: <37541796.A971DD74@prescod.net> Message-ID: <002001beac9b$a2abd0b0$1b19da18@ne.mediaone.net> Paul Prescod wrote: > > > Jonathan Borden wrote: > > > > Interestingly 2396 defines 'resource' as > > either an abstract or physical entity, an example of an abstract entity > > would be a namespace. > > Tim claims that a namespace is not a resource of any sort. The namespace > mechanism uses a string that happens to be a URI. The existence of the URI > implies the existence of the resource but it does not imply that the > namespace *is* the resource. I have pointed to terminology in the > namespaces specification that could be used to support that view but it > clearly was not the intent of at least one of the editors. Not everyone defines resource as it is defined in RFC 2396. Perhaps Tim might clarify his thought wrt this specific definition. > > > Under the definition of URN in 2396, a URN is any URI whose > intention is > > to reference an abstract resource, act primarily as a name, > and/or not be > > retrievable via a network. Under the definition in 2396, "urn" defines a > > scheme/namespace (URI namespace) whose intention is to serve *only* for > > URNs, however the spec suggests that any scheme e.g. "http" can serve to > > define a URN, given the definition of URN in 2396 (part of > which my earlier > > message quotes). > > It does not suggest any such thing. Rather it goes out of its way to > justify its use of URLs as examples instead of URNs. If they could be > interepted either way, why bother? URN "identifiers [are] drawn from a set > of defined namespaces." *Defined URN Namespaces* -- as in > draft-ietf-urn-nid-req If this is how namespaces are defined, you are correct. From 2396: "The URI scheme (Section 3.1) defines the namespace of the URI" I draw the conclusion that schemes such as "urn","http","ftp" define the URI namespace rather than "draft-ietf-urn-nid-req", so perhaps 2141 and 2396 define both "URN" and "namespace" differently. Granted reading RFCs is like reading the bible (or tea leaves), but a mark of a competant theologist (or tea leaf reader) is the ability to support one's argument via quoting the bible (or reading something into ones tea leaves):-) More seriously, a specification is only as good as the precision and clarity of its writing so hopefully these discussions will prompt greater precision and more clarity. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sysx at superlink.com Wed Jun 2 06:35:14 1999 From: sysx at superlink.com (Pawel Potocki) Date: Mon Jun 7 17:12:42 2004 Subject: IBM's xml4j 2.x and VisualCafe Message-ID: <3754B545.CAD07E3E@superlink.com> I wonder if anyone had problems working with IBM's xml parser for Java version 2.x (2.09 is the newest I belive) and Symantec's Visual Cafe 3.0a (3.0, 2.5a or any other). I just switched from IBM's xml parser version 1 (1.1.16) t o version 2 and have problem running examples in the debugger mode. Without debugger, it is OK, but with debuger I get exceptions and can't seems to find a way to fix them. I tried all sort of things, I pointed VisualCafe to different vm's and still same problem. Below I'm attaching printout from DOMCount example in the samples directory. Interesting anough that this works well in the IBM's VisaulAge for Java (debugging mode as well). Thanks for any input and help in this. -Pawel (this is from vm 1.1.7b in VisualCafe 3.0a): Exception raised: "Exception: java.lang.ArrayIndexOutOfBoundsException 32 at com.ibm.xml.internal.DefaultStringPool.ensureCapacity(DefaultStringPool.java:101) at com.ibm.xml.internal.DefaultStringPool.addString(DefaultStringPool.java:182) at com.ibm.xml.internal.UTF8CharReader$UTF8CharDataChunk.addString(UTF8CharReader.java:1597) at com.ibm.xml.internal.UTF8CharReader.addString(UTF8CharReader.java:52) at com.ibm.xml.internal.UTF8CharReader.callWSCharDataHandler(UTF8CharReader.java:919) at com.ibm.xml.internal.UTF8CharReader.scanContent(UTF8CharReader.java:650) at com.ibm.xml.internal.DefaultScanner.scanContent(DefaultScanner.java:1020) at com.ibm.xml.internal.DefaultScanner.scanDocument(DefaultScanner.java:405) at com.ibm.xml.framework.XMLParser.parse(XMLParser.java:327) at com.ibm.xml.framework.XMLParser.parse(XMLParser.java:371) at dom.wrappers.DOMParser.parse(DOMParser.java:59) at dom.DOMCount.count(DOMCount.java:71) at dom.DOMCount.main(DOMCount.java:213) at sun.tools.debug.MainThread.run(Agent.java:47) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 2 08:42:09 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:42 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java In-Reply-To: <14163.61975.304542.267110@localhost.localdomain> References: <14163.61975.304542.267110@localhost.localdomain> Message-ID: * David Megginson | | There is an alpha version of SAX2 for Java available for download | from | | http://www.megginson.com/SAX/SAX2/ I've now done a preliminary Python translation and done most of the work on adding SAX2 features and properties to the xmlproc driver. Overall I think this is looking very good. Comments: - Should we have a CompleteHandlerBase in helpers which combines HandlerBase, DeclHandler, LexicalHandler and NamespaceHandler? - If one of the misc handlers are supported, must all the methods in it be supported? (For example, xmlproc currently won't support the CDATA callbacks in LexicalHandler.) - Should the *NamespaceDeclScope methods be called *NamespaceScope instead? It's a little less of a mouthful, at least. - Do we need to mandate a default value for namespace separator? Should it be space ( )? - Can namespace properties be tuned when namespace processing is off? - Should we add a DTDParser interface? In some cases one will only want to parse the DTD and since we have DeclHandler and DTDHandler it makes sense to me to add an interface to a DTD parser. Maybe like so: public interface DTDParser extends Configurable { public void setDTDHandler(DTDHandler handler); // used for parameter entities public void setEntityResolver(EntityResolver resolver); public void setLocale(Locale locale) throws SAXException; public void setErrorHandler(ErrorHandler handler); public void parse(InputSource source) throws SAXException, IOException; public void parse(String systemId) throws SAXException, IOException; } // Maybe we should also do something here to enable locator // support? Have a special read-only property for the locator? // (Ugly, I know.) // Features: external-param-entities // Properties: dom-node?, xml-string, DeclHandler - Where did AttributeList2 go? Also, I'll get back to the filter issue. Now I need to work on my thesis. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrew.douglas at netcentric-solutions.com Wed Jun 2 13:26:40 1999 From: andrew.douglas at netcentric-solutions.com (Andrew Douglas) Date: Mon Jun 7 17:12:42 2004 Subject: Confusion while implementing the DOM. Message-ID: A non-text attachment was scrubbed... Name: not available Type: text Size: 2679 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990602/eb1a54ba/attachment.bat From msabin at cromwellmedia.co.uk Wed Jun 2 13:55:24 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:42 2004 Subject: Confusion while implementing the DOM. Message-ID: Andrew Douglas wrote, > > Hello > Goodbye > Gutten Adbend > Aufwiedersehen > > > My underlying structure looks like this > > > opentag(root) > | > zomcontent > |-----------+-----------------| > sequence sequence > |------+-----| |------+-------| > opentag(elone) opentag(eltwo) opentag(elone) opentag(eltwo) > | | | | > text text text text > > Not suprisingly, it looks like a tree! So, all these > things can be Nodes, but not all are Elements (opentags > are) -- some are probably DocumentFragments(zomcontent, > sequence, ...). > > So, my DOM implementation has the usual first/last > Child, getChildNodes, get Next/Previous siblings, and > so on, but sometimes these children aren't Elements, > but are DocumentFragements. Ahh ... no, I'm afraid that's not quite right. The DOMs idea of the structure of your document would be, Document doc Element root == doc.getDocumentElement() Element elone == root.getFirstChild() Text Hello == elone.getFirstChild() Element eltwo == elone.getNextSibling() Text Goodbye Element elone Text Gutten Adbend Element eltwo Text Aufwiedersehen A Document *never* has a DocumentFragment amongst its children: the latter exist solely to provide a lightweight holder for Nodes which are _owned_by_, but not _part_of_ a given Document. Note that all Nodes that are created on a particular Document (eg. via Document.createElement()) are always owned by that Document (and so can't be pasted into a different doc), but don't become part of it until they're explicitly added (eg., via someNode.appendChild()). I hope that helps a bit ... Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrew.douglas at netcentric-solutions.com Wed Jun 2 14:26:38 1999 From: andrew.douglas at netcentric-solutions.com (Andrew Douglas) Date: Mon Jun 7 17:12:42 2004 Subject: Confusion while implementing the DOM. Message-ID: A non-text attachment was scrubbed... Name: not available Type: text Size: 2475 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990602/226dbc91/attachment.bat From msabin at cromwellmedia.co.uk Wed Jun 2 14:36:16 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:42 2004 Subject: Confusion while implementing the DOM. Message-ID: Andrew Douglas wrote, > The standard I've got states that a DocumentFragment is > a Node (or at least, it does in the Java headers I've > got). That was my mistake, I think. No mistake. A DocumentFragment *is* a Node. But if you try and insert it into the tree, you'll find that a conforming implementation will throw a HIERARCHY_REQUEST_ERR. > Plus, it seemed like fun and a good way of learning how > it all fits in The best way to learn an API is to implement it :-) Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Wed Jun 2 16:16:00 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:12:42 2004 Subject: Just require URLs Message-ID: <805C62F55FFAD1118D0800805FBB428D0106AEB8@cc20exch2.mobility.com> Jonathan Borden Writes: > Granted reading RFCs is like reading the bible (or tea > leaves), but a mark > of a competant theologist (or tea leaf reader) is the ability > to support > one's argument via quoting the bible (or reading something > into ones tea > leaves):-) > > More seriously, a specification is only as good as the > precision and > clarity of its writing so hopefully these discussions will > prompt greater > precision and more clarity. Actually, anyone can prove almost ANY theological point by quoting sections of the bible, just like anyone can prove almost any URI point by quoting sections of the RFCs. The competent [Christian] theologist, however, knows the bible cover to cover, and how those distinct sections fit in with the whole, just like the competent URI... um... "discusser" knows all of the RFCs, and how each section fit in with the whole. Sorry, I wasn't able to relate this to tea leaves. Or to other religions, for that 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 2 16:19:17 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:43 2004 Subject: SAX2 Queries (was Re: Announcement: SAX2 1999-06-01 alpha release for Java) In-Reply-To: References: <14163.61975.304542.267110@localhost.localdomain> Message-ID: <14165.15161.468164.927448@localhost.localdomain> Lars Marius Garshol writes: > - Should we have a CompleteHandlerBase in helpers which combines > HandlerBase, DeclHandler, LexicalHandler and NamespaceHandler? I'm reluctant, because I don't want to hard-code the optional handlers into the interface any more than I have to. Right now, the separate handler classes are present, but they are nowhere referred to. In the future, we may need to add new handler types (SchemaHandler?), and I don't want to have to change existing classes when we do so. > - If one of the misc handlers are supported, must all the methods in > it be supported? (For example, xmlproc currently won't support the > CDATA callbacks in LexicalHandler.) Opinions, anyone? Clearly, matching start/end events have to be both implemented or both skipped, but otherwise, what are people's expectations? > - Should the *NamespaceDeclScope methods be called *NamespaceScope > instead? It's a little less of a mouthful, at least. I thought about it, but the problem is that it's not the scope for the namespace, only for the declaration; the same namespace might be mentioned in several nested declarations. > - Do we need to mandate a default value for namespace separator? > Should it be space ( )? Yes, we do need a default. The DOM WG is struggling with this as well, and we might be able to piggy-back. Personally, I like , but I recall that John Cowan is partial to ^ (caret). > - Can namespace properties be tuned when namespace processing is off? No -- we need to make that clear > - Should we add a DTDParser interface? In some cases one will only > want to parse the DTD and since we have DeclHandler and DTDHandler > it makes sense to me to add an interface to a DTD parser. Maybe > like so: I don't think that we need a separate interface. After all, you could create SAX parsers for RTF, HTML, LaTeX, or just about anything -- there's no reason that someone couldn't create a SAXDTDParser class implementing Parser and Configurable, where the class tried to parse a DTD rather than a complete document. > - Where did AttributeList2 go? I was wondering if anyone would notice. I'm still not sure how to handle that -- should there be a feature that you can use to check whether the parser can deliver an extended attribute list? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 2 16:19:56 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:43 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java In-Reply-To: References: <14163.61975.304542.267110@localhost.localdomain> Message-ID: <14165.8743.130039.285638@localhost.localdomain> Lars Marius Garshol writes, ironically: > Immediate reactions: it looks good, but filters seem to be missing. > > I think filters really should be in SAX2, for the following reasons: > > - the basic filter interface and concept is simple and fundamental > > - having a single basic standard for filters is important, as many > different packages will probably/hopefully use them as pluggable > components (MDSAX, SAXON, XSL processors, parsers etc) > > - it needs to be done anyway, and doing it in SAX2 saves us an extra > layer of standards Two responses: 1. Do we need a filter *interface* at all, or can a filter just be a class that happens to implement Parser, Configurable, EntityResolver, DTDHandler, DocumentHandler, and ErrorHandler? (In other words, is it enough to set the parent parser/filter in the constructor?) 2. Actually, just last night I wrote an org.xml.sax.helpers.FilterAdapter base class that filters can easily be derived from (though they wouldn't have to be); by default, it just lets all events sink down to the application, and all configuration bubble up to the parser, but subclasses can simply override methods to make changes in either direction. I was thinking of including this class in the next SAX2 pre-release, if people are interested; I can also distribute it separately in the mean time. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 2 16:19:45 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:43 2004 Subject: Just require URLs In-Reply-To: <37541796.A971DD74@prescod.net> References: <02ad01beac31$671a1490$0b2e249b@fileroom.Synapse> <37541796.A971DD74@prescod.net> Message-ID: <14165.9061.742506.813990@localhost.localdomain> Paul Prescod writes: > Tim claims that a namespace is not a resource of any sort. I cannot speak for Tim, but here's one way to think of it: The Namespace is the *abstraction* of the collection of XML names that happen to share the same URI part (the Platonic Ideal of the collection, if you will). I don't know if I actually agree with this; on the other hand, if we had waited to get the philosophy right before releasing Namespaces, we'd have been talking for years. Please don't complain that the W3C isn't ISO or the EU. We batted around a lot of ideas like this during the design process, but we were at least smart enough to realize that we weren't smart enough to do that much that fast. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Wed Jun 2 16:34:42 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:43 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java Message-ID: David Megginson wrote, > 1. Do we need a filter *interface* at all, or can a > filter just be a class that happens to implement This works very nicely. > 2. Actually, just last night I wrote an > org.xml.sax.helpers.FilterAdapter base class > I was thinking of including this class in the next > SAX2 pre-release, if people are interested; Can't hurt ... might help. -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jun 2 16:40:48 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:43 2004 Subject: ANN: Building XML Applications Message-ID: <199906021441.KAA27635@hesketh.net> At long last, McGraw-Hill has shipped _Building XML Applications_, a book I co-authored with Ethan Cerami. The book focuses on XML and Java development using SAX, with some coverage of the DOM. For more information, see: http://www.simonstl.com/buildxml/index.html List price is $49.99 ($39.99); the ISBN is 0071341161. Amazon claims 24 hour shipment, but I haven't yet seen it in a regular bookstore. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 2 16:40:59 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:43 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java In-Reply-To: References: Message-ID: <14165.16862.577958.110731@localhost.localdomain> Miles Sabin writes: > > 2. Actually, just last night I wrote an > > org.xml.sax.helpers.FilterAdapter base class > > > I was thinking of including this class in the next > > SAX2 pre-release, if people are interested; > > Can't hurt ... might help. Actually it can hurt, a bit -- if we want to keep the SAX2 JAR file small enough for use on palmtops or over slow network connections, we have to treat it like the space shuttle, where every pound (or octet, in this case) counts. The question is whether filters are or will be common enough to justify including a base class in the SAX2 JAR. I'd guess that they are -- what do others think? Thanks, and all the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Wed Jun 2 16:47:35 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:43 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java Message-ID: David Megginson wrote, > Miles Sabin writes: > > Can't hurt ... might help. > > Actually it can hurt, a bit -- if we want to keep the > SAX2 JAR file small enough for use on palmtops or over > slow network connections, we have to treat it like the > space shuttle, where every pound (or octet, in this > case) counts. That's not a problem. If there are no dependencies on the filter adapter from any other SAX class or interface (there wouldn't be) then it could be safely left out of any size critical deployment. There's any number of tools that do that sort of thing automagically. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed Jun 2 16:52:46 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:43 2004 Subject: Just require URLs Message-ID: <03ea01bead06$ab690c70$0b2e249b@fileroom.Synapse> Hunter, David wrote: > >Actually, anyone can prove almost ANY theological point by quoting >sections of the bible, just like anyone can prove almost any URI >point by quoting sections of the RFCs. The competent [Christian] >theologist, however, knows the bible cover to cover, and how those distinct >sections fit in with the whole, just like the competent URI... um... >"discusser" knows all of the RFCs, and how each section fit in with the >whole. > >Sorry, I wasn't able to relate this to tea leaves. Or to other >religions, for that matter. > So this analogy ought be cut off quickly lest we forget that we don't hire theologists to design bridges in 20th century civilization. The real argument here is whether a URI with the scheme "http" or "ftp" ought be used to define an XML namespace. The argument has led to discussion of whether such URIs are intended to serve as unique names aside from their intended purpose to serve as resource locators. The argument is twofold: First, using a particular definition of "resource", a name can be termed a locator for the "abstract resource" which is itself the name (or perhaps namespace). A distinction is made between this use of the term "resource" and the more common use in locating a "physical" resource such as a document located on a network. Second, the definition of URI, includes the concepts of URIs used as persistent names (e.g. "URN") as well as URIs used as resource locators (URL). The argument has arisen about whether URLs ought be used as XML namespace URIs and in particular whether the same URI can be used as a URL in one place and a persistent name (I won't call this a URN due to conflicts with 2141) in another (this would be some future as yet unspecified specs which build upon XML namespaces). I argue that per the URI specification (RFC2396) I see no reason why URIs which begin with particular schemes (e.g. "http") can or ought not be used as a persistent name. Aside from my reading and interpretation of RFC 2396, support for this position is in the XSL specification itself which uses URIs belonging to the "http" scheme to define the "xsl" namespace. In prior posts, I;ve asked for specific practical current problems that are created by using such URIs. The bottom line in bridge building (as opposed to theological arguments) is the fact that the bridge stands up to its specified weight for its specified lifespan. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Wed Jun 2 17:51:28 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:43 2004 Subject: FW: Interpretation problems - perceived conflict between RFC 2141 and RFC 2396 Message-ID: Hi, I posted your message in the URN WG mailing list and here is the answer from one of the WG member. Regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com -----Original Message----- From: Leslie Daigle [mailto:leslie@thinkingcat.com] Sent: Wednesday, June 02, 1999 9:30 AM To: martind@NETFOLDER.COM Cc: URN-IETF@LISTS.INTERNIC.NET Subject: Re: Interpretation problems - perceived conflict between RFC 2141 and RFC 2396 Howdy, Thanks for forwarding the questions. > *RFC 2141 states that the forward-slash (and other reserved) character > should not be used in unescaped form, as its "applicability" is (or was at > time of writing, 5/97) still open to debate. > > *RFC 2396, on the other hand, states that forward-slash (and other reserved) > character should not be used in unescaped form IF "the data...would conflict > with the reserved purpose". This seems to imply that it's ok to use "/" > unescaped if it denotes a hierarchical namespace. Actually, I read the words to the contrary. I read these words to say that unescaped "/" should be interpreted by the rules of hierarchy laid out in 2396, and any other expected interpretation requires the character to be escaped. 2396 defines a particular mechanism for interpreting and manipulating hierarchical structures of URIs -- denoted by the use of the forward slash. This includes the ability to make relative references, etc, that we were never able to reconcile with the notion of providing fixed, persistent references (URNs). Rather than try to effect changes to that interpretation of "/" in URIs, or subject URNs to all existing URI rules for handling that hierarchy, we decided to abstain from the use of the character. Note that this does not mean namespaces cannot use "/" to denote hierarchy -- if it is escaped, it can be used for hierarchy as it is understood local to a particular namespace (i.e., browsers and editors will not attempt to create or interpret relative URIs of them). > *RFC 2396 APPEARS to state that an "authority" must be preceded by > double-forward-slash. It is not totally clear to me whether this applies to > the NID component of a URN. Again, this is "authority" as it is defined by the URI syntax, subject to the particular interpretation as laid out in 2396. There are other URI schemes that do not have an authority component preceded by "//". > First of all, I would be interested in opinions as to the above statements. See above. > Secondly, I would be interested in opinions as to the advisability of going > ahead and using unencoded forward-slashes to denote hierarchy within a URN. Don't. :-> More seriously, look a little more closely at the problem, and I think you'll see the distinction we're trying to draw. > I need to denote such hierarchy, and it seems hard to believe that > forward-slash wouldn't be defined to denote such hierarchy. Thus encoding it > seems like a waste of time, effort, and an unnecessary loss of readability. a) don't forget that URNs are not primarily targetted at being human-readable b) is the hierarchy you are looking for really all the bells & whistles of relative URIs as found in 2369, in which case you may not be after a URN afterall. You may want the resolution mechanisms laid out in, for instance, the NAPTR RDS, but those are already described in generic terms as being applicable to all URIs, not just URNs. Leslie. -- ------------------------------------------------------------------------ "My cat has all the answers. But she claims Leslie Daigle she doesn't know the questions." leslie@thinkingcat.com ------------------------------------------------------------------------ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 2 18:05:30 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:43 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java References: <14163.61975.304542.267110@localhost.localdomain> <14165.8743.130039.285638@localhost.localdomain> Message-ID: <37555010.21BD9A81@locke.ccil.org> David Megginson wrote: > 1. Do we need a filter *interface* at all, or can a filter just be a > class that happens to implement Parser, Configurable, > EntityResolver, DTDHandler, DocumentHandler, and ErrorHandler? Actually, a parser filter only *has* to implement Parser. Whether it implements the other things, or delegates their implementation to private objects, is a detail. > (In > other words, is it enough to set the parent parser/filter in the > constructor?) IMHO yes. One could use reflection to determine whether there is such a constructor, at least in the Java domain. > 2. Actually, just last night I wrote an > org.xml.sax.helpers.FilterAdapter base class that filters can > easily be derived from (though they wouldn't have to be); by > default, it just lets all events sink down to the application, > and all configuration bubble up to the parser, but subclasses can > simply override methods to make changes in either direction. I suggest you look at my P.D. code at http://www.ccil.org/~cowan/XML/ParserFilter.java; it would be easy to enhance it for SAX2, and it handles some subtle points. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Wed Jun 2 18:06:19 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:43 2004 Subject: Just require URLs In-Reply-To: <03ea01bead06$ab690c70$0b2e249b@fileroom.Synapse> Message-ID: Hi, a) because a URI could be used to specify a XML name space, we can use either URLs and URNs because both are URIs. b) If we have some forward thinking on the subject, someday, this URI will points to a "place" containing the name space documentation. The ideal world is that the documentation contains both human readable and machine interpretable documents. c) If we choose to use a URL for a name space identifier, we create location dependency to our documents, If we choose URNs, the documents are then location independent. Again, with some forward thinking, the name space documentation may be moved to a registry or moved to several industry registry and still be retrievable (in the case of URNs). In the case of name space documentation referred with a URL, the links become broken if we move the documentation from one "place" to another. Also a some URL like the HTTP URLs points to a single location. A URN can point to several locations. d) like for URL, for human consumption and readability, URN could be written with "/" without encoding. However, the resolution mechanism will have to encode these delimiters before URN->URL transformation on a URN resolver (could be a DNS or any other kind of server like for instance LDAP). This is what is done with most modern browsers today. The user enters a URL containing spaces in the text box and each space gets encoded before the URL gets resolved into a resource on the HTTP server. Conclusion: URN brings more longevity to information elements contained in the published document. The URN can be resolved as long as a resolver has been created to resolve its particular name space (URN name space). In the case of URLs any documentation movement leads to a break of the links and the document is no longer linked to its documentation. Thus, in this case, the document has a shorter longevity (because we cannot retreive the document vocabulary rules and meanings). regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 2 18:05:38 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:43 2004 Subject: SAX2 Queries (was Re: Announcement: SAX2 1999-06-01 alpha release for Java) References: <14163.61975.304542.267110@localhost.localdomain> <14165.15161.468164.927448@localhost.localdomain> Message-ID: <37555333.164980EA@locke.ccil.org> David Megginson wrote: > Personally, I like , but I recall that John Cowan is partial to > ^ (caret). #&32; is fine with me 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed Jun 2 18:56:51 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:43 2004 Subject: Just require URLs Message-ID: <045e01bead18$001c2f20$0b2e249b@fileroom.Synapse> Didier PH Martin wrote: > > >a) because a URI could be used to specify a XML name space, we can use >either URLs and URNs because both are URIs. >b) If we have some forward thinking on the subject, someday, this URI will >points to a "place" containing the name space documentation. The ideal world >is that the documentation contains both human readable and machine >interpretable documents. I agree that this would be a benefit of overloading the namespace URI. >c) If we choose to use a URL for a name space identifier, we create location >dependency to our documents, If we choose URNs, the documents are then >location independent. I have a quibble with this terminology. URLs need not be location dependent. This is a function of the URL scheme or namespace. For example suppose we invent a new location independent protocol (LIP): "lip:W3C/Specifications/XSLT/Version1.0" or: "FPI: ...." This would be a location independent URL. The idea remains that URLs are URIs used to "locate" resources. If you overload the "urn" scheme with a network protocol, it really becomes a URL regardless of its definition in 2141. > >Conclusion: >URN brings more longevity to information elements contained in the published >document. The URN can be resolved as long as a resolver has been created to >resolve its particular name space (URN name space). In the case of URLs any >documentation movement leads to a break of the links and the document is no >longer linked to its documentation. Thus, in this case, the document has a >shorter longevity (because we cannot retreive the document vocabulary rules >and meanings). > Really what you are suggesting is a location independent URL. I agree this is a good idea. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ksievers at novell.com Wed Jun 2 19:02:32 1999 From: ksievers at novell.com (Kent Sievers) Date: Mon Jun 7 17:12:43 2004 Subject: All this buisiness about namespace URNs... Message-ID: Although I have listened to this list for many months, I almost never post anything. Three points: 1) If this is all about giving name spaces a unique name/ID in order to avoid collisions, then there are dozens of ways of generating unique names (I assume that nobody wants to be a registry). For example, you could write a program for the PC that would grab the machines processor ID, combine it with the time stamp and convert it to base 64 and come up with a 16 digit ID that could not be produced by any other PC at any other point in time. If that wasn't human readable enough then you could add your own descriptive text and still come in shorter than many URLs. You would only need access to a PC one time in the lifetime of the name space - to generate the ID/Name that you would use. This is just an example. My point is that if you think about it for very long at all, there are lots of ways of guaranteeing uniqueness, even in a distributed fashion. Especially if you are willing to live with "unique enough." Some other examples: use the hit count on a special web site; have a "grab a tag" type web site that allows visitors to generate unique tags; use one of the global LDAP servers to guarantee a unique E-Mail address; have everyone open an account at the same bank and use their account numbers; use a U.S. patent number (just kidding); etc. etc. etc. 2) Are we really that worried about collisions? After all, don't I usually know (and approve) with whom I am exchanging data? If I can assume that the people I exchange documents with don't have a malicious intent, then what are the odds that if I use "mynamespace.myproject.Novell.com" that I will ever see any problems? Nil! And if they are intending to collide with me, then what recourse would I have anyway? As a side note, it seams like the harder problem is trying to actually collide and share an element. For example: my document has a "subject" while yours has a "topic." Do we have to generate large mappings in order to communicate with lots of different systems? 3) When it comes to global identifiers, it seems to me that there are always two distinct parts: a) the objects name/ID that uniquely identifies it, and b) the objects last known, or probable location. My mail messages, for example, have unique IDs, but they only help me find the message by including addition location information on where to look for it (which message store). The advantage of this type of scheme is: a) I can still uniquely identify it no matter where it is moved, and b) if it is moved, there may be some hope of searching for it and updating it's location. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rja at arpsolutions.demon.co.uk Wed Jun 2 19:20:21 1999 From: rja at arpsolutions.demon.co.uk (Richard Anderson) Date: Mon Jun 7 17:12:44 2004 Subject: All this buisiness about namespace URNs... References: Message-ID: <002401bead1c$6ccb39a0$c5010180@p197> I do not follow this list anymore due to time etc, but this post caught my eye. I assume DCE UUIDs/MS GUIDs have been considered ? ----- Original Message ----- From: Kent Sievers To: Sent: 2 June 1999 18:01 Subject: All this buisiness about namespace URNs... Although I have listened to this list for many months, I almost never post anything. Three points: 1) If this is all about giving name spaces a unique name/ID in order to avoid collisions, then there are dozens of ways of generating unique names (I assume that nobody wants to be a registry). For example, you could write a program for the PC that would grab the machines processor ID, combine it with the time stamp and convert it to base 64 and come up with a 16 digit ID that could not be produced by any other PC at any other point in time. If that wasn't human readable enough then you could add your own descriptive text and still come in shorter than many URLs. You would only need access to a PC one time in the lifetime of the name space - to generate the ID/Name that you would use. This is just an example. My point is that if you think about it for very long at all, there are lots of ways of guaranteeing uniqueness, even in a distributed fashion. Especially if you are willing to live with "unique enough." Some other examples: use the hit count on a special web site; have a "grab a tag" type web site that allows visitors to generate unique tags; use one of the global LDAP servers to guarantee a unique E-Mail address; have everyone open an account at the same bank and use their account numbers; use a U.S. patent number (just kidding); etc. etc. etc. 2) Are we really that worried about collisions? After all, don't I usually know (and approve) with whom I am exchanging data? If I can assume that the people I exchange documents with don't have a malicious intent, then what are the odds that if I use "mynamespace.myproject.Novell.com" that I will ever see any problems? Nil! And if they are intending to collide with me, then what recourse would I have anyway? As a side note, it seams like the harder problem is trying to actually collide and share an element. For example: my document has a "subject" while yours has a "topic." Do we have to generate large mappings in order to communicate with lots of different systems? 3) When it comes to global identifiers, it seems to me that there are always two distinct parts: a) the objects name/ID that uniquely identifies it, and b) the objects last known, or probable location. My mail messages, for example, have unique IDs, but they only help me find the message by including addition location information on where to look for it (which message store). The advantage of this type of scheme is: a) I can still uniquely identify it no matter where it is moved, and b) if it is moved, there may be some hope of searching for it and updating it's location. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Wed Jun 2 19:39:09 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:44 2004 Subject: Just require URLs In-Reply-To: <045e01bead18$001c2f20$0b2e249b@fileroom.Synapse> Message-ID: Hi Jonathan, Jonathan said: I have a quibble with this terminology. URLs need not be location dependent. This is a function of the URL scheme or namespace. For example suppose we invent a new location independent protocol (LIP): "lip:W3C/Specifications/XSLT/Version1.0" or: "FPI: ...." This would be a location independent URL. The idea remains that URLs are URIs used to "locate" resources. If you overload the "urn" scheme with a network protocol, it really becomes a URL regardless of its definition in 2141. Didier says: There is a project called PURL (permanent URL) that uses URL to create permanent names. However, if we overload locators (URL) to do everything even the morning coffee, we'll have some confusion. Its like have a single word to designate everything. This is why we created URN. To distinguish names (URN) form locators (URL). YOu are right to say that on some browser, we can implement a name resolver as a protocol handler. But this is caused by these browsers architecture not by the URN scheme being perceived as a URL. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Jun 2 20:33:00 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:12:44 2004 Subject: Confusion while implementing the DOM. In-Reply-To: Message-ID: <000001bead26$921a1d20$3296fea9@w21tp> > Andrew Douglas wrote, > > The standard I've got states that a DocumentFragment is > > a Node (or at least, it does in the Java headers I've > > got). That was my mistake, I think. > > No mistake. A DocumentFragment *is* a Node. But if you > try and insert it into the tree, you'll find that a > conforming implementation will throw a > HIERARCHY_REQUEST_ERR. Actually, inserting a DocumentFragment 'node' into a tree should insert the child nodes of the DocumentFragment (leaving it empty). HERARCHY_REQUEST_ERR exception should be thrown only if any of the child nodes can not be inserted. State of the tree after partially sucessful DocumentFragment insertion is unspecified in the spec. My implementation revokes the entire operation leaving the tree and the DocumentFragment unchanged. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 2 21:06:46 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:44 2004 Subject: All this buisiness about namespace URNs... In-Reply-To: References: Message-ID: <14165.32954.596890.457@localhost.localdomain> Kent Sievers writes: > 2) Are we really that worried about collisions? After all, don't > I usually know (and approve) with whom I am exchanging data? Not really, especially if you count HTTP transactions as "exchanging data", and in the future, I expect that things will get even more complicated: e-commerce, in particular, pretty much requires an ability for blind information exchange. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed Jun 2 21:08:36 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:44 2004 Subject: Just require URLs Message-ID: <049e01bead2a$591d59c0$0b2e249b@fileroom.Synapse> Didier PH Martin wrote: > >Didier says: >There is a project called PURL (permanent URL) that uses URL to create >permanent names. However, if we overload locators (URL) to do everything >even the morning coffee, we'll have some confusion. Its like have a single >word to designate everything. This is why we created URN. To distinguish >names (URN) form locators (URL). YOu are right to say that on some browser, >we can implement a name resolver as a protocol handler. But this is caused >by these browsers architecture not by the URN scheme being perceived as a >URL. > Let me get this straight .... *you are* suggesting a mechanism to allow resolution of "urn:...." into a resource, no? Isn't a URI which locates resources a URL (by definition) regardless of the scheme? You are suggesting using the "urn" scheme to locate resources, correct? using some extension to DNS, correct? This is a protocol, no? Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 2 22:06:35 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:44 2004 Subject: SAX Filters (was Re: Announcement: SAX2 1999-06-01 alpha release for Java) In-Reply-To: <37555010.21BD9A81@locke.ccil.org> References: <14163.61975.304542.267110@localhost.localdomain> <14165.8743.130039.285638@localhost.localdomain> <37555010.21BD9A81@locke.ccil.org> Message-ID: <14165.36517.8304.868228@localhost.localdomain> John Cowan writes: > I suggest you look at my P.D. code at > http://www.ccil.org/~cowan/XML/ParserFilter.java; it would be easy > to enhance it for SAX2, and it handles some subtle points. ccil.org doesn't seem to be responding right now -- I will be happy to do a code merge, but in the meantime, I think that a brief list of some of the subtleties that John's class handles would be very appropriate for an XML developers' list (the list doesn't have to come from John). Thanks, and all the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Wed Jun 2 22:40:14 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:44 2004 Subject: Just require URLs In-Reply-To: <049e01bead2a$591d59c0$0b2e249b@fileroom.Synapse> Message-ID: Hi JOnathan, Jonathan said: Let me get this straight .... *you are* suggesting a mechanism to allow resolution of "urn:...." into a resource, no? Isn't a URI which locates resources a URL (by definition) regardless of the scheme? You are suggesting using the "urn" scheme to locate resources, correct? using some extension to DNS, correct? This is a protocol, no? Didier says: I do not suggest anything. URN have been created to allow some permanency to resource identity. IN the WG we discussed lengthily about the fact that location independence leads to permanency. It is explicitly stated in specs and drafts that URNs could be resolved into one or more URL with a name resolver. Ron, presented a name resolver based on DNS. The spec do not restrict the name resolution to solely DNS servers. You can create your own name resolver or use one like for instance LDAP. URN is not a protocol. However, because some browsers recognize the first string before the ":" as a protocol. On these kind of browsers you can implement a URN name resolver by implementing a protocol handler. Actually, two browser have this characteristic: Mozilla, IE (I don't know for others). But, it is only an implemention trick because a URN is not a protocol. Thus, on Mozilla or IE, we can create a LDAP based URN name resolver implemented as a protocol handler for the protocol "urn" (But urn is not a protocol - this is only an implementation trick). But one fact remains, URN where created to be resolved into one or more URLs and the URLs used to be resolved into resources. URLs have the implicit transport mechanism or protocol indicated by their scheme (off course we can give other meaning to scheme or protocol identifier). URN do not have the protocol or transport mechanism in encoded in it. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Jun 3 02:30:03 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:12:44 2004 Subject: Confusion while implementing the DOM. In-Reply-To: <99060309182300.19989@ripe> Message-ID: <000001bead58$8072ff60$3296fea9@w21tp> > really? > In, w3c's document, the following statements appear. > - this results in all the child nodes of the DocumentFragment being > moved to the child list of this node. > Umm, above "moved" word means what? > copy-and-paste or cut-and-paste? Cut and paste. > The class that I had developed in java has DocumentFragment Object, > and this class's publish() method insert this DocumentFragment into > root Document's any Node. after invoking publish() method, > is it correct this class's DocumentFragment member has no child nodes? > or not. The only purpose of having DocumentFragment in the DOM API is to have children for adoption via insertChild/appendNode. It is just a placeholder for nodes which are 'owned' by a Document but not yet part of the Document tree. > If the original node's of DocumentFragment remained in > DocumentFragment > object, I can change the DocumentFragment's childnode's. huh? They are moved, cut-and-pasted, out of the DocumentFragment and into the target node. > How Current well-known DOM implementaions handles it? > especially OpenXML? *shrug* Best, Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Thu Jun 3 02:16:07 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:12:44 2004 Subject: XHTML DTDs failing in IE5 Message-ID: Hi all, Anyone know why the IE5 parser is telling me that the 'xmlns' attribute defined on the HTML element "should be #FIXED", when I try to use any of the DTDs for XHTML? I'd rather not remove !DOCTYPE from the top of my XHTML documents if I can avoid it, but I can't apply XSL to the documents with it in! Any comments? Is IE5 at fault, or is it true that xmlns should be #FIXED, and so the DTDs are incorrect? Regards, Mark Mark Birbeck Managing Director IED Ltd. 220 Bon March? Centre 442-444 Brixton Road London SW9 8EJ w: http://www.iedigital.net/ t: +44 (171) 501 9502 e: Mark.Birbeck@iedigital.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From abird at seedvr.com Thu Jun 3 02:17:43 1999 From: abird at seedvr.com (Kihyun Yoon) Date: Mon Jun 7 17:12:44 2004 Subject: Confusion while implementing the DOM. References: <000001bead26$921a1d20$3296fea9@w21tp> Message-ID: <99060309182300.19989@ripe> Thu, 03 Jun 1999=BF=A1, Don Park =C0=DB=BC=BA=C7=D1 =B1=DB: >> Andrew Douglas wrote, >> > The standard I've got states that a DocumentFragment is >> > a Node (or at least, it does in the Java headers I've >> > got). That was my mistake, I think. >> >> No mistake. A DocumentFragment *is* a Node. But if you >> try and insert it into the tree, you'll find that a >> conforming implementation will throw a >> HIERARCHY_REQUEST_ERR. > >Actually, inserting a DocumentFragment 'node' into a tree should insert = the >child nodes of the DocumentFragment (leaving it empty). > >HERARCHY_REQUEST_ERR exception should be thrown only if any of the child >nodes can not be inserted. State of the tree after partially sucessful >DocumentFragment insertion is unspecified in the spec. My implementatio= n >revokes the entire operation leaving the tree and the DocumentFragment >unchanged. really? In, w3c's document, the following statements appear. - this results in all the child nodes of the DocumentFragment being moved to the child list of this node. Umm, above "moved" word means what? copy-and-paste or cut-and-paste? The class that I had developed in java has DocumentFragment Object, and this class's publish() method insert this DocumentFragment into=20 root Document's any Node. after invoking publish() method,=20 is it correct this class's DocumentFragment member has no child nodes? or not. If the original node's of DocumentFragment remained in DocumentFragment object, I can change the DocumentFragment's childnode's. How Current well-known DOM implementaions handles it? especially OpenXML? Best, Kihyun Yoon. -- "For the Peace of Hanul, Saram and Ttang." Ki-hyun Yoon, The Tech. Development Devision Director of Seed Virtual Systems Inc. Phone : +82-2-3461-0413 Fax : +82-2-3461-0412 Email : abird@seedvr.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jun 3 09:36:24 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:44 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java In-Reply-To: <14165.8743.130039.285638@localhost.localdomain> References: <14163.61975.304542.267110@localhost.localdomain> <14165.8743.130039.285638@localhost.localdomain> Message-ID: * David Megginson | | 1. Do we need a filter *interface* at all, or can a filter just be a | class that happens to implement Parser, Configurable, | EntityResolver, DTDHandler, DocumentHandler, and ErrorHandler? (In | other words, is it enough to set the parent parser/filter in the | constructor?) I'm more concerned with interoperability than ease of development, really, and a main point is that assemblies of filters should be easy to put together. The trouble with the above is that once the filter is instantiated its position in the assembly is fixed. So I am not satisfied with just setting the event source in the constructor. Another thing is the business with delegation that John mentioned. This monster interface could be reduced somewhat by replacing an interface with a corresponding getInterface method on the filter, returning either the private object or the filter itself. Or we could just reason that the clients of the filter don't need access to its handlers, and do this: public interface Filter extends Parser { public Parser getEventSource(); public void setEventSource(Parser eventSource); public Configurable getConfigurable(); } This ensures that filters can be moved around in the assembly and that they can support configuration if they so wish (and return null if they don't). It also makes it much clearer from the interface what a filter is and does and enables the hiding of the handler implementation(s). As for FilterAdapter (or FilterBase), it could either do what you proposed that filter do above, or be split into an implementation of filter that uses a near cousin of HandlerBase called Propagator or some such. | [org.xml.sax.helpers.FilterAdapter] | | I was thinking of including this class in the next SAX2 | pre-release, if people are interested; I can also distribute it | separately in the mean time. I am definitely interested in seeing it now. And like David I would also like to see John's list of subtle points. For those interested in prior art, Bill la Forge's MDSAX is also very much worth a look: I see that his MDFilters are interfaces that extend Parser, DocumentHandler, DTDHandler, EntityResolver and ErrorHandler, and add a setParser method. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DanekerV at visa.com Thu Jun 3 11:02:28 1999 From: DanekerV at visa.com (Daneker, Vincent) Date: Mon Jun 7 17:12:44 2004 Subject: All this buisiness about namespace URNs... Message-ID: <9B4A09772123D211B61B000629B1B966019F301F@sw620x025> I can see that collisions may occur if attempting to piece together a document (archive) from other documents (archives), each potentially using the same tags for different purposes. There seem to ways to avoid the difficulties. One way would be to continue to use a commonly agreed format for general consumption. Today XML -> HTML is used to allow general access. This doesn't really allow people to use XML to its full potential. So, the development of XML aware applications seems to be a logical step. Currently, IE5 can display raw XML, which isn't particularly appealing, but it can be done. Will Excel or Access in Office 2000 (or tools by any other company, MS is just an example, please don't flame me) allow direct and sensible import of an XML file into their formats? In this case well-formedness is more important than specific tag sets and while the latter can cause trouble it should be relatively easy to overcome. At the very least any puzzling entries it would highlight the difficulties we're speaking about. The blind exchange of data in e-commerce could open a can of worms. However, if I'm engaged in a commercial venture, then I'm going to ensure that you, our valued customer, have everything you need from us to complete your transaction. This means that I'd include something like the element and have that indicate an existing resource that would give the DTD and another for a style sheet. The assumption here is that your connection to us will understand all of that. Hopefully, the XML aware applications will do so. Finally, if engaged in direct EDI, then the partners would either have to be working to a pre-existing standard (not to open that debate again :-)) or would have to agree to one so that the EDI would work. Here is where namespaces would be useful. Alternatively, the partners could come up with their own new set of elements and DTD and map their marked-up information to the new set. I'd suggest that communities of common interest will work out some modus vivendi that may indeed be a namespace. I certainly hope that I haven't completely misunderstood the debate. Please, let me know if I have. regards, Vincent P.S. this is being sent from outlook. It should go out as text/plain, if, however, it arrives as one of those stupid little envelope attachments, please let me know and I'll fix it. Thanks. > -----Original Message----- > From: David Megginson [SMTP:david@megginson.com] > Sent: Wednesday, June 02, 1999 8:08 PM > To: xml-dev@ic.ac.uk > Subject: All this buisiness about namespace URNs... > > Kent Sievers writes: > > > 2) Are we really that worried about collisions? After all, don't > > I usually know (and approve) with whom I am exchanging data? > > Not really, especially if you count HTTP transactions as "exchanging > data", and in the future, I expect that things will get even more > complicated: e-commerce, in particular, pretty much requires an > ability for blind information exchange. > > > All the best, > > > David > > -- > David Megginson david@megginson.com > http://www.megginson.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ldodds at ingenta.com Thu Jun 3 11:53:23 1999 From: ldodds at ingenta.com (Leigh Dodds) Date: Mon Jun 7 17:12:45 2004 Subject: DOM, SAX and Events Message-ID: <000401beada7$27c33200$ab20268a@pc-lrd.bath.ac.uk> Hi, I'm currently using a SAX parser to parse an XML script which drives some application processing. I used SAX as it gave a nice fit with the Java event system. I've layered a lightweight application specific event system on top of SAX so those details are hidden from the application itself. This all works very nicely and is nothing new. However I now realise that I may need to repeat parts of the script, i.e. run a particular section multiple times before continuing. I can't simply copy and paste parts of the XML doc as I don't know a priori how many repetitions are required. I also can't revisit that part of the document because the SAX parser doesn't allow this. So, I'm going to move to a DOM representation and do a tree-walk instead. I can then revisit subtrees whenever required. This should be no problem to implement, but leads me to wonder whether other people have met this same problem, and if so whether it'd be useful to have an event driven interface to the DOM? Basically the interface just involves tree-walking and determining the types of nodes and generating the correct callbacks similar to SAX, albeit at a slightly higher level. Is this something others have encountered? Is it an already solved problem and I've missed something? Cheers, L. ================================================================== "Never Do With More, What Can Be Achieved With Less" ---William of Occam ================================================================== Leigh Dodds Eml: ldodds@ingenta.com ingenta ltd Tel: +44 1225 826619 BUCS Building, University of Bath Fax: +44 1225 826283 ================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bd at internet-etc.com Thu Jun 3 12:06:38 1999 From: bd at internet-etc.com (Brandt Dainow) Date: Mon Jun 7 17:12:45 2004 Subject: XHTML DTDs failing in IE5 In-Reply-To: Message-ID: <000501beada8$88283540$a183bc3e@p300> I think IE5 is correct. I saw the same problem with some DTD's from W3C. My understanding is that #FIXED should preceed a specific value described in chars. Isn't that what a xmlns always contains? Brandt Dainow bd@internet-etc.com Internet Etc Ltd http://www.internet-etc.com >-----Original Message----- >From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On >Behalf Of >Mark Birbeck >Sent: Thursday, June 03, 1999 1:21 AM >To: 'xml-dev@ic.ac.uk' >Subject: XHTML DTDs failing in IE5 > > >Hi all, > >Anyone know why the IE5 parser is telling me that the 'xmlns' attribute >defined on the HTML element "should be #FIXED", when I try to >use any of >the DTDs for XHTML? I'd rather not remove !DOCTYPE from the top of my >XHTML documents if I can avoid it, but I can't apply XSL to the >documents with it in! > >Any comments? Is IE5 at fault, or is it true that xmlns should be >#FIXED, and so the DTDs are incorrect? > >Regards, > >Mark > > > >Mark Birbeck >Managing Director >IED Ltd. >220 Bon March? Centre >442-444 Brixton Road >London >SW9 8EJ >w: http://www.iedigital.net/ >t: +44 (171) 501 9502 >e: Mark.Birbeck@iedigital.net > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Thu Jun 3 12:21:56 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:12:45 2004 Subject: DOM, SAX and Events Message-ID: <93CB64052F94D211BC5D0010A800133170EEC0@wwmess3.bra01.icl.co.uk> > So, I'm going to move to a DOM representation and do a tree-walk > instead. I can then revisit subtrees whenever required. > This should be no problem to implement, but leads me to wonder > whether other people have met this same problem, and if > so whether it'd be useful to have an event driven interface to > the DOM? Absolutely. This was exactly the problem I was trying to solve when I started development of SAXON. Take a look at it, it's on http://home.iclweb.com/icl2/mhkay/saxon.html Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Thu Jun 3 14:20:20 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:12:45 2004 Subject: DOM, SAX and Events References: <000401beada7$27c33200$ab20268a@pc-lrd.bath.ac.uk> Message-ID: <002301beadbb$30b4d6c0$0300000a@cygnus.uwa.edu.au> > So, I'm going to move to a DOM representation and do a tree-walk > instead. I can then revisit subtrees whenever required. > This should be no problem to implement, but leads me to wonder > whether other people have met this same problem, and if > so whether it'd be useful to have an event driven interface to > the DOM? I recently adopted this strategry for FOP (http://www.jtauber.com/fop/) so that it can take a formatting object tree as a DOM Document as well as an XML document. Rather stupidly, the SAX DocumentHandler, FOTreeBuilder, then goes an builds a tree again, but this was the quickest way to get DOM support (which people were asking for). (As an aside: because XT allows you to specify a SAX DocumentHandler to do output, it will be easy for me to attached XT and FOP together---stay tuned for version 0.6.3) JamesT Here's my code (largely pinched from John Cowan, whose version of this is more comprehensive :-) package com.jtauber.fop.apps; // FOP import com.jtauber.fop.fo.FOTreeBuilder; // DOM import org.w3c.dom.Document; import org.w3c.dom.Node; import org.w3c.dom.NamedNodeMap; import org.w3c.dom.Attr; // SAX import org.xml.sax.SAXException; import org.xml.sax.helpers.AttributeListImpl; // Java import java.io.PrintWriter; /** * A FOProcessor that takes a DOM Document, walks the tree, firing events as if a SAX parser * * Instantiate this class with a DOM Document and then run the format method with a PrintWriter the PDF is to be given to * * based on John Cowan's work */ public class DOMProcessor extends FOProcessor { private Document document; // the DOM document /** * create a DOM-driven FOProcessor with the given DOM Document */ public DOMProcessor(Document document) { super(); // set up the FOProcessor this.document = document; } /** * Format the document to PDF on the given PrintWriter * * Most of the ideas in this method come from John Cowan */ public void format(PrintWriter writer) throws FOPException { Node currentNode; AttributeListImpl currentAtts; char[] array = null; // temporary array for making Strings into character arrays currentAtts = new AttributeListImpl(); currentNode = this.document; // start at the document element try { while (currentNode != null) { switch (currentNode.getNodeType()) { case Node.DOCUMENT_NODE: this.treeBuilder.startDocument(); break; case Node.CDATA_SECTION_NODE: case Node.TEXT_NODE: String data = currentNode.getNodeValue(); int datalen = data.length(); if (array == null || array.length < datalen) // if the array isn't big enough array = new char[datalen]; // make a new one data.getChars(0, datalen, array, 0); this.treeBuilder.characters(array, 0, datalen); break; case Node.PROCESSING_INSTRUCTION_NODE: this.treeBuilder.processingInstruction(currentNode.getNodeName(),currentNode .getNodeValue()); break; case Node.ELEMENT_NODE: NamedNodeMap map = currentNode.getAttributes(); currentAtts.clear(); for (int i = map.getLength() - 1; i >= 0; i--) { Attr att = (Attr)(map.item(i)); currentAtts.addAttribute(att.getName(), "CDATA", att.getValue()); } this.treeBuilder.startElement(currentNode.getNodeName(), currentAtts); break; } Node nextNode = currentNode.getFirstChild(); if (nextNode != null) { currentNode = nextNode; continue; } while (currentNode != null) { switch (currentNode.getNodeType()) { case Node.DOCUMENT_NODE: this.treeBuilder.endDocument(); break; case Node.ELEMENT_NODE: this.treeBuilder.endElement(currentNode.getNodeName()); break; } nextNode = currentNode.getNextSibling(); if (nextNode != null) { currentNode = nextNode; break; } currentNode = currentNode.getParentNode(); } } } catch (SAXException e) { throw new FOPException(e.getMessage()); } layoutput(writer); } } xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mirja.hukari at citec.fi Thu Jun 3 14:52:48 1999 From: mirja.hukari at citec.fi (Mirja Hukari) Date: Mon Jun 7 17:12:45 2004 Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux Message-ID: <37567AC8.E48F7A00@citec.fi> First SGML and XML browser on Linux, DocZilla ============================================= CiTEC is proud to announce the first XML and SGML browser on Linux, DocZilla. DocZilla Alpha 2 runs on WinNT/95/98 and Linux. The Linux DocZilla Alpha comes with the Linux HOWTO's (technical documentation created using the LinuxDoc DTD) rendered directly from the original SGML format. The DocZilla XML/SGML Module Alpha 2 extends Mozilla Web technology with enhanced XML support, SGML, HyTime links, CGM graphics, CALS tables, and additional features from CSS2. The DocZilla XML/SGML Module will be a dynamically registered add-on component to the Netscape Gecko browser when it is released. The XML/SGML Module Alpha 2 is now available as a standalone application built with the Mozilla source code with the full web browser capabilities. The XML/SGML Module is the first offering from CiTEC of components for advanced Web publishing. Our next components will include: XML search, publishing tools, and document fragment delivery. The XML/SGML Module Alpha 2 comes with a Demo Kit with many excellent demonstrations of the use of SGML, XML, CSS, DOM, JavaScript, CGM and more with DocZilla. These demos are set up to be viewed with point-and-click simplicity. Visit DocZilla Web page at http://www.doczilla.com for DocZilla Alpha 2 download information. Best regards, Miss DocZilla -- Mirja Hukari tel. +358-6-3240 723 Citec Information Technology fax. +358-6-3240 800 Silmukkatie 2 email. mhu@citec.fi 65100 Vaasa URL: http://www.citec.fi xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Thu Jun 3 15:17:15 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:12:45 2004 Subject: DocZilla Alpha 2 for WinNT/95/98 and Linux References: <37567AC8.E48F7A00@citec.fi> Message-ID: <003501beadc3$334a7c20$0300000a@cygnus.uwa.edu.au> I guess it would be trolling to ask if XSL support is planned. (Sorry, I couldn't resist :-) James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jun 3 15:53:53 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:45 2004 Subject: DOM, SAX and Events In-Reply-To: <000401beada7$27c33200$ab20268a@pc-lrd.bath.ac.uk> References: <000401beada7$27c33200$ab20268a@pc-lrd.bath.ac.uk> Message-ID: * Leigh Dodds | | So, I'm going to move to a DOM representation and do a tree-walk | instead. I can then revisit subtrees whenever required. This should | be no problem to implement, but leads me to wonder whether other | people have met this same problem, and if so whether it'd be useful | to have an event driven interface to the DOM? John Cowan has a DOMParser that walks a DOM tree and fires SAX events at Also, one strategy I've used in cases where the area that needs to be repeated is very small is to simply record the SAX events in a vector and do a sort of playback. (Used this to implement a general SAX DocumentHandler that chooses between several different DocumentHandlers based on the name of the document element.) --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at metalab.unc.edu Thu Jun 3 15:59:48 1999 From: elharo at metalab.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:12:45 2004 Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux In-Reply-To: <37567AC8.E48F7A00@citec.fi> Message-ID: I notice that DocZilla is not free. May I then assume that it doesn't use any Mozilla code? +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | Java I/O (O'Reilly & Associates, 1999) | | http://metalab.unc.edu/javafaq/books/javaio/ | | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Thu Jun 3 16:02:20 1999 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:12:45 2004 Subject: XHTML DTDs failing in IE5 In-Reply-To: Mark Birbeck's message of Thu, 3 Jun 1999 01:21:04 +0100 Message-ID: <199906031404.PAA02679@stevenson.cogsci.ed.ac.uk> > Any comments? Is IE5 at fault, or is it true that xmlns should be > #FIXED, and so the DTDs are incorrect? The Namespaces recommendation does not require it; Microsoft have decided that it does not make sense to allow a declared element type to be used to refer to elements in different namespaces, and they enforce this by requiring xmlns attributes to be declared as #FIXED. Furthermore, they do not allow you to declare prefixed element types or attributes unless you also declare an xmlns attribute for the prefix. This is also not in the standard. Andrew Layman posted a message about this a couple of weeks ago; it's archived as http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-May-1999/0394.html He points out: if you want to use the DTD to validate an instance, you must use exactly the same prefixes in the instance as were used in the DTD. This is true, but it doesn't seem to me to be a good reason to reject namespace-conformant documents. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jun 3 16:31:30 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:45 2004 Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux In-Reply-To: References: <37567AC8.E48F7A00@citec.fi> Message-ID: <14166.37316.938922.20789@localhost.localdomain> Elliotte Rusty Harold writes: > I notice that DocZilla is not free. May I then assume that it > doesn't use any Mozilla code? I'll have to reread the Mozilla Public License, but I don't think that there's anything to prevent a closed-source, commercial product from embedded Mozilla, as long as any changes to the Mozilla code itself are made public. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Thu Jun 3 16:34:39 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:45 2004 Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux In-Reply-To: Message-ID: Hi Eliotte You said I notice that DocZilla is not free. May I then assume that it doesn't use any Mozilla code? Didier says: Contrary to that - it uses Mozilla code. Do you say that because of the Mozilla licence? regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From heikki at citec.fi Thu Jun 3 17:00:56 1999 From: heikki at citec.fi (Heikki Toivonen) Date: Mon Jun 7 17:12:45 2004 Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux In-Reply-To: <14166.37316.938922.20789@localhost.localdomain> Message-ID: <003301beadd1$f7505640$2500a8c0@hto.citec.fi> > I'll have to reread the Mozilla Public License, but I don't think that > there's anything to prevent a closed-source, commercial product from > embedded Mozilla, as long as any changes to the Mozilla code itself > are made public. Actually not "public public". The license says you must make Modifications available in source form to the users of your product. One common misunderstanding about the NPL is that you should give the source back to Netscape. That is not true (unless NS happens to use your product). Because you are only required to make Modifications available you can hide the bulk of your code in modules you do not need to disclose. You will just need simple hooks in the mainline code. -- Heikki Toivonen http://www.doczilla.com http://www.citec.fi xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Thu Jun 3 19:20:19 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:12:45 2004 Subject: XHTML DTDs failing in IE5 Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF659@RED-MSG-08> Richard Tobin in http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Jun-1999/0185.html cites my earlier message http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-May-1999/0394.html describing the fairly restrictive rules that the IE5 MSXML parser enforces for use of namespaces and DTDs. I want to emphasize that my earlier message was intended to clarify what the actual behavior of MSXML is, not to describe what the best behavior should be. In this list and in others, there have been strong and conflicting opinions expressed on what would be the best behavior of a parser, and no settled standard exists. I believe that people will continue to post opinions on what a parser should do. I do not, in fact, know that the IE5 rules are the ultimately best rules; what we can say in their favor is that because they are conservative, they do not encourage the creation of documents that are accepted by MSXML and yet are later rejected by conformant parsers after standards have been worked out. As we are gaining experience with namespaces, this seems a prudent course. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ngill at eecs.uic.edu Thu Jun 3 19:39:09 1999 From: ngill at eecs.uic.edu (Navreena Gill) Date: Mon Jun 7 17:12:45 2004 Subject: & in the element Message-ID: Hello List, Is it not possible to have & in the node value of an element like the one: AT&T My corresponding dtd has data defined as While parsing it using SUN parser gives me error: Illegal character or entity reference syntax. I do need to have & in the value for lots of elements. Can any one suggest me some alternative. I cannot change the xmls, since these are generated by some other application. I can only modify dtd. I would appreicate some help. Thanks a lot in advance. Navreena xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 3 20:01:12 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:45 2004 Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux References: <37567AC8.E48F7A00@citec.fi> <14166.37316.938922.20789@localhost.localdomain> Message-ID: <3756C306.EC24A9FB@locke.ccil.org> David Megginson wrote: > I don't think that > there's anything to prevent a closed-source, commercial product from > embedded Mozilla, as long as any changes to the Mozilla code itself > are made public. That is exactly what distinguishes the MPL from the BSD/MIT/etc. license on the one hand ("do as thou wilt") and from the GPL on the other ("all derivative works must be GPLed too"). Netscape Communicator 5, if and when it appears, will be the main such product, of course, but others can be made. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Thu Jun 3 20:05:17 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:12:45 2004 Subject: & in the element Message-ID: <01BEADCA.BF6949A0@cc398234-a.etntwn1.nj.home.com> Navreena wrote: "Is it not possible to have & in the node value of an element like the one: AT&T" Navreena, Each occurrence of "&" in the application data must be encoded as "&" in the XML file. For example, AT&T Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Orr at Design-Intelligence.com Thu Jun 3 20:11:28 1999 From: Michael.Orr at Design-Intelligence.com (Michael.Orr@Design-Intelligence.com) Date: Mon Jun 7 17:12:46 2004 Subject: DocZilla Alpha 2 for WinNT/95/98 and Linux Message-ID: <4454C011BDE5D211B6C800609776E5400F1797@master.design-intelligence.com> > From: Mirja Hukari [mailto:mirja.hukari@citec.fi] > Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux Your announcement is specifically addressed to 95/98 users as well as NT/Linux, but the installer pops up an *extremely* strongly worded warning to the effect that it would be extremely foolish to go ahead with the install on 95/98. What's your recommendation for us 95/98 users? Thanks, Mike ---------------------------------------- Michael Orr, CTO, VP R&D Design Intelligence Inc, Seattle WA USA http://www.design-intelligence.com phone:206-718-2103 fax:206-343-7750 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From carl at chage.com Thu Jun 3 20:16:17 1999 From: carl at chage.com (Carl Hage) Date: Mon Jun 7 17:12:46 2004 Subject: All this buisiness about namespace URNs... In-Reply-To: <9B4A09772123D211B61B000629B1B966019F301F@sw620x025> Message-ID: <199906031818.NAA19820@rgate2.ricochet.net> From: "Daneker, Vincent" > So, the development of XML aware applications seems to be a logical step. > Currently, IE5 can display raw XML, which isn't particularly appealing, > but it can be done. Will Excel or Access in Office 2000 (or tools by any > other company, MS is just an example, please don't flame me) allow direct > and sensible import of an XML file into their formats? Thanks for bringing things back to reality-- that's the whole point of XML (it's not really a scheme to force purchase of upgrades). Besides general office software, sensible import into applications like Quicken will also be important. In order for import to be sensible, the application software needs to be able to interpret the format and semantics (to a certain degree) for each tag read. That means the application needs to get more information than just the syntax of the DTD. The URI's referenced in the XML headers and DTD are a natural way for applications to access the information needed for a sensible import, and as a sensible means for humans to access the documentation about the data. After you load an XML file into a spreadsheet, database, or XSL transformed data entry form, you want the "Help" button to work properly and directly show the definition of that data. You don't want to write to Geneva and buy a $900 document, or track down a programmer to find the meaning of a field. > The blind exchange of data in e-commerce could open a can of worms. > However, if I'm engaged in a commercial venture, then I'm going to ensure > that you, our valued customer, have everything you need from us to > complete your transaction. Unfortunately, that's not the norm. Missing or ambiguous documentation and missing code values is quite common. For every vendor or customer, the software is modified since the "standards" aren't really standards. Data exchange these days is often in fixed length files (it's hard to get mainframe programmers to create tab-delimited), where the postal- mailed data file is accompanied by a paper containing the documentation-- a list of abbreviated field names with columns. You retype all the columns into a computer (or scan and OCR the paper, then write a perl program to extract the record format). In about 40% of the cases, the documentation has errors. When you don't understand the field name semantics, you call the owner of the data, and often, they have no idea either. XML could be a continuation of the nightmare, since it allows any writer of data to invent a new DTD. Data should be written so it can be imported (not just exported), meaning it must be transformed into some agreed upon standard which can be interpreted. XML today is incrementally better than the usual fixed-length flat file with faxed record format in that it at least has an electronic definition of the syntax of the data. In my opinion XML won't be significant until all data that exists has associated electronic definitions of the semantics as well as syntax. Style sheets that print the data are incomplete-- there needs to be style sheets to print the documentation of the data as well, e.g. so the context sensitive help in a data entry form functions properly. Likewise, if I type a value into a form from a controlled vocabulary, e.g. "California" or "CA", the spreadsheet or browser should be able to access the CV definitions to validate that entry, without having to create/modify software, download some Java (that works in only 1 application), etc. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Thu Jun 3 20:23:52 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:12:46 2004 Subject: & in the element Message-ID: <01BEADCD.52771770@cc398234-a.etntwn1.nj.home.com> Navreena, I forgot to mention: Each "<" in the application data must be encoded as "<" in the XML. For example, 4 < 5 and 6 > 5 You can also use a CDATA section for text that contains "&" or "<" characters. For example: Note that if any of your attribute values contain "&" or "<" characters, then they have to be encoded as well. For example, ... Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.S.Brothers at EMCIns.Com Thu Jun 3 20:23:03 1999 From: Michael.S.Brothers at EMCIns.Com (Michael S. Brothers) Date: Mon Jun 7 17:12:46 2004 Subject: All this buisiness about namespace URNs... In-Reply-To: <14165.32954.596890.457@localhost.localdomain> Message-ID: On Wed, 02 Jun 1999 15:08:29 -0400 (EDT) David Megginson wrote: > Kent Sievers writes: > > > 2) Are we really that worried about collisions? After all, don't > > I usually know (and approve) with whom I am exchanging data? > David Megginson reply: > Not really, especially if you count HTTP transactions as "exchanging > data", and in the future, I expect that things will get even more > complicated: e-commerce, in particular, pretty much requires an > ability for blind information exchange. > This being where an industry-wide standards organization fills the void and develops the elements, attributes, etc., for all entities doing business in that industry. If such DTD's (x-schema's, whatever) are in place, communication within the industry would be seamless. The complication arises when trying to exchange data outside the industry. That's why I fall into the camp of having the namespace designator actually point to a document that is retrievable and explains the data being sent. Take Care, ---------------------- Michael S. Brothers Michael.S.Brothers@EMCIns.com 515-362-7473 At this point, I don't think that's the best option. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 3 20:31:48 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:46 2004 Subject: & in the element References: Message-ID: <3756CA77.68DD0F66@locke.ccil.org> Navreena Gill wrote: > Is it not possible to have & in the node value of an element like the > one: > AT&T > My corresponding dtd has data defined as > > > While parsing it using SUN parser gives me error: > Illegal character or entity reference syntax. > I do need to have & in the value for lots of elements. Can any one suggest > me some alternative. I cannot change the xmls, since these are generated > by some other application The other application is in error, and is simply not generating XML at all. Complain upstream; no amount of DTD-fiddling will help you. It should be generating "AT&T". Alternatively, insert a filtering process just before your input that maps every "&" to "&". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Thu Jun 3 20:39:27 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:12:46 2004 Subject: XHTML DTDs failing in IE5 Message-ID: Brandt Dainow wrote: > I think IE5 is correct. I saw the same problem with some > DTD's from W3C. > My understanding is that #FIXED should preceed a specific > value described in > chars. Isn't that what a xmlns always contains? I think I agree, Brandt. However, the DTDs for XHTML simply have xmlns as a URI that is required, but only say what that namespace is in the comments. Nowhere is it actually 'defined'. It's annoying because if I remove the DOCTYPE declaration to get past the parser, then I lose the ability to use ' ' and such-like. Thanks for your reply, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ngill at eecs.uic.edu Thu Jun 3 20:46:58 1999 From: ngill at eecs.uic.edu (Navreena Gill) Date: Mon Jun 7 17:12:46 2004 Subject: In cont. of & in element Message-ID: Thanks a lot for replying to my question regarding & in an element's value. I have been trying to read REC-xml-199.. of W3C to get list of such forbidden characters. Looks like & < ' " %. But I do not get any problem with ', ", %. The & < gave errors. Am I correct about this, or missing something trivial here. The REC-xml-... document seems to be very confusing to me, may be because I am new to xml. I was offered suggestion to use CDATA for using & in the value. What is CDATA? Does it represent some default value? Thanks a lot in advance. Navreena xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 3 21:15:51 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:46 2004 Subject: XHTML DTDs failing in IE5 In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAF659@RED-MSG-08> Message-ID: <199906031917.PAA32650@hesketh.net> At 10:21 AM 6/3/99 -0700, Andrew Layman wrote: >I want to emphasize that my earlier message was intended to clarify what the >actual behavior of MSXML is, not to describe what the best behavior should >be. In this list and in others, there have been strong and conflicting >opinions expressed on what would be the best behavior of a parser, and no >settled standard exists. I believe that people will continue to post >opinions on what a parser should do. I do not, in fact, know that the IE5 >rules are the ultimately best rules; what we can say in their favor is that >because they are conservative, they do not encourage the creation of >documents that are accepted by MSXML and yet are later rejected by >conformant parsers after standards have been worked out. As we are gaining >experience with namespaces, this seems a prudent course. Perhaps I'm just confused, but this seems to privilege the namespaces rec way above the XML 1.0 rec. Not only that, but #FIXED as a requirement for namespace attribute declarations doesn't appear anywhere in the Namespaces rec. Rather than being conservative, I'd have to call this fairly radical. It may seem grotesque to let people override the declarations in the document, but I don't think it's that impossible to come up with cases where it might actually be useful, and I can't see any reason why #FIXED declarations should be mandatory. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 3 21:18:51 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:46 2004 Subject: In cont. of & in element References: Message-ID: <3756D586.7C6580FD@locke.ccil.org> Navreena Gill wrote: > Thanks a lot for replying to my question regarding & in an element's > value. I have been trying to read REC-xml-199.. of W3C to get list of > such forbidden characters. Looks like & < ' " %. % is only an issue within DTDs, not within document instances. ' and " are an issue only in attribute values that are enclosed in ' and " respectively. < and & are a problem everywhere. > I was offered suggestion > to use CDATA for using & in the value. What is CDATA? You can suppress the special meaning of all characters within document content (not attribute values) by enclosing them in the special quotation marks "". Of course, the appearance of "]]>" within your data will screw even this up. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Thu Jun 3 21:21:41 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:12:46 2004 Subject: XHTML DTDs failing in IE5 Message-ID: Richard Tobin wrote: > Andrew Layman posted a message about this a couple of weeks ago; it's > archived as > > > http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-May-1999/0394.html > > He points out: > > if you want to use the DTD to validate an instance, you must use > exactly the same prefixes in the instance as were used in the DTD. Thanks for that Richard - I missed that. However, without raising the good old namespace debate again ;) - this seems unnecessarily restrictive. I can't see how DTDs get involved in namespaces *as such* (or rather how namespaces get involved in DTDs). I can see how if I want to have two elements with the same name I can differentiate them with a namespace prefix, like ns1:elem and ns2:elem. But as far as validation is concerned, won't the following two examples pass (even in a non-namespace aware parser)? DTD: XML 1: Hello mum XML 2: Hello mum If I understand Andrew correctly then this is what he means when he says you "must use exactly the same prefixes" - the ns1 and ns2. But why does this mean that the value of 'xmlns' has to be #FIXED? Surely at the level of validation it doesn't matter what the namespace value is - and it's debatable as to whether the concept of namespaces even exists at the level of validation as currently understood, with XML 1.0 + namespaces (XML-Data is different, see below). So, my question is, have MS made something part of validation (as currently defined) which doesn't belong there? If an application really must have the correct namespace defined for it to process the data correctly (after parsing) then it always has the option of defining a DTD that says the namespace must be set to this value. In my above example this could be: and then 'XML 2' would correctly fail. But shouldn't this be an option, not a requirement? The alternative is to say that one DTD is always bound to one namespace. For example, the MS version would prevent me having: DTD: checksum #CDATA #IMPLIED > Hello mum Hello mum which uses the same DTD to validate two lots of data, but indicates that they are to be processed (after parsing) in a different way. As far as I can see from XML 1.0 and the namespace spec this is perfectly acceptable. To bring it back to XHTML, if the W3C is saying that any XHTML processing tool such as a browser needs the namespace set correctly so that it can pick out the correct bits of the document, then yes, the 'xmlns' value must be #FIXED. But if I want to say, here is a document that has a namespace, and although that namespace might change as I develop my applications, a document that uses a previous version of the namespace should still be valid By the way, I recognise that none of what I have said applies to Microsoft's first-cut of schemas constructed from XML which is part of the IE5 parser. In this case the prefix is genuinely a place-holder and the actual underlying URI is significant. But in that case they have implemented 'proper' namespace support in validation, i.e. all the following documents are effectively the same: Hello mum and Hello mum and Hello mum Maybe that's the root of the problem - that features from the schema type of validation have crept into the DTD type? Any thoughts? Regards, Mark PS In the meantime, what are people doing to get round this? Does no-one use any of the W3C DTDs with the MS parser? Do you just use different parsers or have you all copied the DTDs locally and edited them? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ksievers at novell.com Thu Jun 3 22:27:44 1999 From: ksievers at novell.com (Kent Sievers) Date: Mon Jun 7 17:12:46 2004 Subject: All this buisiness about namespace URNs... Message-ID: It amuses me to see how far off topic my posting got. And so quickly. With everyone fixating on a poorly worded clause of mine, I though I better try again, to see if I could improve on my rambling. This time, I will pose it as 3 simplified questions: 1) If (as has ben debated on this list) we are worried about URLs because they are not unique and change over time and do not have "ownership" without adding the HTTP protocol, then why don't we invent an ID for name spaces that IS globally unique? 2) Are we really that worried about collisions? If I just used "mynamespace.myproject.Novell.com" as a name space ID, what are the odds that I will ever see any accidental collisions? And if someone intends to collide with me, then what recourse would I have with any other identifier? 3) Why isn't our name space identifier two parts: 1) the name spaces name/ID that uniquely identifies it, and 2) the last known, or probable location of the information about the name space. The advantages of this are: a) I can still uniquely identify the name space no matter where it is moved, b) I can retrieve information about the name space and c) if that information is moved, there may be some hope of searching for it and updating it's location. Think of it as an ID/URL combination with the URL part optional, but a true URL. >>> "Michael S. Brothers" 06/03/99 12:26PM >>> On Wed, 02 Jun 1999 15:08:29 -0400 (EDT) David Megginson wrote: > Kent Sievers writes: > > > 2) Are we really that worried about collisions? After all, don't > > I usually know (and approve) with whom I am exchanging data? > David Megginson reply: > Not really, especially if you count HTTP transactions as "exchanging > data", and in the future, I expect that things will get even more > complicated: e-commerce, in particular, pretty much requires an > ability for blind information exchange. > This being where an industry-wide standards organization fills the void and develops the elements, attributes, etc., for all entities doing business in that industry. If such DTD's (x-schema's, whatever) are in place, communication within the industry would be seamless. The complication arises when trying to exchange data outside the industry. That's why I fall into the camp of having the namespace designator actually point to a document that is retrievable and explains the data being sent. Take Care, ---------------------- Michael S. Brothers Michael.S.Brothers@EMCIns.com 515-362-7473 At this point, I don't think that's the best option. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Jun 3 23:27:55 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:12:46 2004 Subject: XHTML DTDs failing in IE5 Message-ID: <3.0.32.19990603143004.011ee890@pop.intergate.bc.ca> At 03:21 PM 6/3/99 -0400, Simon St.Laurent wrote: >It may seem grotesque to let people override the declarations in the >document, but I don't think it's that impossible to come up with cases >where it might actually be useful, and I can't see any reason why #FIXED >declarations should be mandatory. I'd agree. I think IE5 is clearly wrong here. On the other hand, Andrew is correct in saying that the microsoft approach is the maximally-cautious one, and probably quite defensible in what is effectively a release 1.0 product. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Thu Jun 3 23:53:20 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:46 2004 Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux In-Reply-To: <14166.37316.938922.20789@localhost.localdomain> Message-ID: Hi David, David said: I'll have to reread the Mozilla Public License, but I don't think that there's anything to prevent a closed-source, commercial product from embedded Mozilla, as long as any changes to the Mozilla code itself are made public. Didier says: You are right. As you know, Mozilla is made of XPCOM component. Il can make a new package by replacing an existing XPCOM component or adding a XPCOM component to the existing ones. In a certain way, you sell your component, everything else is free. Its like making a car out of component where 99% of the components are provided by a car component manufacturer and you charge 50 000$ for the mirror :-). So yes you can right we can do that as long as we don't modify the components made by mozilla group or if we do, we give back the modified component. But this constraint is not applied to our components. Regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Fri Jun 4 01:04:45 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:12:46 2004 Subject: Topic Maps Workshops Message-ID: <199906032238.RAA02867@bruno.techno.com> Two special workshops on T O P I C M A P S (ISO/IEC 13250) Instructors: Michel Biezunski and Steven R. Newcomb (both co-editors of 13250) June 21-22 June 24-25 Bellevue, Washington Dallas, Texas USD $1,400 per participant ----------------------------------------------- Registrations: Michele Budz michele@isogen.com +1 214 953 0004 x124 See http://www.infoloom.com/workshop.htm for details. ----------------------------------------------- ISOGEN International Corporation Infoloom TechnoTeacher Inc. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jkuan at infoserve.net Fri Jun 4 07:36:18 1999 From: jkuan at infoserve.net (Jami Kuan) Date: Mon Jun 7 17:12:46 2004 Subject: XML parser problem related to Steven Holzner's code in XML Complete Message-ID: <001101beae4c$b75fa9c0$611652d1@jkuan> Greetings, I'm new comer to the subject of XML, and the first book I read in XML is Steven Holzner's XML Complete. His book is quite easy to follow, but unfortunatly, many changes have taken place since it was published, and I am having trouble to get started, even running some of the samples codes in the book. In many of the java files (Steven used Java mostly), the following three lines are present: import com.ms.xml.ParseException; import com.ms.xml.Document; import com.ms.xml.Element; Whenever I try to run a file with those three lines in it, a class definition not found error is given. According to the book, there is a file called xmlinst.exe avail. from http://www.microsoft.com/standards/xml/xmlparse.htm. Once I ran xmlist, the microsoft COM Java package will be installed, and I was supposed to drag the COM folder into the Java\classes directory in Win Explorer so that the Java programs can find the parser class easily. However, Microsoft has reorganized the web site, and the parser is now integrate into the VM. I downloaded and installed the SDK 3.2, JVM build 3181, and the two class files, but I still get the same errors. According to the book, the following major MSXML classes are used in the sample codes: com.ms.xml.Element com.ms.xml.ElementFactory com.ms.xml.Attribute com.ms.xml.Document com.ms.xml.ParseException Could you please give me some ideas as how to set up my development environment so that I could get started? Thanks very much, James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990604/0536ca9e/attachment.htm From heikki at citec.fi Fri Jun 4 08:50:36 1999 From: heikki at citec.fi (Heikki Toivonen) Date: Mon Jun 7 17:12:46 2004 Subject: DocZilla Alpha 2 for WinNT/95/98 and Linux In-Reply-To: <4454C011BDE5D211B6C800609776E5400F1797@master.design-intelligence.com> Message-ID: <004201beae56$a0033da0$2500a8c0@hto.citec.fi> > Your announcement is specifically addressed to 95/98 users as well as > NT/Linux, but the installer pops up an *extremely* strongly worded warning > to the effect that it would be extremely foolish to go ahead with the > install on 95/98. > > What's your recommendation for us 95/98 users? The only problem (although a bad one!) I know of that is specific to Win95/98 are images on your own HD (or maybe LAN disk as well). So for example if you install DocZilla and try the demos from your HD the images come up *extremely* slow. If you try the *exact* same demos on our website there is no such problems. -- Heikki Toivonen http://www.doczilla.com http://www.citec.fi xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Fri Jun 4 09:02:48 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:12:47 2004 Subject: XHTML DTDs failing in IE5 Message-ID: Andrew Layman wrote: > In this list and in others, there have been strong and conflicting > opinions expressed on what would be the best behavior of a parser, and no > settled standard exists. I believe that people will continue to post > opinions on what a parser should do. Sorry. If you were trying to pre-empt more debate ... too late, I've sent it off! > I do not, in fact, know that the IE5 rules are the ultimately best rules; > what we can say in their favor is that because they are conservative, > they do not encourage the creation of documents that are accepted by > MSXML and yet are later rejected by conformant parsers after standards > have been worked out. I'm sure that raised a few smiles! As it happens, your approach is worse than useless. If in the future the value of 'xmlns' is actually part of determining whether a document is valid or not, then so be it. DTDs will need to change. But that also goes for XLink, fragments, XML-Data and more. The fact is that as far as I can tell, at the moment there is nothing in XML 1.0 or the namespace spec that says the value of a namespace MUST be fixed. Yet because Microsoft have decided they should be - and many may agree - I am now unable to get perfectly valid DTDs, over which I have no control, past your parser. This is not conservative ... it is WRONG. What really amazes me is why you have picked this feature to be restrictive on. Microsoft have happily issued an implementation of XML-Data that we all know will have to change, as well as an implementation of XSL that has changed already and will have to change again. I don't mind that - I accept that things are still evolving. In fact I'm very grateful for having the chance to build a test system around XML-Data, even though I know it will all change. It's even got to the point where for our own purposes I don't even use DTDs anymore - I automatically generate schemas from my database and use your excellent parser. But your misplaced paternalism is now preventing me from doing real work with information from people who still DO use DTDs - like the W3C, for example! I want to apply XSL to XHTML, and I can only think that to do it I will have to change parsers (unless you tell me there is a secret switch somewhere, to turn this ridiculous 'feature' off). Mark Birbeck Managing Director IED Ltd. 220 Bon March? Centre 442-444 Brixton Road London SW9 8EJ w: http://www.iedigital.net/ t: +44 (171) 501 9502 e: Mark.Birbeck@iedigital.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Fri Jun 4 10:22:49 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:47 2004 Subject: Confusion while implementing the DOM. Message-ID: Don Park wrote, > Miles Sabin wrote, > > But if you try and insert it into the tree, you'll > > find that a conforming implementation will throw a > > HIERARCHY_REQUEST_ERR. > > Actually, inserting a DocumentFragment 'node' into a > tree should insert the child nodes of the > DocumentFragment (leaving it empty). Oops, how embarrasing, particularly since ... > HERARCHY_REQUEST_ERR exception should be thrown only if > any of the child nodes can not be inserted. State of > the tree after partially sucessful DocumentFragment > insertion is unspecified in the spec. My > implementation revokes the entire operation leaving the > tree and the DocumentFragment unchanged. ... that's exactly how _my_ implementation behaves too! How could I forget. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From heikki at citec.fi Fri Jun 4 11:06:41 1999 From: heikki at citec.fi (Heikki Toivonen) Date: Mon Jun 7 17:12:47 2004 Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux In-Reply-To: <5F052F2A01FBD11184F00008C7A4A800022A1959@eukbant101.ericsson.se> Message-ID: <004f01beae69$9f038640$2500a8c0@hto.citec.fi> > And you also have a common misconception: The code that you > have to give to your users has to be given under the NPL (or > MPL). This means they are free to re-distribute that source code > to whoever they like (i.e. there's no point in keeping your > source code modifications private to just you and your users - > you can't stop them putting it on a public ftp server). I found > this out by discussing the issue with a Netscape lawyer on > netscape.public.mozilla.licence I know that. The code that is a Modification as explained in the license falls under NPL (or MPL if that is what the original file used). That code must be made available to your user, not everybody. The user is then free to do whatever they want with the source, under the NPL or MPL. As you pointed out, they can post it to a public ftp site if they want. But the code is not automatically "public public" as in some other licensies. There is a certain difference between CAN and MUST. The code you develop that does not fall under NPL or MPL is nobody's business but yours. NPL and MPL are different from GPL for a good reason. I've already seen product releases that use the Mozilla Public License that have nothing to do with Mozilla or Netscape. But this is getting off topic... -- Heikki Toivonen http://www.doczilla.com http://www.citec.fi xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Fri Jun 4 11:18:23 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:12:47 2004 Subject: ANN: DocZilla Alpha 2 for WinNT/95/98 and Linux Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A1959@eukbant101.ericsson.se> > -----Original Message----- > From: Heikki Toivonen [SMTP:heikki@citec.fi] > > > I'll have to reread the Mozilla Public License, but I don't think that > > there's anything to prevent a closed-source, commercial product from > > embedded Mozilla, as long as any changes to the Mozilla code itself > > are made public. > > Actually not "public public". The license says you must make Modifications > available in source form to the users of your product. One common > misunderstanding about the NPL is that you should give the source back to > Netscape. That is not true (unless NS happens to use your product). > And you also have a common misconception: The code that you have to give to your users has to be given under the NPL (or MPL). This means they are free to re-distribute that source code to whoever they like (i.e. there's no point in keeping your source code modifications private to just you and your users - you can't stop them putting it on a public ftp server). I found this out by discussing the issue with a Netscape lawyer on netscape.public.mozilla.licence Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jun 4 12:01:51 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:47 2004 Subject: XHTML DTDs failing in IE5 In-Reply-To: <3.0.32.19990603143004.011ee890@pop.intergate.bc.ca> References: <3.0.32.19990603143004.011ee890@pop.intergate.bc.ca> Message-ID: * Tim Bray | | I'd agree. I think IE5 is clearly wrong here. On the other hand, | Andrew is correct in saying that the microsoft approach is the | maximally-cautious one, and probably quite defensible in what is | effectively a release 1.0 product. I find it interesting to note that if one requires all xmlns attributes to be #FIXED we have an implementation of namespaces that is effectively equivalent to the original processing instruction draft. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ben at mitra.com Fri Jun 4 15:22:52 1999 From: ben at mitra.com (Ben Hui) Date: Mon Jun 7 17:12:47 2004 Subject: xsl editor needed Message-ID: <000301beae8d$a2f0e2b0$9607a8c0@mitra.com> hi all I am trying to find a nice GUI XSL editor to greate XSL file. I tried XML Styler, i find it too difficult to use. Are the any alternative I can pick from?? Thanks As a note, for those people who are involved in XSL development, I really don't know how they write XSL document... notepad? anyway, they are hero to me :) Ben Hui xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 4 15:47:59 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:47 2004 Subject: XHTML DTDs failing in IE5 References: <3.0.32.19990603143004.011ee890@pop.intergate.bc.ca> Message-ID: <3757D970.6D68F88E@locke.ccil.org> Lars Marius Garshol wrote: > I find it interesting to note that if one requires all xmlns > attributes to be #FIXED we have an implementation of namespaces that > is effectively equivalent to the original processing instruction draft. I don't think so. The PI version did not allow local-scope declarations, whereas #FIXED attributes are local to the element they are declared as belonging to. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shecter at darmstadt.gmd.de Fri Jun 4 18:16:29 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:12:47 2004 Subject: Paul has volunteered (was Re: Overloaded URIs must GO!) References: <805C62F55FFAD1118D0800805FBB428D0106AE9A@cc20exch2.mobility.com> <14162.43529.767446.988311@localhost.localdomain> <009e01beabbe$40c5e6c0$0300000a@cygnus.uwa.edu.au> Message-ID: <3757FC09.F442A45B@darmstadt.gmd.de> James Tauber wrote: > ...What I am suggesting is that if one has the right > to > > http://www.sprynet.com/megginson/MyNamespace > > then one has the right to: > > hname://www.sprynet.com/megginson/MyNamespace > > The only difference is one is explicitly stating in the latter that it is > irretrievable. > This sounds very reasonable, but I haven't seen any responses. And, combining it with Didier's comments about characters to avoid, it could look like this: urn:hname:www:sprynet:com:megginson:MyNamespace ...Which looks even less URL-like. So, we can all agree that the rights are based on some protocol like HTTP, but when we write it out, we write it in such a way that it isn't misleading. I don't think it matters what the fine print of the standards say, because writing something like "http://..." "means" that something can be retrieved, and is very specific about how. It's just confusing, and saying something that's not true. Personally, I think it'd be even better to use email addresses as the "protocol to which we have rights", instead of webspace: - We all have "rights" to the space, and the references are unique, BUT, there's no chance that someone will think they can retrieve something there. If anything, there's an implied contact address which could be used to make a request to. - They'd be longer lasting. As a private person, my acm.org email address is guaranteed for life (?), but I don't have any such guarantees from orgs where I have private webspace. Also, URLs seem to get shuffled around more than email addresses. - There's more flexibility in making the right choice. Most people have several email addresses, and can base a namespace on the one whose lifetime and organizational associations are appropriate for the particular situation. Organizations can use e-mail aliases to make abstracted spaces not tied to any person, etc. This is something that people are already familiar with, and can be done with current technology. So, this would mean something along the lines of: urn:hname:org:acm:robb@:MySpace1 Just brainstorming, - Robb xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Fri Jun 4 19:22:54 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:47 2004 Subject: Paul has volunteered (was Re: Overloaded URIs must GO!) In-Reply-To: <3757FC09.F442A45B@darmstadt.gmd.de> Message-ID: Hi Robb Robb proposed: urn:hname:www:sprynet:com:megginson:MyNamespace ...Which looks even less URL-like. So, we can all agree that the rights are based on some protocol like HTTP, but when we write it out, we write it in such a way that it isn't misleading. Didier says: Sounds good Robb, the syntax is OK and the name cannot be taken for a URL. Regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ksievers at novell.com Fri Jun 4 19:32:39 1999 From: ksievers at novell.com (Kent Sievers) Date: Mon Jun 7 17:12:47 2004 Subject: All this buisiness about namespace URNs... Message-ID: I see how Paul's proposal meets the "forever unique" requirement, but how is it usefull for retrieving the namespace information? Reguarding the collisions, I for one would be willing to live with either 1) a "forever unique" ID or 2) taking my chances with the odds on a more descriptive ID. Finnally, I think that you missunderstood me on my third question. I never suggested making the URL part of the document. I am proposing that it be part of the ID. For example xmlns="xxxxxxxxx:http://www.novell.com/myproject/mynamespace" where xxxxxxx is a "forever unique" identifier and the rest is an indication of where it can be retrieved. The point is that the second part can be used to retreive, while the unique identifier can be used to identify and possibly perform a search in case the information is moved. It would be replacable/ignorable without breaking the essence of the identifier. >>> Steve Dahl 06/03/99 04:20PM >>> Kent Sievers wrote: > It amuses me to see how far off topic my posting got. And so quickly. With everyone fixating on a poorly worded clause of mine, I though I better try again, to see if I could improve on my rambling. This time, I will pose it as 3 simplified questions: > > 1) If (as has ben debated on this list) we are worried about URLs because they are not unique and change over time and do not have "ownership" without adding the HTTP protocol, then why don't we invent an ID for name spaces that IS globally unique? Paul Prescod's proposal for identifiers of the form "urn:urn-22:19990603:xml-dev@ic.ac.uk:e-mail" ..would be exactly the sort of ID you're talking about. Of course, we won't know whether it's "urn-22" or "urn-7" or "urn-1003" until the IETF assigns him a number. And I'm not sure whether I've used the date format correctly, but this is an example of his proposal, at least in the general structure. So it's been invented, but we need to wait for the IETF to ratify it. > 2) Are we really that worried about collisions? If I just used "mynamespace.myproject.Novell.com" as a name space ID, what are the odds that I will ever see any accidental collisions? And if someone intends to collide with me, then what recourse would I have with any other identifier? In your lifetime, maybe you'll never see a collision. Part of this issue is protecting not just ourselves, but our heirs, so to speak. We're trying to avoid the next Y2K problem. Let's hypothesize that you use the above namespace ID. Further, assume that for some reason which you have not yet anticipated, someone wants to archive your XML files for long periods of time (maybe 100 years). Assume that 30 years from now, Novell (by acquisition or merger) changes its name, and sells "novell.com". Another company buys that DNS name, and starts creating namespace names. There is some remote probability that by accident, they could accidentally collide with your namespace name. Here's a list of obvious objections, and my responses. "My data / namespace will never last 100 years." Maybe, but this is the same mentality that led programmers to use 2 digits for the year number, and they've been proved wrong in a grand way. After the scare created by Y2K, I suspect a lot of people are going to pay a lot more attention to long-term issues, especially if they're not hard to account for. "The odds of an accidental collision are very remote." Yes, it's very unlikely that your specific namespace will encounter a collision. But assume that over time billions or trillions of names will be generated--some of these will identify XML namespaces, but other resources will get named as well, and if we want to use the URN to retrieve documentation about the namespace, we don't want to collide with the URN for some other resource. So we imagine trillions of names generated over hundreds of years. While the probability of a given name being used twice is extremely low, the probability that *some* name will be duplicated becomes quite high, when you have that big a data set. To make a comparison that's not too far off the mark, imagine that through poor planning, some reserch center released a disease that cannot be controlled, and where the odds that I will be killed by this on any given day are 1:100,000,000. I personally would not be very afraid that I might catch it. But I think most people would be infuriated if every day 60 people world-wide (including 3 Americans) were killed due to poor planning by this center. It's a contrived example that ignores how diseases spread, so don't pick too hard at the details, but it points up how small probabilities become big ones when the dice are rolled often enough. "And if someone intends to collide with me, then what recourse would I have with any other identifier?" No recourse at all--no naming scheme can prevent collisions if one of the parties is malicious. This is all about avoiding collisions between people who honestly don't want collisions. If everyone follows the rules, how can we *guarantee* no collisions, without depending on a central naming authority, or on (as someone suggested) the serial numbers of specialized hardware. > 3) Why isn't our name space identifier two parts: 1) the name spaces name/ID that uniquely identifies it, and 2) the last known, or probable location of the information about the name space. The advantages of this are: a) I can still uniquely identify the name space no matter where it is moved, b) I can retrieve information about the name space and c) if that information is moved, there may be some hope of searching for it and updating it's location. Think of it as an ID/URL combination with the URL part optional, but a true URL. Because, if we have some server that knows how to map the namespace ID to an URL, why should we embed the same URL in the document. If we do a good job of choosing the URN (the namespace ID) so that it's permanently unique, we can guarantee that it will never be out of date. But we know there's a pretty good chance that the URL will change over time--it would be nice if the document didn't contain out-of-date URLs. By letting some server hold the mapping from URN to URL, and by updating that server when the URL changes, we make sure that any software would always be able to find, not the last known, but the *current* URL of the documentation. Assuming that such a server exists, it's a much more robust mechanism for finding information about the namespace. But the lack of such a server shouldn't necessarily keep us from using URNs. In fact, the more we use URNs, the more push there will be to create such servers. And if you need to be able to retrieve documentation *right now*, and not wait until this magical server exists, then you should use an URL rather than an URN as your namespace ID. -- - Steve Dahl sdahl@goshawk.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jabuss at cessna.textron.com Fri Jun 4 20:03:02 1999 From: jabuss at cessna.textron.com (Buss, Jason A) Date: Mon Jun 7 17:12:47 2004 Subject: XCatalog (now XMLCatalog) Message-ID: I am interested in seeing if any more work is being done with XCatalogs. I (being the SGML stalwart that I am) think that XCatalogs would be a very useful feature of XML. I love using catalog files (and i'm not even a sadist). It's saved my bootie a few times and keeps things pretty scalable... I thought the idea of using sysIDs with publicIDs in the XML doc instance was kinda screwy... Who's idea was that anyway? Best wishes... Jason A. Buss Single Engine Technical Publications Cessna Aircraft Co. jabuss@cessna.textron.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 4 20:22:01 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:47 2004 Subject: XCatalog (now XMLCatalog) References: Message-ID: <375819B2.3E397BF6@locke.ccil.org> Buss, Jason A wrote: > I am interested in seeing if any more work is being done with XCatalogs. Not by me at present. I do have some orphaned Java code that plugs XML Catalog support into any SAX environment by implementing the org.xml.sax.EntityResolver interface. I haven't had time to debug/document this. (Any takers?) It supports only the OASIS format, not the XML-syntax format. Interested parties can download it from these URLs: http://www.ccil.org/~cowan/XML/Socat.java http://www.ccil.org/~cowan/XML/SocatResolver.java http://www.ccil.org/~cowan/XML/SocatDemo.java -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ebohlman at netcom.com Fri Jun 4 20:38:25 1999 From: ebohlman at netcom.com (Eric Bohlman) Date: Mon Jun 7 17:12:47 2004 Subject: XCatalog (now XMLCatalog) In-Reply-To: Message-ID: On Fri, 4 Jun 1999, Buss, Jason A wrote: > I am interested in seeing if any more work is being done with XCatalogs. > > I (being the SGML stalwart that I am) think that XCatalogs would be a very > useful feature of XML. I love using catalog files (and i'm not even a > sadist). It's saved my bootie a few times and keeps things pretty > scalable... I'm currently working on an XML::Catalog Perl module. Can't say when it will be done, though. > I thought the idea of using sysIDs with publicIDs in the XML doc instance > was kinda screwy... Who's idea was that anyway? I believe Tim addressed this in the Annotated XML Recommendation; I forget the exact details. Something to do with always having a fallback in case a public ID couldn't be resolved, IIRC. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 4 22:24:54 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:12:47 2004 Subject: xsl editor needed In-Reply-To: <000301beae8d$a2f0e2b0$9607a8c0@mitra.com> Message-ID: <000301beaec8$875465a0$aa58fea9@w21tp> > I am trying to find a nice GUI XSL editor to greate XSL file. > I tried XML > Styler, i find it too difficult to use. Are the any > alternative I can pick > from?? Thanks Exactly what were you looking for? I have written several IDEs but I find it difficult to come up with an easy to use WYSIWYG XSL editor but here are some ideas from my stack of cool things: 1. Template creation wizard 2. Match pattern wizard 3. XSL document tree with drag-n-drop everywhere 4. XSL element property inspector 5. Before and after views in the template wizard/editors 6. Template/pattern repository for reuse 7. Late-binding of literal result to allow multiple results (HTML, XHTML, XML, PDF, etc.) 8. Drag-and-drop XSL process configuration for multi-step translation. 9. Debugger. Anything else? How would you rank the ideas in terms of importance? > As a note, for those people who are involved in XSL > development, I really > don't know how they write XSL document... notepad? anyway, > they are hero to > me :) More like vi or emacs me thinks. Frankly, those 'finger-happy' editors gives me the creeps. No offense meant to finger-happy folks. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ngill at eecs.uic.edu Fri Jun 4 22:24:10 1999 From: ngill at eecs.uic.edu (Navreena Gill) Date: Mon Jun 7 17:12:47 2004 Subject: Saving XML document Message-ID: Hello List, I am using SUN parser to parse an XML, modify it and write it back. I use Write function of XMLDocument with UTF-8 encoding. But the file it produces has all those squere boxes after each line break. How do I get rid of those? These boxes show up while opening the saved file in notepad. In wordpad it is fine. I have tried using xmlWriteChildren with pretty printing setting, this also does not work. Thanks a lot in advance. Navreena Gill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 4 22:41:59 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:48 2004 Subject: xsl editor needed References: <000301beaec8$875465a0$aa58fea9@w21tp> Message-ID: <37583A80.58A573D5@locke.ccil.org> Don Park wrote: > More like vi or emacs me thinks. Frankly, those 'finger-happy' editors > gives me the creeps. No offense meant to finger-happy folks. Me too, which is why I am an 'ex' troglodyte. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sjs at portal.com Fri Jun 4 22:56:47 1999 From: sjs at portal.com (Steve Schow) Date: Mon Jun 7 17:12:48 2004 Subject: xsl editor needed Message-ID: <188D20A88142D11190E900A0C906BBD3015C5534@venus.portal.com> Frankly, what the world is going to need are tools that you use to "styleize" XML.... Not "XSL Editors". It may be that XSL is being used under the covers to "style-ize", and as such....you would effectively be editing XSL with the tool. But rather than make a tool that just makes it easy to edit XSL....how about a tool that you use to think graphically about the layout you desire and then it figures out what XSL to use? -steve > -----Original Message----- > From: Don Park [mailto:donpark@quake.net] > Sent: Friday, June 04, 1999 1:26 PM > To: 'XML Dev' > Subject: RE: xsl editor needed > > > > I am trying to find a nice GUI XSL editor to greate XSL file. > > I tried XML > > Styler, i find it too difficult to use. Are the any > > alternative I can pick > > from?? Thanks > > Exactly what were you looking for? I have written several > IDEs but I find > it difficult to come up with an easy to use WYSIWYG XSL > editor but here are > some ideas from my stack of cool things: > > 1. Template creation wizard > 2. Match pattern wizard > 3. XSL document tree with drag-n-drop everywhere > 4. XSL element property inspector > 5. Before and after views in the template wizard/editors > 6. Template/pattern repository for reuse > 7. Late-binding of literal result to allow multiple results > (HTML, XHTML, > XML, PDF, etc.) > 8. Drag-and-drop XSL process configuration for multi-step translation. > 9. Debugger. > > Anything else? How would you rank the ideas in terms of importance? > > > As a note, for those people who are involved in XSL > > development, I really > > don't know how they write XSL document... notepad? anyway, > > they are hero to > > me :) > > More like vi or emacs me thinks. Frankly, those > 'finger-happy' editors > gives me the creeps. No offense meant to finger-happy folks. > > Best, > > Don Park > Docuverse > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Sat Jun 5 04:52:51 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:12:48 2004 Subject: BW ebiz--5/28/99--Clicks & Misses: Message-ID: <375890A2.A41ECA8E@infinet.com> I thought this might be of interest to many on this list who are active participants with XML.Org even though they all probably are already aware of this article. Nevertheless, just in case here it is. Enjoy, Tyler http://www.businessweek.com/ebiz/9905/el0528.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990605/1740c24b/el0528.htm From ricko at allette.com.au Sat Jun 5 06:04:15 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:12:48 2004 Subject: Namespaces are dead. Message-ID: <005a01beaf00$c079c860$40f96d8c@NT.JELLIFFE.COM.AU> Both BizTalk and the recent XML Schema draft use the namespace identifier as the schema identifier. However, BizTalk says that people *must* use XML Data for their schemas. So BizTalk documents cannot use XML Schema documents, and vice versa, unless both XML Schema and BizTalk/XML-Data are considered selective transformations of some other document type which has the namespaces in some schema neutral format. In the absense of a schema invocation mechanism (e.g., a version of the style sheet PI for schemas) that seperates Namespace identifiers from particular schemas (and therefore allows multiple schemas), both XML Schemas and BizTalk/XML-Data capture your data to particular paradigms. For BizTalk this is marginally more understandable: BizTalk frames itself as a wrapper, but then doesn't allow any flexibility in the schema language for the body: in other words, if you use BizTalk, you have to use XML-Data. This means that developers who require a degree of portability should maintain their documents using some schema-independent namespace, and only attach the namespace for a particular schema when the document is generated for a particular purposes. BizTalk could have allowed multiple schemas with XML-Data as the default; this would have allowed a lot of competition inside the wrapper/routing framework. But they didn't: is it a framework or a straightjacet? In other words, namespaces are dead (for database documents) as ways of uniquely naming elements independent of any other considerations. They are now "name-in-a-particular-schema-in-a-particular-schema-language--spaces". Congratulations to all concerned. The practical question is now what to do? Should we just lay down and die; should we go back to architectural forms; should we invent a parallel namespace PI that is concerned with uniquely identifying names and not with tieing elements to a schema? The first thing that is required is for W3C to create a Schema PI, in a similar fashion to the Stylesheet PI. In the absense of that mechanism, the Devourers can excuse themselves that there is nothing else to use for invoking schemas apart from namespaces. This is a matter of urgency and should take priority over all XML Schema activities, IMHO. Rick Jelliffe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990605/2bdbd796/attachment.htm From dent at oofile.com.au Sat Jun 5 08:06:32 1999 From: dent at oofile.com.au (Andy Dent) Date: Mon Jun 7 17:12:48 2004 Subject: new expatpp c++ wrapper for expat Message-ID: There's a new expatpp on our ftp server. I'm sorting out some issues building DLLs on VC but it now includes working projects with static libs . The big feature of this update is it makes it trivially easy to create nested parsers which is something used heavily in parsing our report-writer output. We just released an OOFILE update which saves and restores entire report layouts and data (using expatpp for reading). I've included relevant report-writer code as an example in the expatpp release. or Both archives include CodeWarrior projects for Mac and VC5 projects for Win. If you're interested in demos of the report-writer output there are some files online at Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability http://www.oofile.com.au/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Sat Jun 5 10:13:33 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:12:48 2004 Subject: XCatalog (now XMLCatalog) References: Message-ID: <00fc01beaf2a$a348d860$0300000a@cygnus.uwa.edu.au> > I thought the idea of using sysIDs with publicIDs in the XML doc instance > was kinda screwy... Who's idea was that anyway? I think some people felt that have just publicIDs would cause problems because there was no widespread resolution mechanism deployed on the Web[1]. As XML 1.0 stands, people can use publicIDs if they want to but must provide a sysID fall-back. James [1] of course, my DELEGATE extension to catalogs was designed to provide exactly such a 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Sat Jun 5 14:20:28 1999 From: costello at mitre.org (Roger Costello) Date: Mon Jun 7 17:12:48 2004 Subject: XSL Challenge Message-ID: <37591721.87D330C8@mitre.org> Hi Folks, Are you up for a mind-bending XSL problem? Someone presented me with this problem several weeks ago and I have yet to find a solution. It looks simple. It is deceptively challenging. An XML document stores database data as follows: A B C S E R G Q Note that the columns that we are interested in are col1 and col2. A element may contain data from columns not of interest. But, it will always contain at least data for col1 and col2. The problem is to create an XSL stylesheet that generates an HTML table with a table header: col1 col2 and within the table it has the row data. So the HTML table should look like this: col1 col2 A C E S Q G I have shown an XML document which has just two columns. However, the XSL stylesheet needs to be generic and capable of handling XML documents with any number of columns (as listed in the section). /Roger P.S. Below is what I tried, which doesn't work. Dynamic Table
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at w3.org Sat Jun 5 14:42:23 1999 From: chris at w3.org (Chris Lilley) Date: Mon Jun 7 17:12:48 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) References: <03fd01bea2a6$19f351c0$6f6167cb@james.harvestroad.com.au> <374AE345.152015E4@prescod.net> Message-ID: <37591984.32F697C5@w3.org> Paul Prescod wrote: > > James Tauber wrote: > > > > 1. Namespace URIs don't have to point to anything retrievable, they are just > > unique identifiers > > 2. Some URI schemes might not be web-retrievable (eg "isbn:1-23456-789-0") > > 3. Some URI schemes *are* web-retrievable (eg http://www.megginson.com/ns/) > > 4. So namespaces URIs *can* point to something, though, such as a > > human-readable description of the namespace, if they use a URI scheme that > > is web-retrievable. > > It strikes me as clearly poor design to use an HTTP url for something not > retrievable by the HTTP protocol. It would be, but no such examples were given. I suspect that the "isbn" protocol example would be better written urn:isbn:whatever - but regardless, it did not claim to be using the http protocol > I am distressed that this is becoming > "standard practice." How the heck are we supposed to know, on seeing a URI > whether it is supposed to be retrievable or not? Look at the protocol part and see if you understand that protocol. -- Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Sat Jun 5 14:45:29 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:12:48 2004 Subject: XSL Challenge References: <37591721.87D330C8@mitre.org> Message-ID: <37591A3F.76C01E0A@jclark.com> You have to use the variables feature of the current WD. Replace the second TR element in your attempted solution by the following: Roger Costello wrote: > > Hi Folks, > > Are you up for a mind-bending XSL problem? Someone presented > me with this problem several weeks ago and I have yet to find > a solution. It looks simple. It is deceptively challenging. > > An XML document stores database data as follows: > > > > > > > > > > A > B > C > > > S > E > > > R > G > Q > > > > > Note that the columns that we are interested in are col1 and col2. > A element may contain data from columns not of interest. > But, it will always contain at least data for col1 and col2. > > The problem is to create an XSL stylesheet that generates an > HTML table with a table header: > > col1 col2 > > and within the table it has the row data. So the HTML table > should look like this: > > col1 col2 > A C > E S > Q G > > I have shown an XML document which has just two columns. However, > the XSL stylesheet needs to be generic and capable of handling > XML documents with any number of columns (as listed in the > section). > /Roger > > P.S. Below is what I tried, which doesn't work. > > > result-ns="html"> > > > > Dynamic Table > > > > > > > > > > > > > > > >
> select="../../Rows/Row/Column[@name='{@name}']"/>
> > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From costello at mitre.org Sat Jun 5 14:53:50 1999 From: costello at mitre.org (Roger Costello) Date: Mon Jun 7 17:12:48 2004 Subject: XSL Challenge References: <37591721.87D330C8@mitre.org> <37591A3F.76C01E0A@jclark.com> Message-ID: <37591F08.A4AB814C@mitre.org> Thanks James. Any way to do it with the Dec. 16 WD? /Roger James Clark wrote: > > You have to use the variables feature of the current WD. Replace the > second TR element in your attempted solution by the following: > > > > > > > > > > > > Roger Costello wrote: > > > > Hi Folks, > > > > Are you up for a mind-bending XSL problem? Someone presented > > me with this problem several weeks ago and I have yet to find > > a solution. It looks simple. It is deceptively challenging. > > > > An XML document stores database data as follows: > > > > > > > > > > > > > > > > > > > > A > > B > > C > > > > > > S > > E > > > > > > R > > G > > Q > > > > > > > > > > Note that the columns that we are interested in are col1 and col2. > > A element may contain data from columns not of interest. > > But, it will always contain at least data for col1 and col2. > > > > The problem is to create an XSL stylesheet that generates an > > HTML table with a table header: > > > > col1 col2 > > > > and within the table it has the row data. So the HTML table > > should look like this: > > > > col1 col2 > > A C > > E S > > Q G > > > > I have shown an XML document which has just two columns. However, > > the XSL stylesheet needs to be generic and capable of handling > > XML documents with any number of columns (as listed in the > > section). > > /Roger > > > > P.S. Below is what I tried, which doesn't work. > > > > > > > result-ns="html"> > > > > > > > > Dynamic Table > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > select="../../Rows/Row/Column[@name='{@name}']"/>
> > > > > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 5 15:02:18 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:12:48 2004 Subject: XSL Challenge References: <37591721.87D330C8@mitre.org> <37591A3F.76C01E0A@jclark.com> <37591F08.A4AB814C@mitre.org> Message-ID: <37591E6B.38051F51@jclark.com> Roger Costello wrote: > > Thanks James. Any way to do it with the Dec. 16 WD? Not that I can think of. One of the main reasons for adding the local variables feature was precisely to be able to handle this sort of example. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From csgallagher at worldnet.att.net Sat Jun 5 17:05:46 1999 From: csgallagher at worldnet.att.net (WorldNet) Date: Mon Jun 7 17:12:48 2004 Subject: Well-Formed SNAFU Message-ID: <000001beaf65$98332940$0a000a0a@csg> I've noticed that Netscape Communicator 4.x ignores
and haven't tried same with IE4.x as I've upgraded to IE5. What techniques are going to be developed to account for this backwards compatibility issue if one creates otherwise well-formed documents? Must we count on the DOM and script our way into redundancy again? Would 'inline redundancy' be a strategy as in the form of

or would this break the current and future processors while addressing the foibles of the earlier releases? Lastly, I thought I read somewhere to use
using white space and when I use this technique this seems to be recognized by Communicator 4.x *and* IE5 but I wonder again about generalized usage in this regard with respect to maintaining a well-formed document. If this white space technique for empty tags is to be the way it should be done why do I not see this technique used in the examples that are being published? I hope to remind those of you who have a grasp on usage that most of us are engaged in 'monkey see - monkey do'. ======================================= Clinton Gallagher NET cpio@metromilwaukee.com URL http://www.metromilwaukee.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Sat Jun 5 18:42:16 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:12:48 2004 Subject: Namespaces are dead. In-Reply-To: <005a01beaf00$c079c860$40f96d8c@NT.JELLIFFE.COM.AU> (ricko@allette.com.au) References: <005a01beaf00$c079c860$40f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <199906051622.LAA09660@bruno.techno.com> [Rick Jelliffe:] > In other words, namespaces are dead (for database documents) as ways > of uniquely naming elements independent of any other > considerations. They are now > "name-in-a-particular-schema-in-a-particular-schema-language--spaces". > The practical question is now what to do? Should we just lay down and > die; should we go back to architectural forms; should we invent a > parallel namespace PI that is concerned with uniquely identifying > names and not with tieing elements to a schema? I'm glad you brought this up, Rick, because I have never heard a good argument as to why architectural forms were rejected in the first place. To me, it looks as though they were rejected simply because many RDBMS applications professionals don't yet think in object-oriented terms. (But that's changing.) Architectural forms handle multiple inheritance very gracefully, and they are based on a paradigm (the Grove Paradigm) within which re-usable software modules for inheritable architectures can cooperate in arbitrary combinations within applications that understand multiple vocabularies, even when vocabularies are combined arbitrarily in XML resources. Architectural forms work with or without a DTD; with architectural forms, the DTD becomes merely a markup-minimization device. "Meta-DTDs" (or "meta-Schemas", if you prefer) are the basis of primary syntactic validation. "Architectural definition documents" are the basis of subsequent semantic validation. Architectural "property sets" expose the information sets of resources that inherit architectures. Architectural forms provide a means of validating resources against the real syntactic and semantic requirements involved in using what are commonly called "vocabularies", thus meeting a real, basic requirement that W3C "namespaces" have never met, and that *vendor-neutral e-commerce must have*. For a general introduction, see my slides from XTech '99, http://www.hytime.org/papers/srnXTech99 I hate the idea of further fracturing the solution space with yet another PI which will be in partial conflict with other XML features. Now is the time to have a sensible, hard-working solution for inheriting multiple vocabularies. XML Schema isn't quite there (yet), but it could easily get where it needs to be, and I have high hopes for it. Anyway, until I see something better, my money's on the Grove Paradigm. I don't see anything else (yet) that will really meet all the requirements and really provide a stable path forward for the indefinite future. If we already know a correct answer, and our need for a correct answer is urgent, why don't we accept it and improve on it? In any case, the Grove Paradigm is already inevitable in ERP and other high-end corporate memory applications, including Topic Maps. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Jun 5 19:11:31 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:12:49 2004 Subject: Namespaces are dead. Message-ID: <3.0.32.19990605101241.01614920@pop.intergate.bc.ca> At 11:22 AM 6/5/99 -0500, Steven R. Newcomb wrote: >I'm glad you brought this up, Rick, because I have never heard a good >argument as to why architectural forms were rejected in the first >place. To me, it looks as though they were rejected simply because >many RDBMS applications professionals don't yet think in >object-oriented terms. (But that's changing.) Architectural forms were rejected because it was a design goal to assign namespaces both to elements and to attributes, and the AF syntax for doing with this attributes was felt to be indefensibly hideous. As David Megginson has pointed out on several occasions, namespaces solve an entirely different problem, and interoperate with AFs just fine. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Jun 5 19:11:31 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:12:49 2004 Subject: Well-Formed SNAFU Message-ID: <3.0.32.19990605101325.01616ec0@pop.intergate.bc.ca> At 10:10 AM 6/5/99 -0500, WorldNet wrote: >I've noticed that Netscape Communicator 4.x ignores
and haven't tried >same with IE4.x as I've upgraded to IE5. What techniques are going to be >developed to account for this backwards compatibility issue Admittedly a kludge, but "
" (note the space) works just fine.

kind of works, but in legacy browsers actually inserts *two* blank lines (sigh). -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sat Jun 5 19:12:25 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:49 2004 Subject: Namespaces are dead. In-Reply-To: <005a01beaf00$c079c860$40f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <001901beaf75$a1b0de30$1b19da18@ne.mediaone.net> Ouch!! Why ought namespaces be dead? Is Biztalk that important? Just don't use Biztalk or the XML Data namespace if you don't want it, this is a free WWW! --------- > Both BizTalk and the recent XML Schema draft use the namespace identifier as the > schema identifier. ... > In other words, namespaces are dead (for database documents) as ways of uniquely > naming elements independent of any other considerations. They are now "name-in-a-particular-schema-in-a-particular-schema-language--spaces". Not always. You can always use a "urn:" based namespace URI to prevent linking the namespace to a schema. > > Congratulations to all concerned. > > The practical question is now what to do? Should we just lay down and die; should > we go back to architectural forms; should we invent a parallel namespace PI that is > concerned with uniquely identifying names and not with tieing elements to a schema? > The first thing that is required is for W3C to create a Schema PI, in a similar > fashion to the Stylesheet PI. In the absense of that mechanism, the Devourers can > excuse themselves that there is nothing else to use for invoking schemas apart from > namespaces. Agreed. This is an easier to understand, more flexible solution which is more akin to the present mechanism of associating a DTD to a document than the proposed linkage to the namespace URI. One issue to consider, however, is the impact of either mechanism of schema/namespace association on how a document containing elements from multiple namespaces ought be validated. --------- Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sat Jun 5 20:13:40 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:49 2004 Subject: Well-Formed SNAFU In-Reply-To: <000001beaf65$98332940$0a000a0a@csg> from "WorldNet" at Jun 5, 99 10:10:49 am Message-ID: <199906051833.OAA11320@locke.ccil.org> WorldNet scripsit: > I thought I read somewhere to use
using white space and when > I use this technique this seems to be recognized by Communicator 4.x *and* > IE5 but I wonder again about generalized usage in this regard with respect > to maintaining a well-formed document. There is nothing ill-formed about "
", since whitespace is allowed in that position by the XML BNF. However, many browsers interpret "
" as ", so the formally equivalent "

" turns out to be a bad idea. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Jun 5 21:02:23 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:49 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) References: <03fd01bea2a6$19f351c0$6f6167cb@james.harvestroad.com.au> <374AE345.152015E4@prescod.net> <37591984.32F697C5@w3.org> Message-ID: <37597341.40FE2768@prescod.net> Chris Lilley wrote: > > > It strikes me as clearly poor design to use an HTTP url for something not > > retrievable by the HTTP protocol. > > It would be, but no such examples were given. The XSL namespace is: http://www.w3.org/XSL/Transform/1.0 Is someone going to put something retrievable there? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jkuan at infoserve.net Sat Jun 5 21:21:57 1999 From: jkuan at infoserve.net (Jami Kuan) Date: Mon Jun 7 17:12:49 2004 Subject: How to Solve this ParserException Problem? Message-ID: <000d01beaf89$39b9a280$331652d1@jkuan> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: textbrowserFrame.class Type: application/octet-stream Size: 560 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990605/5ee2c095/textbrowserFrame.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: textbrowser.java Type: application/octet-stream Size: 3306 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990605/5ee2c095/textbrowser.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: textbrowser.xml Type: text/xml Size: 480 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990605/5ee2c095/textbrowser.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: textbrowser.class Type: application/octet-stream Size: 3275 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990605/5ee2c095/textbrowser-0001.obj From srn at techno.com Sat Jun 5 22:32:12 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:12:49 2004 Subject: Namespaces are dead. In-Reply-To: <3.0.32.19990605101241.01614920@pop.intergate.bc.ca> (message from Tim Bray on Sat, 05 Jun 1999 10:13:28 -0700) References: <3.0.32.19990605101241.01614920@pop.intergate.bc.ca> Message-ID: <199906052030.PAA28464@bruno.techno.com> > Architectural forms were rejected because it was a design goal to > assign namespaces both to elements and to attributes, and the AF > syntax for doing with this attributes was felt to be indefensibly > hideous. Hideousness is in the eye of the beholder, but I think we're at cross-purposes. The issues here go far deeper than syntax. Syntax is just *how* we say something. *What* we say is infinitely more important, just as the whole architectural forms paradigm is infinitely more significant than the question of how we declare its use. > As David Megginson has pointed out on several occasions, namespaces > solve an entirely different problem, and interoperate with AFs just > fine. What, exactly, is the nature of the real-world problem that namespaces are the key to solving? Namespaces are still *perceived* as solving, and are often *sold* as solving, a problem that they do not in fact solve: the problem of allowing information to be exchanged in a truly open marketplace. Namespaces are being sold as the key to interchanging e-commerce information. And they will work for that purpose, BUT NOT IN A VENDOR-NEUTRAL CONTEXT, in which every system vendor can participate on a level playing field with every other system vendor, with a reasonable expectation that information will be reliably interchanged, regardless of who made the software that produces or applies the information. If I had ever thought that XML, nee SGML, could not be used by the public to create such a level playing field, I would have lost interest in it then and there. That's why I react so negatively to "namespaces". They seem to me designed to make private languages, not public ones. Namespaces provide absolutely no way for the information-using public to create (and demand software conformance to) whatever information architectures it deems appropriate. Namespaces put all control over every aspect of information interchange in the hands of whichever software companies already "own" a given user base. I put it to you very baldly: namespaces work against the public interest, and in favor of existing software monopolies. It doesn't surprise me that Rick Jelliffe has detected a conflict between BizTalk and other attempts to rationalize e-commerce, nor am I surprised that the conflict exposes an impedance mismatch involving namespaces. I keep hoping that people will wake up to the real requirements, and the real public interest issues here. That's why I'm bringing up architectural forms, for the umpteenth time, in this forum. I'm hoping that people will recognize that the interchange of commercial information requires *common* *public* languages, while "namespaces" are, at best, *private* languages that are inextricably entangled in particular software applications. Architectural forms provide a syntax (about which I care nothing -- let's agree on new syntax that you like, Tim), and a paradigm (about which I care very passionately) in which we can have *validatable* *common* *public* vocabularies that can be used for interchangeable information. In the AF paradigm, in any given application, we can have a re-usable plug-in engine for each vocabulary. The means whereby that magic is accomplished is the grove paradigm. It may or may not be relevant that all this is already standardized in ISO/IEC 10744:1997. The fact is, it works, and it is urgently needed for medical records, e-commerce, and other major applications of XML. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at w3.org Sat Jun 5 22:57:19 1999 From: chris at w3.org (Chris Lilley) Date: Mon Jun 7 17:12:49 2004 Subject: DTD confusion (was Re: Lotsa laughs) References: <199905280413.AAA17525@locke.ccil.org> <374C6EE4.572051B@finetuning.com> <14158.42213.350360.409498@localhost.localdomain> <3.0.1.32.19990528110617.015740f0@mail.accessone.com> <14158.60704.722872.118928@localhost.localdomain> Message-ID: <375925C9.AC6A7F40@w3.org> David Megginson wrote: > > David LeBlanc writes: > > (on DTDs) > > > Ok, now i'm confused David - your second statement seems to > > contradict your first statement. > > If you give me a single, well-formed XML document, I can *always* > write a DTD that describes its structure. Yes. You declare each observed element, give it a content model of any, declare each observed attribute, and make it PCDATA. That minimally describes it, like an RFC 822 email message can be describes as "a sequence of characters"; and likewise, it doesn't necessarily fully describe it or capture all the constraints that would be wished. -- Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dent at oofile.com.au Sat Jun 5 23:58:55 1999 From: dent at oofile.com.au (Andy Dent) Date: Mon Jun 7 17:12:49 2004 Subject: schema output for critique Message-ID: The context of this is that we needed to finish a local contract in a hurry that involved reading and writing entire report definitions as well as data. The data had to come back in with a schema very close to the original (ie: data types such as date & int preserved) because the report-writer preview window also allows in-place editing of content. I therefore took a few minor shortcuts from the XML Schema working draft. My major concerns are: 1) nested scope of names eg: how to handle Value used within Order as an integer and within Employee as a string. (uggh, horrible example I know) 2) masking for date types - the lexical suggestions don't seem to go far enough in allowing arbitrary letter separators. Am I being silly in writing outpu datatypes for those we use which match the MS XML Data standard? The following annotated sample gives an idea of what our output looks like, more examples at and I'm really interested in having them criticised. 0 65,535 -32,768 32,767 0 4,294,967,295 -2,147,483,648 2,147,483,647 1.7E-308 1.7E308 0 4,294,967,295 0 4,294,967,295 0 65,535 Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability http://www.oofile.com.au/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dent at oofile.com.au Sat Jun 5 23:59:02 1999 From: dent at oofile.com.au (Andy Dent) Date: Mon Jun 7 17:12:49 2004 Subject: XSL Challenge In-Reply-To: <37591721.87D330C8@mitre.org> References: <37591721.87D330C8@mitre.org> Message-ID: At 8:25 -0400 5/6/99, Roger Costello wrote: >It looks simple. It is deceptively challenging. > >An XML document stores database data as follows: > > > > > > > > > ... >So the HTML table >should look like this: > > col1 col2 > A C > E S ... Hmmm It's not quite applicable, but this is very close to the kind of layout problems we solve in our report writer. I found XSL syntax too complex for our purposes (machines and humans writing, machine parsing back into report definitions). The following annotated sample gives an idea of what our output looks like, more examples at and I'm really interested in having them criticised.
Carey Marion Fixed Text Dobson Sharon Fixed Text ... Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability http://www.oofile.com.au/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Sun Jun 6 05:18:36 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:12:49 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) References: <03fd01bea2a6$19f351c0$6f6167cb@james.harvestroad.com.au> <374AE345.152015E4@prescod.net> <37591984.32F697C5@w3.org> Message-ID: <008701beafcb$5d1483c0$0300000a@cygnus.uwa.edu.au> > > It strikes me as clearly poor design to use an HTTP url for something not > > retrievable by the HTTP protocol. > > It would be, but no such examples were given. Here are two: In http://www.w3.org/TR/REC-rdf-syntax/ there is the example of using http://www.w3.org/staffId/85740 to refer to a person. In http://www.w3.org/TR/1999/WD-xslt-19990421, http://www.w3.org/XSL/Transform/1.0 is used as the namespace. Admittedly, I have less of a problem with a latter case. I would imagine that soon there will be some document placed at that URI (whether a machine readable schema or not) describing the namespace. I have a bigger problem with the former, as I have outlined previously on this list. To raise again the sample problem I raised before: what would it mean to use RDF to specifier the Creator of http://www.w3.org/staffId/85740? Does it mean The Creator :-) or the creator of the retrievable resource (if any) at that URI? James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Sun Jun 6 06:13:56 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:12:49 2004 Subject: schema output for critique Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF68E@RED-MSG-08> Looks generally good to me. There is not yet a settled solution to local scoping of element names in the schema proposals, so you must either wait, use attributes, or hope that no clashes occur in your databases. You should also be aware that the working draft has no guarantees of stability. Regarding the specific datatypes you define, you show min and max values in some cases, and in those you include formats that might cause trouble: "1.7E308" might be better as "1.7E+308" and the several that have commas in them would face fewer internationalization problems if you omit the commas. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at qub.com Sun Jun 6 06:15:31 1999 From: paul at qub.com (Paul Tchistopolskii) Date: Mon Jun 7 17:12:50 2004 Subject: 2 questions about XML validating parsers. Message-ID: <002601beafd3$e4cf3e60$56d4d6cf@g0f2n0> Hello. 1. entities preprocessor. -------------------------------- I found that for some XML parsers ( like Expat, for example, but not only Expat ;-) processing entities ( especialy PERefs ) is not a kind of basic functionality. >From my point of view, if parsing/validating XML is like compiling C, expanding entities and resolving external references is kind of thing that C preprocessor does. Given the shape of existing validating parsers, for me it makes sence to write an XML preprocessor, that will resolve all the PERefs, 'include' all external DTD's and will produce an 'entities free' XML stream ( like C preprocessor does). Even this task looks trivial, there are some interesting twists there, like efficiency, whitespace / formatting control e t.c., so the question is: Is there any tool that looks like 'XML preprocessor' ? In other words - is there some tool I can use to : - take a complex XML documents contaning complicated entities e t.c. - produce an XML stream that whould be acceptable by Expat ;-) 2. The problem of 'sharing-very-close-but-not-exactly-the-same' XML documents. -------------------------------- If I have I still need to decalre Valid. Is there any *practical* reason for such a restriction? I mean that when somebody creates some DTD with element A of type ANY it means that the structure of the body of element A is absolutely unpredictable ( otherwise, why declaring it ANY ? ). Or there is some other practical reason to declare some element to be ANY ? So on one hand we have 'the body of this element is unpredictable' on another hand we are placing some extra restriction that is stronger than 'just be well-formed'. Unfortunately, I don't understand what is good with that extra restriction in practice, not in theory. Theory seems to be : "there should be no undeclared elements in any part of the valid XML document". ( BTW why not? What practical problem it may cause to have undeclared elements in that ANY part ( and only there...) ? ) What I do understand is the problem that such restriction introduces on practice. A couple of weeks ago I asked how can I solve some practical problem that I have - when 2 different companies are exchanging the 'very-close-but-not-the-same' documents. > The only difference between A-documents and > B-documents is that A-documents have > element that is specific to company A > and B-documents have element specific > to company B - the rest of elements and > attributes are the same for both companies. > > Now our companies decided to exchange > their documents. As a solution they may write > XSL stylesheets, or ( maybe) use entities > to remove A1 elemets and B1 elements. > I see no other ways to workaround this > situation and both are a bit complicated. > > The problem here is to hide some part of > XML document from the validation process. You could do write a single DTD with the following: and then have each company define their company-specific elements in company-specific DTDs, which would be included through the internal subset. This is open to abuse, though, as a valid document could contain any elements, not just the intended, company-specific elements, in the COMPANY_SPECIFIC element. However, if the documents are machine generated, this is not a problem. (By the way, EMPTY and ANY(THING) are valid only in content model definitions, not attributes.) So when one company introduces some new tag A1 the appropriate ;-) should be populated to the DTD's that are used by another company. Now what if we have 3 companies? 10? More? ( And we *will* have such problems with XSA and XSA-alike networks ). All those problems would simply disappear if just allowing ANY to be *realy* ANY ( it means that Validating parsers should allow undeclared elements to appear in the body of element of type ANY ). ---------------- So the question is: what is a practical reason for not making ANY to be realy ANY ? ---------------- ( Yes, we can always write yet another XSL stylesheet for rendering those 'very-close-documents' to each other, and because documents are closea - those stylesheets would be easy to write. What I don't understand is why should we write some extra code if just allowing ANY to be ANY would allow *not* to write extra code at all... ) Maybe I'm missing something again - I'l appreciate any feedback. Rgds.Paul. paul@pault.com www.pault.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sun Jun 6 11:17:28 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:50 2004 Subject: Addressing the Enterprise: Why the Web needs Groves Message-ID: <375A3B16.635FAB31@prescod.net> I'm posting the first few sections of http://www.prescod.net/groves/shorttut/ I've rewritten a lot of it to demonstrate the importance to the Web. I am hoping to generate some discussion on XML-DEV and xlxp. -------------------------------------------------------------------------------- 1. Introduction This paper is a high level introduction to the grove paradigm. Just as SGML was a hidden jewel buried in among the ISO standards for screwdriver heads, groves are another well-kept secret. The time has come to make "groves for the Web". This document should be relevant to the people that would do the specifying and coding to make groves available on the Web, but also to technically-oriented managers that are not interested in the fine details. This document is intended to explain the importance of the grove paradigm to the It is intended to clarify in people's minds what the result of parsing an SGML or XML document should look like. Some variation on the grove model could be imagined, but the basics of the model seem fundamental and unavoidable to me: for instance, W3C's DOM reflects the same basic concepts. Groves were invented to solve the problems that had become revealed at a particular point in the development of the SGML family of standards. XML has reached the same point so the time is right to popularize the grove idea. Please send me your comments on this document. It will eventually become an ISOGEN technical paper, but it is still rough. -------------------------------------------------------------------------------- 2. Background 2.1 The Problem In the early and mid-1990s, the ISO groups that were responsible for the SGML family of standards realized that they had a large problem. The people working on the DSSSL and HyTime standards found that they had slightly different ideas of the abstract structure of an SGML document. Understanding an SGML document's structure is easy for simple things, but there are many issues that are quite complex. For instance, it is not clear whether comments should be available for a DSSSL spec. to work on, or whether they should be addressable by hyperlinks. It isn't clear whether it should be possible to address every character, or only non-contiguous spans of characters. Should it be possible to address and process tokens in an attribute value or only character spans? Should it be possible to address markup declarations? XLink and XSL must solve all of the same issues. Although this paper will discuss many problem domains, the reader should keep in mind that addressing is the central one. If you cannot address information (e.g. through a URL) then you cannot do anything else you need to it: such as retrieve it, bind methods to it, attach metadata to it, apply access control lists to it, render it, work with it in a programming language and so forth. Addressing is the key. Value follows naturally and immediately. The reason that addressing into XML (and other data formats) is ill-defined is because the XML specification speaks of the syntax of the XML language, not the abstract, addressible objects encoded in the document. Linking and processing are done in terms of some data model, not in terms of syntax. When you make a link between two elements, you are not linking in terms of the character positions of the start- and end-tags in an SGML or XML entity. You are linking in terms of abstract notions such as "element", "attributes" and "parse tree". The role of an XML parser is to throw away the syntax and rebuild the logical ("abstract") view. The role of a linking engine (such as a web browser) is to make links in terms of that logical view. The role of a stylesheet engine is to apply formatting in terms of that logical view. Unless stylesheet languages, text databases, formatting engines and editors share a view, processing will be unreliable and complicated. It is not very common for XML and SGML applications and toolkits to provide all of the information necessary for building many classes of sophisticated applications, such as editors. There is not even a standardized way for an toolkit to express what information from the SGML/XML document it will preserve. Even if two toolkits preserve exactly the same information, it is quite possible that they use different terminology to describe the information. In some cases, APIs might be identical except that they use different structures to organize the information! But those one or two features could make navigating the APIs very different. In the software engineering world we have a technique for avoiding this sort of problem: modelling. Using languages like the Unified Modelling Language (UML) we can build sophisticated, intricate models of the world that can be independently implemented and yet interoperable. I can hand a model of a human resources application to a developer on the other side of the planet and we can build logically compatible applications. Of course UML is at a very high level. The precise expression of an object in a particular programming language or system is not fixed by UML. The UML is a mathematical expression of the entities and relationships in a problem domain. It doesn't usually translate directly into code or APIs. That is why we also have to use more concrete object description languages such as IDL, ODL and STEP Express. 2.2 Why Not the DOM The W3C has partially addressed this situation with a specification called the Document Object Model (DOM). Unfortunately the DOM is not really an object model in the abstract sense. It is rather just a collection of IDL interfaces and some descriptions of how they relate. This is different from an abstract object model because it is too flexible in some places and not flexible enough in others. The DOM is too flexible in that it is not rigorous enough to be a basis for addressing. For instance the DOM says that a string of four characters could be broken up into multiple text nodes or treated as a single one. If we describe addresses in terms of DOM text nodes, those addresses will be interpreted differently by various DOM implementations. This is one reason that XPointer and XSL are not defined in terms of the DOM. This weakness of the DOM is fatal for using it for addressing but it is also annoying for programmers. In some cases they must write special code to work with documents that have different text breaking algorithms because the DOM has given implementors too much flexibility here. It puts their ease of implementation above the ease of coding for DOM users. In other ways te DOM is not flexible enough. One important weakness is that it is defined in IDL which does not permit much variation in language mappings and bindings. We have found this very limiting in the Python and Perl worlds. With these high level languages there are more convenient ways of mapping the high level XML concepts into APIs than the ways dictated by CORBA. If we use these ways instead of the DOM ways, however, our APIs are conformant to the DOM only in spirit, not in terms of the formal detail of the specification. 2.3 Defining views The DOM has a more important inflexibility. It would be useful for the programmer using the DOM to be able to define whether all adjacent text nodes are merged or not. There is a "normalize" method that attempts to provide this feature that method actually modifies the tree. All viewers must see the same view. Another useful view is one in which every character is a separate node. That view allows us to address individual characters very easily. Another view might provide DTD information for a document. Yet another view would provide linking information. Still another view would attach RDF properties to the DOM. We can also make views that are simpler than the default DOM view. We could have a view that got rid of CDATA nodes and treated them just as text. Another view might remove processing instructions based on the principle that many applications do not use them. It would also be very nice to be able to remove "insignificant" whitespace from a view. The W3C is working on a subset of XML to make XML easier to process for parsers but there is no such spec to make simpler DOMs for application writers. Let's take this back to the addressing realm for a second. Given all of these views of a document, we could do things like query for the node with the "author" RDF property with value "Paul" or for the node that is reference by a particular hyperlink or for the third character of an element and so forth. There is an important truth here. Every time we create a new specification built on XML, we implicitly define new properties that should be attached to the nodes: almost a whole new data model! Consider a document type based not only on XML but also on XLink, namespaces and RDF. That document has many different views. Here are some obvious ones: * First there is the low-level XML view. It would have elements, attributes, characters and so forth. * Then there is the namespace view built on top of that. A "namespace engine" would add some namespace information to the tree. It would probably hide namespace attributes that were visible in the lower view. * Then there is yet another view that adds hyperlinking information. The engine that provides this view can let us know whether a node is an anchor or a link. On top of that there could be a view built specifically for that document type. It would understand the constructs in the document type and make them available to a programmer as objects with properties. Let's step back for a minute again. If we can make all of these views available to the programmer in some simple, consistent way, then we could surely make them all available to people doing querying and addressing also. That means that we could make a query language that could do queries based on constructs from all four levels! We could also easily define query languages that were specialized and optimized for a particular level. The way we currently handle this is through different "levels" of the DOM. The second one is being worked on right now. These levels tend to lag behind the specifications that they are supposed to work with by months or years. There is a DOM for XML, HTML and CSS, but nothing for namespaces, RDF, XLink, XSL queries or XHTML. There is a single group within the W3C that will be responsible for building all of these "levels" of the DOM. This group of intelligent, well-meaning people is the most fundamental bottleneck in the standards world today. Even if all of the DOM people gave up their day jobs and became full-time DOM builders they could never keep up with the amount of innovation occurring within the W3C. Consider then, that the problem is in no way limited to the W3C. People are building little XML-based languages with their own data models all over the Web. A central API bottleneck is not inconvenient: it is impossible. The DOM cannot be a universal API for all XML-based languages. The XML Information Set project is similar to the DOM except that it works in terms of abstractions instead of APIs. That is an important first step. But the Information Set is designed only for a single view of XML with certain optional features. It does not seem at this time that it will be possible for "end-users" (programmers and query-writers) to tweak the views. It also does not seem that the model is designed to be extensible to completely new views. In other words it provides the very bottom layer but does not define the infrastructure to build the upper ones. In the ISO world we solve this problem by farming out the definition of data models. A "property set" is a formal model for a view of an XML document. A property set is half way between an abstract, unimplementable UML data model and a narrowly defined IDL definition. It speaks in terms of the higher level concepts that are the basis of hypermedia and so can be implemented conveniently in high level programming languages. The important thing about property sets is that they embed and embody the requirements necessary for a data model to be useful in a hypermedia context. That means that every node in the grove is addressable. It is easy to construct an address for any given node (for instance the character under a mouse click) or node list (e.g. a selected list of characters). 2.4 Hypermedia to the Max Now we get to the really exciting thing about property sets. You can build property sets for views of XML documents. Those are extremely useful and powerful. Even more powerful, though, are property sets for things that are not even XML. SQL databases and OLE objects can have property sets. LaTeX files can have property sets. People have defined experimental property sets for CSS, CGM and for something as abstract as legal documents. After all, a property set is just a simple data model. You could define UML models for all of those types. Defining a property set is no harder. But property sets have a huge benefit over UML: once you define a property set for a data object type, that data object becomes addressible. This means that every subcomponent of every data object in an enterprise is potentially addressable. The important point is that you do not have to convert all of your data resources into XML or HTML to make them addressable. You may need to turn them into XML or HTML to render or transfer them between machines, but there are many other things that we need to be able to do with addressable resources. We can attach access control lists to to them, make hyperlinks to them, attach metadata to them and so forth. Some "XML people" have this idea already but they express it in terms of "building a DOM" over some non-XML resource. The idea is right but the expression of the idea is wrong. The logic goes this way: We want an addressable data model for the resource. XML has a data model. Therefore let's use the XML data model for the resource. This model seems logical but it is inefficient both in terms of computer time and programmer time. If the underlying object is a relational database then it makes no sense to take numbers (for example) and encode them as strings so that the client application can unencode them back to numbers. Similarly, it makes no sense to turn a database record into an XML element so that the final application can think of it as a record again. If all you need to do is address a database record then what you want to do is the minimum required to turn a database record into something addressable. The grove model is designed so that defining a property set for the database is the minimum you have to do. In this case you can forget about XML altogether! In buzzword-speak this is "addressing the enterprise." Every data object in an organization from the smallest non-profit to the largest multinational can be addressed through a single data model and query language. You might also think of these as meta-models and meta-query languages in that the grove model and its associated query language give you a framework for defining the details of more precise models and richer query languages. Let me say again that rendering the document is another matter altogether. Given an address, the easiest way to render the object might be via XML. For a database record this might be the case. For a slide within a PowerPoint document, however, the easiest way to render it might be through OLE. Addressing is separate from rendering. Groves allow you to say that you want to see the slide. OLE or XML/XSL might provide the technology that you need to actually see the slide. Without groves, hypermedia addressing is very poorly defined. For instance, how do you, today, make a hyperlink to a particular frame in an MPEG movie, or a particular note in a midi sequence? How would you extract that information in a stylesheet (for instance for sequencing a multimedia hyperdocument). It makes no sense to address in terms of bytes, because often a single logical entity, like a frame, is actually spread across several bytes and they may not be contiguous. Addressing in terms of characters would make even less sense because MPEG movies and midi sequences are not character based. The web solves this problem by inventing a new "query language" (in the form of extensions to URLs called "fragment identifiers") for each data type. This more or less works, but it leads to a proliferation of similar, but incompatible query languages doing the same basic thing. These languages have different syntax and underlying models. This brings us to the next point: implementation. Under today's W3C way of doing things you would implement a hypermedia browser (e.g. SMIL) by hard-coding support for each different type of query for each type of playable object. If resources hyperlinked to each other through these fragment identifers, the implementation engine would have to implement separate query languages for each fragment identifier type. That is an annoying waste of time. Consider, the issue of metadata attached to parts of media objects through links. For instance I might add a title to an MPEG frame so that I could locate it later. Or I could add a pop-up-video style annotation. Usually this would be implemented as some sort of on-disk or in-memory database. In one column of a record you would have the properties that you want to attach (expressed somehow). On the other side you need to have things to attach them to. We need a generic term for "things that you can address within media objects." Generically, we could call these "nodes" and "node lists." As soon as you make that leap to describing the targets of references generically, regardless of media type, you have essentially reinvented groves. It follows that standards like RDF implicitly depend upon a (currently underdefined) concept similar to groves. Instead of reinventing them, however, you have the option of using an international standard that specifies them! I hope that one day there will also be a W3C standard that does something similar. More at: http://www.prescod.net/groves/shorttut/ -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sun Jun 6 11:34:38 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:50 2004 Subject: RDF and Resources Message-ID: <375A3D93.4B8E34D2@prescod.net> RDF's definition of resource seems to be incompatible with the URI specification that it references: > All things being described by RDF expressions are called resources. > A resource may be an entire Web page; such as the HTML document > "http://www.w3.org/Overview.html" for example. A resource may be a > part of a Web page; e.g. a specific HTML or XML element within the > document source. A resource may also be a whole collection of pages; > e.g. an entire Web site. A resource may also be an object that is > not directly accessible via the Web; e.g. a printed book. Resources > are always named by URIs plus optional anchor ids (see [URI]). According to RFC 2396, a resource is something addressable by a URI (without fragment identifier) -- a complete HTML or XML document, not a part of it. Also, I find it interesting to note that RDF does not seem to be able to attach metadata to components of things that are not XML: frames of a video, records in a database, paragraphs in a Word document and so forth. We need the ability to do so. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 6 12:16:01 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:12:50 2004 Subject: RDF and Resources In-Reply-To: <375A3D93.4B8E34D2@prescod.net> Message-ID: Interesting point. The RDF spec says... > > not directly accessible via the Web; e.g. a printed book. Resources > > are always named by URIs plus optional anchor ids (see [URI]). ...when it perhaps ought to say "always named by URI References", per section 4.1 of the RFC. I believe this is a confusion rather than a bug in the spec, in that nothing I can find in either doc tells us that the things picked out using URI References, ie. the #'d view into the retrieved object, cannot themselves be resources. If they have identity (cue separate debate) they're resources. And hence RDF describable. Some excerpts from ftp://ftp.isi.edu/in-notes/rfc2396.txt Uniform Resource Identifiers (URI) provide a simple and extensible means for identifying a resource. [...] Resource A resource can be anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. [...] 4. URI References The term "URI-reference" is used here to denote the common usage of a resource identifier. A URI reference may be absolute or relative, and may have additional information attached in the form of a fragment identifier. However, "the URI" that results from such a reference includes only the absolute URI after the fragment identifier (if any) is removed and after any relative URI is resolved to its absolute form. Although it is possible to limit the discussion of URI syntax and semantics to that of the absolute result, most usage of URI is within general URI references, and it is impossible to obtain the URI from such a reference without also parsing the fragment and resolving the relative form. URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] The syntax for relative URI is a shortened form of that for absolute URI, where some prefix of the URI is missing and certain path components ("." and "..") have a special meaning when, and only when, interpreting a relative path. The relative URI syntax is defined in Section 5. [...] the optional fragment identifier, separated from the URI by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI. So... on my reading... --- the URI is the bit before the # in a URI or URI Reference --- the entire 'thing' picked out by a URI Reference might still be a resource and have 'identity' (and might eg. have a first-class URI in another scheme, eg uuid: or urn:). Even if just a section of a larger object (video frame etc). --- for any URI reference, there are potentially two objects (resources) implicated; the one picked out by the URI proper, and the one picked out by the URI reference, if there is an optional '#'. RDF uses the latter when the #foo is present. The Web doesn't give a name to the relationship between these two things, though the Web Characterisation activity seems to be making a good start in that direction. I see nothing in this to suggest that that RDF can't describe bits of non-XML content, since those components for eg might well have URIs (eg. urn, uuid...) of their own. What I do see is a rather ugly glitch (doubtless motivated but still scary) in the section of the URI RFC which defines fragment identifiers: 4.1 tells us: The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of the retrieval result. This is gross as it relativises the semantics of frag identifiers to the mime time of the object as retrieved. Since that is itself a (possibly time-sensitive) function of content-negotiation between client and server, fragment identification issues get tangled up with possibility of the server offering multiple (language/format) negotiable versions or renderings (or manifestations -- pick your terminology) of the same object. When this wierdness in web architecture is cleared up, and the different renderings available (eg. over http, http-ng) are more explicitly differentiated, RDF and XML will be living in a happier less ambiguous world. Dan On Sun, 6 Jun 1999, Paul Prescod wrote: > RDF's definition of resource seems to be incompatible with the URI > specification that it references: > > > All things being described by RDF expressions are called resources. > > A resource may be an entire Web page; such as the HTML document > > "http://www.w3.org/Overview.html" for example. A resource may be a > > part of a Web page; e.g. a specific HTML or XML element within the > > document source. A resource may also be a whole collection of pages; > > e.g. an entire Web site. A resource may also be an object that is > > not directly accessible via the Web; e.g. a printed book. Resources > > are always named by URIs plus optional anchor ids (see [URI]). > > According to RFC 2396, a resource is something addressable by a URI > (without fragment identifier) -- a complete HTML or XML document, not a > part of it. > > Also, I find it interesting to note that RDF does not seem to be able to > attach metadata to components of things that are not XML: frames of a > video, records in a database, paragraphs in a Word document and so forth. > We need the ability to do so. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Jun 6 13:53:53 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:12:50 2004 Subject: Namespaces are dead. Message-ID: <004501beb00b$92ac0b30$1df96d8c@NT.JELLIFFE.COM.AU> From: Jonathan Borden >Why ought namespaces be dead? Is Biztalk that important? Just don't use >Biztalk or the XML Data namespace if you don't want it, this is a free WWW! Unlike Steve Newcomb and like Tim Bray, I think namespaces do solve a different problem to architectural forms. Namespaces provide a way to treat a local name as a public identifier. I like namespaces; they are convenient but XML needs to have available ASAP something to prevent them from being used by vendors to capture data. The big door that architectural forms opened to allow multiple schemas operating on the same data: whether for structure description, data description, competitive schema languages, or any other reason. All along people have perceived clearly that the namespaces were (if tied directly to schema specifications) a way to prevent "open" extensiblility and instead to capture data to single, probably proprietary schema tools and systems. The extensibility of XML not only refers to adding new elements, but in preventing data capture (this is why PIs have targets, for example.) The stylesheet PI is good, because multiple PIs are possible: you dont need to generate different data depending on the other end (in the pleasant future). Tieing particular schemas to namespaces is bad, becuase it forces a document to use XML data or XML schema only: we are right back in slack old HTML land. It is disgusting. >... You can always use a "urn:" based namespace URI to prevent >linking the namespace to a schema. But then I still have to reprocess my names to if I want to send BizTalk or use XML Schema. > One issue to consider, however, is the impact of either mechanism of >schema/namespace association on how a document containing elements from >multiple namespaces ought be validated. I think the open/closed content model directly impacts that: some places the schema will allow you to extend without being particularly interested in what happens. This is pretty much in architectural-forms territory. I cannot see why a schema-selecting PI could not also allow architectural-forms, but that is not a requirement for this problem. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pgrosso at arbortext.com Sun Jun 6 18:45:38 1999 From: pgrosso at arbortext.com (Paul Grosso) Date: Mon Jun 7 17:12:50 2004 Subject: Well-Formed SNAFU Message-ID: <3.0.32.19990606114800.006ca32c@pophost.arbortext.com> At 10:13 1999 06 05 -0700, Tim Bray wrote: >At 10:10 AM 6/5/99 -0500, WorldNet wrote: >>I've noticed that Netscape Communicator 4.x ignores
and haven't tried >>same with IE4.x as I've upgraded to IE5. What techniques are going to be >>developed to account for this backwards compatibility issue > >Admittedly a kludge, but "
" (note the space) works just >fine.

kind of works, but in legacy browsers actually >inserts *two* blank lines (sigh). -T. But getting the space into
and having it stay there through round trips in XML-aware editors and such is not always possible, and

doesn't really work, as Tim says. However, something like:
(any attribute value assignment would do) works in most HTML browsers (certainly in NS4.x and IE 3-5) and is something that can be done (and will not get undone) by any editing tool. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pgrosso at arbortext.com Sun Jun 6 19:18:01 1999 From: pgrosso at arbortext.com (Paul Grosso) Date: Mon Jun 7 17:12:50 2004 Subject: XCatalog (now XMLCatalog) Message-ID: <3.0.32.19990606115024.006ca32c@pophost.arbortext.com> At 16:03 1999 06 05 +0800, James Tauber wrote: >> I thought the idea of using sysIDs with publicIDs in the XML doc instance >> was kinda screwy... Who's idea was that anyway? > >I think some people felt that have just publicIDs would cause problems >because there was no widespread resolution mechanism deployed on the Web[1]. >As XML 1.0 stands, people can use publicIDs if they want to but must provide >a sysID fall-back. > >James > >[1] of course, my DELEGATE extension to catalogs was designed to provide >exactly such a mechanism. Yes, and the SGML Open (now OASIS) TR9401:1997 catalog resolution [2] includes a version of the DELEGATE entry type, thanks to James and others. [2] http://www.oasis-open.org/html/techpubs.htm#entity xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sun Jun 6 19:25:41 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:50 2004 Subject: RDF and Resources References: Message-ID: <375AAA68.F67EA2D6@prescod.net> Dan Brickley wrote: > > [...] > the optional fragment identifier, separated from > the URI by a crosshatch ("#") character, consists of additional > reference information to be interpreted by the user agent after the > retrieval action has been successfully completed. As such, it is not > part of a URI, but is often used in conjunction with a URI. > > So... on my reading... > > --- the URI is the bit before the # in a URI or URI Reference > --- the entire 'thing' picked out by a URI Reference might still be a > resource and have 'identity' (and might eg. have a first-class > URI in another scheme, eg uuid: or urn:). Even if just a section > of a larger object (video frame etc). At the very best we can say that the thing following the # might or might not represent "somehing with identity." There are no constraints on it. It could be used to attach a stylesheet or make the background color of the displayed object blue. It is merely "additional reference information." Therefore I think that RDF is correct to limit itself to the two Web-language where the referenced objects have identity (even if the details are still being worked out in the Information Set project). I think that even in the XML realm there is a problem. If XPointer-NG continues to allow spans to be addresssed as first class objects (a mistake IMHO) then that would mean that every possible start,end pair in an XML document is a separate "resource". Iterating over these "resources" within a document would be an impossibly slow operation. A better model (that they will hopefully adopt) would be that spans address NODE LISTS (not "span resources"). Then an RDF attachment could be interpreted as shorthand for attaching to each node in the list. After all, we desperately need this shorthand and it makes iteration easy. Resources would correspond to what we think of as nodes: elements, attributes, characters and so forth. > When this wierdness in web architecture is cleared up, and the different > renderings available (eg. over http, http-ng) are more explicitly > differentiated, RDF and XML will be living in a happier less ambiguous > world. Agreed. Insofar as the grove model was designed precisely to clear up an identical weirdness in SGML and HyTime, I tend to think that it is the best place to start in fixing the Web. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From carl at catapultt.com Sun Jun 6 20:18:27 1999 From: carl at catapultt.com (Carl Schei) Date: Mon Jun 7 17:12:50 2004 Subject: [Bug] Inline DTD's and XML4J ? Message-ID: <003501beb049$96cea9a0$786f6f6f@womble> Hi There, This is my first posting to XML-Dev. Great mailing list. I have been using the IBM XML4J Parser (v2.0.9) class for just a short while. The client has requested that we inline the DTD's instead of making them external. I resorted to the following sample code, Parser p = new Parser(getDefaultDTDPath(), this, null); DTD aDTD = null ; try { BufferedReader b = new BufferedReader(new FileReader("SampleDTD.dtd")) ; aDTD = p.readDTDStream(b) ; b.close() ; } catch (IOException ex) { } aDTD.setName("CustomerDataResponse") ; StringWriter aWriter = new StringWriter(); try { aDTD.print(aWriter) ; } catch (IOException ex) {} System.out.println(aWriter.toString()) ; Used on the following XML file (with inline DTD), ]> Produces the results, ]> Note that there is no line, Which totally invalidates the DTD. Now the interesting thing is that if I duplicate this line in the original DTD, i.e., ]> It produces the desired results!! Anyone found similiar results? I can't think of anything that I'm doing wrong. Thanks, Carl Schei Catapult Technology, Inc. (630) 515-3670 phone carl@catapultt.com http://www.catapultt.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990606/0386c3c1/attachment.htm From paul at prescod.net Mon Jun 7 03:03:44 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:12:50 2004 Subject: XML Inclusion Proposal References: <3.0.1.32.19990601120415.00e6c820@tiac.net> Message-ID: <375B179F.4B70FEB0@prescod.net> "Joshua E. Smith" wrote: > > An interesting philosophical question, first: if I make this inclusion > mechanism available to authors of documents in my XML conformant language > (which is not, I expect, a language which will be useful to any XML > processor other than my own), would it be reasonable to omit support for > general entity references? I'm reluctant to encourage half-way support of the XML specification. One day there will be a standardized XML subset that does not include general entities and I would be more comfortable then. > Question 2: I think I understand your intent, but just to be sure: what do > you *expect* the included document to look like? Does it start with: > > > > Would you expect it to have a DOCTYPE, or not? Any element in any XML document can be included. If you link to the full document then it should be interpreted as an inclusion of the root element (i.e. not the DOCTYPE and XML/encoding declaration, if present) > I suspect I could just make my own rules for my authors (e.g., the included > document must be well formed, must not includes a doctype, etc.), but I was > wondering if you had a particular set of conventions in mind. In > particular, a well formed document has only one root node, which might be > kind of inconvenient in a lot of cases (take your copyright example: I > might want to always include both a > blahblah and if I require that the > included doc is well formed, I'd have to wrap those together, right?). Yes, but the specification allows you to make an inclusion link that ONLY brings in the copyright and GPL, but not the wrapper element. > Question 3: I'm not familiar enough with the XLink/XPointer specs to > understand this part: > > >Source Anchor: > > > >The source anchor may be identified as an anchor described in a locator > >with the role "source". It must address a single node in the same > >document as the link. If an inline link has no locator named "source", > >then the local resource serves as the source anchor. > > > >Target Anchor: > > > >The target anchor may be identified by a locator with the role > >"content". If the link has no such locator but it has only one single > >remote resource then that resource may be used as the content anchor. > > Can you give examples of each kind of inclusion this can lead to? I'm > having a lot of trouble with understanding what these two paragraphs mean, > exactly. Here is the basic XLink data model: link=role, anchor+ anchor=role, href So an inclusion link looks like: link = role, (source, target) source="source", href (to a single node in the same document as the link) target="content", href (to any node or node list in any document anywhere) Inline links implicitly have an anchor which is the linking element itself, like this or . When the inclusion specification sees a simple link, it presumes the content to be the source anchor and the referenced nodes to be the target. Out-of-line links do not treat the linking element as an anchor and instead link two other things. In the case of an out-of-line link I don't know which anchor is the source and which is the content so you have to say explicitly. > Does this mean that I can include some miscellaneous nodes buried in the > included document? For example, can I have a document license.xml with > various licenses, and then include the one in particular that I need by > using these anchors? How would that look? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Jun 7 04:02:51 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:50 2004 Subject: Saving XML document References: Message-ID: <375B28C4.F9415B04@pacbell.net> Navreena Gill wrote: > > Hello List, > I am using SUN parser to parse an XML, modify it and write it back. > I use Write function of XMLDocument with UTF-8 encoding. But the file it > produces has all those squere boxes after each line break. I can see two things this might be. First is a bug that's been fixed in the latest release (TR2, available now) where writing text didn't actually use the platform line end; so, on Win32, rather than seeing a CRLF you'd see just a LF. Second, which may be less likely in this case, is that you need to be usin an editor which really talks UTF-8 !! > How do I get > rid of those? These boxes show up while opening the saved file in notepad. > In wordpad it is fine. I have tried using xmlWriteChildren with pretty > printing setting, this also does not work. Get the TR2 release of Sun's package, and see if that fixes the CRLF issue for you. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Jun 7 04:57:39 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:50 2004 Subject: XHTML DTDs failing in IE5 References: <5BF896CAFE8DD111812400805F1991F708AAF659@RED-MSG-08> Message-ID: <375B359C.C9FA76D7@pacbell.net> Andrew Layman wrote: > > In this list and in others, there have been strong and conflicting > opinions expressed on what would be the best behavior of a parser, and no > settled standard exists. I can't buy this. The W3C specifications for XML and for namespaces are quite settled ... and _neither_ one places a requirement that declared "xmlns*" attributes must have "#FIXED" default values. In fact, the statements that exist make it clear that from the XML 1.0 syntax point of view, "xmlns*" are like other attributes ... which may be defaulted or not, and hence may omit (or include) "#FIXED" depending on what a given DTD author chooses to do. > I do not, in fact, know that the IE5 > rules are the ultimately best rules; what we can say in their favor is that > because they are conservative, they do not encourage the creation of > documents that are accepted by MSXML and yet are later rejected by > conformant parsers after standards have been worked out. Sound like you're saying it's conservative to treat MSXML as the holder of the standards, rather than the W3C documents. That's not a very popular attitude outside of Redmond! In a standards context, "conservative" means implementing only (and exactly!) what the specifications say. I don't think this is what Microsoft has done in this case. Speculating on the reasons why may be amusing, but I'd rather see this bug fixed (soon!) instead. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Jun 7 05:05:27 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:51 2004 Subject: xsl editor needed References: <188D20A88142D11190E900A0C906BBD3015C5534@venus.portal.com> Message-ID: <375B3776.66107224@pacbell.net> Steve Schow wrote: > > Frankly, what the world is going to need are tools that you use to > "styleize" XML.... Not "XSL Editors". It may be that XSL is being used > under the covers to "style-ize", and as such....you would effectively be > editing XSL with the tool. But rather than make a tool that just makes it > easy to edit XSL....how about a tool that you use to think graphically about > the layout you desire and then it figures out what XSL to use? Saaaay ... how about a CSS editor? :-) I looked at Mozilla M6 and its XML/CSS support, and was quite pleased. I can even use parts of XLink to make URLs work, though I don't quite have the pointers changing correctly when they go over those links. Yes, yes -- CSS doesn't let you restructure your XML, can't solve the table of contents or indexing problems, can't construct internal links. That can be done on servers if needed, or with an XSL first pass, and isn't always needed anyway. But even if you think that XSL will be the One True Stylesheet, you'd have to acknowledge there's a need for something to handle the formatting objects. And it should be straightforward to make that module handle CSS along with FOs. (Whatever you do, don't insist on rendering to HTML!!) - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Jun 7 05:12:37 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:51 2004 Subject: Well-Formed SNAFU References: <3.0.32.19990605101325.01616ec0@pop.intergate.bc.ca> Message-ID: <375B3924.BE0295C8@pacbell.net> Tim Bray wrote: > > Admittedly a kludge, but "
" (note the space) works just > fine.

kind of works, but in legacy browsers actually > inserts *two* blank lines (sigh). -T. I think someone at W3C looked around and conclused that "
" (and "
" etc) was a good solution for (X)HTML if you were willing to punt on version 2 browsers. At any rate it's pretty widely accepted. It's to avoid this particular issue that Sun's XML package prints empty tags with the otherwise unnecessary space before the "/>", in fact! Paul Grosso wrote: > >
Hmm, interesting. I'd not seen that one before. I wonder how widely that one is accepted? - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From michael_champion at ameritech.net Mon Jun 7 05:50:51 1999 From: michael_champion at ameritech.net (Mike Champion) Date: Mon Jun 7 17:12:51 2004 Subject: Addressing the Enterprise: Why the Web needs Groves Message-ID: <375B428B.B05A0B41@ameritech.net> Paul Prescod wrote: > The W3C has partially addressed this situation with a specification called > the Document Object Model (DOM). Unfortunately the DOM is not really an > object model in the abstract sense. It is rather just a collection of IDL > interfaces and some descriptions of how they relate. This is different > from an abstract object model because it is too flexible in some places > and not flexible enough in others. This was the subject of much discussion on the DOM interest group about a year ago. The resolution was that the InfoSet WG, not the DOM, has responsibility for defining the "structure model" of XML (which I think is the same as the "abstract object model"). When there is consensus on what *the* abstract object model for XML is, the DOM will evolve to reflect this consensus. > 2.3 Defining views > > The DOM has a more important inflexibility. It would be useful for the > programmer using the DOM to be able to define whether all adjacent text > nodes are merged or not. There is a "normalize" method that attempts to > provide this feature that method actually modifies the tree. All viewers > must see the same view. Another useful view is one in which every > character is a separate node. That view allows us to address individual > characters very easily. Another view might provide DTD information for a > document. Yet another view would provide linking information. Still > another view would attach RDF properties to the DOM. > This seems like quite a useful idea. Can anyone suggest an API for this, perhaps Document::setView(int viewFlag) where viewFlag is one of NORMALIZE, ONECHARPERNODE, etc.? Or perhaps the NodeIterators in the DOM Level 2 working draft could have factory methods that make it easy to present such views? (The latter is more in the spirit of DOM Level 2, I personally believe). Likewise, various Level 2 extensions are being considered to present a view of the text underneath an element that eliminates the burden of navigating each TextNode individually. > The W3C > is working on a subset of XML to make XML easier to process for parsers > but there is no such spec to make simpler DOMs for application writers. FWIW, There is a strong sentiment among DOM people to defer working on a simpler subset of the DOM until a simpler subset of XML is defined. > The way we currently handle this is through different "levels" of the DOM. > The second one is being worked on right now. These levels tend to lag > behind the specifications that they are supposed to work with by months or > years. There is a DOM for XML, HTML and CSS, but nothing for namespaces, > RDF, XLink, XSL queries or XHTML. There is a single group within the W3C > that will be responsible for building all of these "levels" of the DOM. > This group of intelligent, well-meaning people is the most fundamental > bottleneck in the standards world today. Well, that's gonna help me sleep at night! ;~) Seriously, I think this is an important misconception. I believe I speak for most people involved in the DOM in asserting that the RDF, XLink, XHTML, etc. definers,implementers, and/or users can and should develop DOM extensions of their own to avoid this very bottleneck. DOM Level 2 will contain mechanisms to make it easier for independent groups to develop APIs that provide convenient, powerful interfaces to the semantics of specific XML applications that presumably are built upon or in some way compatible with the DOM Core. For example, a "groves" API that extends the DOM to provide the features Paul Prescod discusses could be defined by essentially anyone, submitted to the W3C as Note, and the marketplace of ideas would determine the extent to which it will be actually implemented and used. Obviously the DOM working group COULD tackle this job; the basic ideas of the groves model were carefully considered and deliberately excluded from the DOM API, mainly because most implementers balked at the performance/footprint implications of many grove-related ideas. So, go ahead, somebody, prove us wrong! You don't need to convince anyone at the W3C, just build a grove processing package that extends the DOM interfaces, make it available to the world, then watch what happens. I guarantee you that there are plenty of people who would LOVE to see a simple, usable, efficient object model for XML element text that avoids the problems of TextNodes. On the other hand, few of them are holding their breath waiting ... [If there are fundamental ways in which CORBA IDL or the DOM Core inhibits such extensions, I'm sure we'd be interested in hearing the details and would entertain suggestions of how to resolve such limitations.] Other matters under discussion here (especially the areas of XSL queries and attaching metadata to documents via the DOM) may well be addressed in DOM Level 3. This is a good time to start advocating specific requirements or suggest APIs! Mike Champion Software AG and W3C DOM Working Group (speaking only for myself, etc.) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 7 05:55:08 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:12:51 2004 Subject: Well-Formed SNAFU Message-ID: <3.0.32.19990606205607.0118a630@pop.intergate.bc.ca> At 08:14 PM 6/6/99 -0700, David Brownell wrote: >Paul Grosso wrote: >>
>Hmm, interesting. I'd not seen that one before. I wonder how >widely that one is accepted? Yes, new (and clever). I suspect that will work on any browser known to humankind. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From davids at mannanetwork.com Mon Jun 7 11:03:06 1999 From: davids at mannanetwork.com (David Soroko) Date: Mon Jun 7 17:12:51 2004 Subject: DOM, SAX and Events Message-ID: <002e01beb0cd$653e0460$49934dd4@mannanetwork.com> XML4j parser (from IBM) implements the Visitor pattern. You run a traversal on the DOM tree and receive *events* into a visitor that rides piggy back on the traversal object. HTH David ==================================================== Hi, I'm currently using a SAX parser to parse an XML script which drives some application processing. I used SAX as it gave a nice fit with the Java event system. I've layered a lightweight application specific event system on top of SAX so those details are hidden from the application itself. This all works very nicely and is nothing new. However I now realise that I may need to repeat parts of the script, i.e. run a particular section multiple times before continuing. I can't simply copy and paste parts of the XML doc as I don't know a priori how many repetitions are required. I also can't revisit that part of the document because the SAX parser doesn't allow this. So, I'm going to move to a DOM representation and do a tree-walk instead. I can then revisit subtrees whenever required. This should be no problem to implement, but leads me to wonder whether other people have met this same problem, and if so whether it'd be useful to have an event driven interface to the DOM? Basically the interface just involves tree-walking and determining the types of nodes and generating the correct callbacks similar to SAX, albeit at a slightly higher level. Is this something others have encountered? Is it an already solved problem and I've missed something? Cheers, -- =================================================== David Soroko mailto://davids@mannanetwork.com http://www.geocities.com/SiliconValley/Campus/1628/ Manna Network Technologies =================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From owen.synge at meadowhouse.co.uk Mon Jun 7 11:28:44 1999 From: owen.synge at meadowhouse.co.uk (Owen Synge) Date: Mon Jun 7 17:12:51 2004 Subject: Posting Data Islands Message-ID: <375B91C2.A7E805B9@meadowhouse.co.uk> I have been looking at the microsoft web pages (even though at hart I am a linux user) for XML examples, unfortunately I am yet to work out what to do with data islands once I send them to the client. Can they send them back to my server, or can they save them to disk, please help, or if you know a URL to demo these facilitys with out useing active server pages I would be most pleased. Thanks in advance Owen xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Mon Jun 7 11:42:13 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:12:51 2004 Subject: Posting Data Islands Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A196C@eukbant101.ericsson.se> > -----Original Message----- > From: Owen Synge [SMTP:owen.synge@meadowhouse.co.uk] > > I have been looking at the microsoft web pages (even though at hart I am > a linux user) for XML examples, unfortunately I am yet to work out what > to do with data islands once I send them to the client. Can they send > them back to my server, or can they save them to disk, please help, or > if you know a URL to demo these facilitys with out useing active server > pages I would be most pleased. > Am I the only person that has come to the conclusion that XML Data Islands are a really bad idea? I hope MS see it the same way, and deprecate them in favour of namespaces instead. As an answer to your question, you have to do something with them in Javascript (or heaven forbid: vbscript). I don't know the IE object model well enough to know if you can save them to disk, but I'm sure you can probably send them back to the server if you really want to. Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From neumann at psi.uni-trier.de Mon Jun 7 14:52:45 1999 From: neumann at psi.uni-trier.de (Andreas Neumann) Date: Mon Jun 7 17:12:51 2004 Subject: Announcement: Version 1.2 of fxp Message-ID: <375BC116.8D49F4BC@psi.uni-trier.de> I am pleased to announce version 1.2 of fxp, a validating XML parser written in Standard ML. New in this version: - full support for XML syntax of XML Catalog; - support for retrieval of non-local URIs; - new sample application fxviz, a document tree visualizer; - few bug fixes. fxp has been developed at the Computer Science Department, University of Trier, using Standard ML of New Jersey. fxp and its documentation are available at: http://www.informatik.uni-trier.de/~neumann/Fxp -- Andreas Neumann FB IV - Praktische Informatik II University of Trier, 54286 Trier email: neumann@psi.uni-trier.de Germany, Tel. : +49 651 201-2823 url : http://www.informatik.uni-trier.de/~neumann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From neumann at psi.uni-trier.de Mon Jun 7 14:52:41 1999 From: neumann at psi.uni-trier.de (Andreas Neumann) Date: Mon Jun 7 17:12:51 2004 Subject: Announcement: Version 1.2 of fxp Message-ID: <375BC116.8D49F4BC@psi.uni-trier.de> I am pleased to announce version 1.2 of fxp, a validating XML parser written in Standard ML. New in this version: - full support for XML syntax of XML Catalog; - support for retrieval of non-local URIs; - new sample application fxviz, a document tree visualizer; - few bug fixes. fxp has been developed at the Computer Science Department, University of Trier, using Standard ML of New Jersey. fxp and its documentation are available at: http://www.informatik.uni-trier.de/~neumann/Fxp -- Andreas Neumann FB IV - Praktische Informatik II University of Trier, 54286 Trier email: neumann@psi.uni-trier.de Germany, Tel. : +49 651 201-2823 url : http://www.informatik.uni-trier.de/~neumann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Mon Jun 7 15:56:59 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:12:51 2004 Subject: Byte on XML-RPC In-Reply-To: References: <4.2.0.56.19990606191425.00ce3bc0@mail.userland.com> <1283438849-10359322@scripting.com> Message-ID: <4.2.0.56.19990607065048.01d964c0@mail.userland.com> Gotta read this one! http://byte.com/features/1999/06/0607XML_RPC.html Success! Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bd at internet-etc.com Mon Jun 7 15:55:24 1999 From: bd at internet-etc.com (Brandt Dainow) Date: Mon Jun 7 17:12:51 2004 Subject: Posting Data Islands In-Reply-To: <5F052F2A01FBD11184F00008C7A4A800022A196C@eukbant101.ericsson.se> Message-ID: <000e01beb0ec$db57fe20$fe87bc3e@p300> XML Data Islands can populate tables without the author knowing any JavaScript. Personally I think they're a great way of letting ordinary web designers get at XML. They also provide a way of formatting XML database output without using either XSL or any scripting, which should enable db'ers to start getting some simple output straight away. Data Islands have nothing to do with namespaces at all. Brandt Dainow bd@internet-etc.com Internet Etc Ltd http://www.internet-etc.com >-----Original Message----- >From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On >Behalf Of >Matthew Sergeant (EML) >Sent: Monday, June 07, 1999 10:44 AM >To: 'Owen Synge'; XML development >Subject: RE: Posting Data Islands > > >> -----Original Message----- >> From: Owen Synge [SMTP:owen.synge@meadowhouse.co.uk] >> >> I have been looking at the microsoft web pages (even though >at hart I am >> a linux user) for XML examples, unfortunately I am yet to >work out what >> to do with data islands once I send them to the client. Can they send >> them back to my server, or can they save them to disk, >please help, or >> if you know a URL to demo these facilitys with out useing >active server >> pages I would be most pleased. >> > Am I the only person that has come to the conclusion >that XML Data >Islands are a really bad idea? I hope MS see it the same way, >and deprecate >them in favour of namespaces instead. > > As an answer to your question, you have to do something >with them in >Javascript (or heaven forbid: vbscript). I don't know the IE >object model >well enough to know if you can save them to disk, but I'm sure you can >probably send them back to the server if you really want to. > > Matt. > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jun 7 16:21:34 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:51 2004 Subject: Imminent death of Namespaces predicted (was: Namespaces are dead.) In-Reply-To: <005a01beaf00$c079c860$40f96d8c@NT.JELLIFFE.COM.AU> References: <005a01beaf00$c079c860$40f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <14171.52648.395380.720312@localhost.localdomain> Rick Jelliffe writes: [snip .... BizTalk not using XML Schemas ... snip ] > In other words, namespaces are dead (for database documents) as > ways of uniquely naming elements independent of any other > considerations. They are now > "name-in-a-particular-schema-in-a-particular-schema-language--spaces". > > Congratulations to all concerned. This is a schema problem, not a Namespace one. The XML architecture that is currently working itself out is a layered one; here's one possible path (more document-oriented): Layer Spec Purpose ------------------------------------------------------------------------ 1 Unicode Encoding-independent characters 2 XML Generic markup language 3 Namespaces Globally-unique names 4 Schemas (?) Generic structural constraints and relationships 5 TEI A specific set of constraints and relationships Here's another possible path (more data-oriented): Layer Spec Purpose ------------------------------------------------------------------------ 1 Unicode Encoding-independent characters 2 XML Generic markup language 3 Namespaces Globally-unique names 4 RDF Generic identification of properties (attributes) and resources (entities) 5 RDF Schema Object-oriented data constraints and relationships 6 Dublin Core A specific set of object-oriented data constraints and relationships Right now, I think that most people would agree that layers #1 and #2 (Unicode and XML) in both examples are, if not rock solid, firm enough for now, and that layer #4 in the first example (XML Schemas), and #5 in the second (RDF Schemas), are quite wobbly. I don't see, though, from any of Rick's examples, that there is reason to call layer #3 (Namespaces) into question. Last summer in Montreal, I argued that Architectural Forms themselves would make a useful layer on top of Namespaces (so that you can say element X is a kind of element Y without reading a 500K schema to figure it out), but Architectural Forms are about subtyping, not naming per se, so they're not competing for the same space. We're gradually creeping our way up a greased pole; so far, the Unicode Consortium and ISO have standardised a character set, the W3C (and, indirectly, ISO) have specified a low-level markup language, and the W3C has specified a global naming scheme for elements and attributes. Many people believe that the next logical layer is schemas; Rick is right to point out that there are problems in those woods, but the lower layers are still safe (just as disagreement over HTTP wouldn't put TCP itself into jeopardy). Eventually, we'll hit a point where it doesn't make sense (or becomes too difficult) to standardize any further, but the lower layers should be fine. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jun 7 16:21:12 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:51 2004 Subject: DTD confusion (was Re: Lotsa laughs) In-Reply-To: <375925C9.AC6A7F40@w3.org> References: <199905280413.AAA17525@locke.ccil.org> <374C6EE4.572051B@finetuning.com> <14158.42213.350360.409498@localhost.localdomain> <3.0.1.32.19990528110617.015740f0@mail.accessone.com> <14158.60704.722872.118928@localhost.localdomain> <375925C9.AC6A7F40@w3.org> Message-ID: <14171.54095.173678.376151@localhost.localdomain> Chris Lilley writes: > > If you give me a single, well-formed XML document, I can *always* > > write a DTD that describes its structure. > > Yes. You declare each observed element, give it a content model of any, > declare each observed attribute, and make it PCDATA. In fact, you can do it without resorting to ANY; you could also type the attributes much more closely as well. There is already existing software that will take a stab at it for you. The original point, though, was that by definition a document is not well-formed if it cannot be described by a DTD, not that the absence of a DTD (or other schema) is insignificant. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jun 7 16:21:24 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:51 2004 Subject: Well-Formed SNAFU In-Reply-To: <000001beaf65$98332940$0a000a0a@csg> References: <000001beaf65$98332940$0a000a0a@csg> Message-ID: <14171.53913.875128.977845@localhost.localdomain> WorldNet writes: > I've noticed that Netscape Communicator 4.x ignores
and haven't tried > same with IE4.x as I've upgraded to IE5. Try
It's annoying, but it works. Same with , ,
, etc. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SMUENCH at us.oracle.com Mon Jun 7 16:25:00 1999 From: SMUENCH at us.oracle.com (Steve Muench) Date: Mon Jun 7 17:12:52 2004 Subject: Posting Data Islands Message-ID: <199906071425.HAA17893@mailsun2.us.oracle.com> I don't quite understand the comment about replacing a named temporary buffer for XML sent to me from a server by a namespace, but here's an example of posting an XML data island to a server: function postTextAreaXMLToServer() { // Get a new XML Document (these 3 lines not required if // "doc" was already the name of an XML Data Island // in the page). In my example I let the user type in // an XML document in a TEXTAREA on the form whose // name="toSend". doc.loadXML() loads raw text and parses // it as an XML document. var doc = new ActiveXObject("Microsoft.XMLDOM"); doc.async = false; doc.loadXML(toSend.value); // Get an instance of the HTTP Request/Response Object var msg = new ActiveXObject("Microsoft.XMLHTTP"); // Open an HTTP message to define its characteristics msg.open("POST","http://smuench-lap/echoxml.jsp",false); // Send the "doc" XML Document (/Data Island) msg.send(doc); // Interpret the response. In this case my server JSP page // parses the sent XML file and sends back the same XML // file as a "text/xml" mimetype (an echo test). toReceive.value = msg.responseXML.documentElement.xml; } See: http://msdn.microsoft.com/xml/reference/scriptref/XMLHttpRequest_object.asp For complete details... _________________________________________________________ Steve Muench, Consulting Product Manager & XML Evangelist Business Components for Java Dev't Team http://www.oracle.com/xml -------------- next part -------------- An embedded message was scrubbed... From: "Matthew Sergeant (EML)" Subject: RE: Posting Data Islands Date: 07 Jun 99 02:43:58 Size: 3589 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990607/a81e0731/attachment.eml From creitzel at mediaone.net Mon Jun 7 16:29:15 1999 From: creitzel at mediaone.net (Charles Reitzel) Date: Mon Jun 7 17:12:52 2004 Subject: Overloaded URIs must GO! Message-ID: <199906071430.KAA13614@chmls05.mediaone.net> Must this same discussion be repeated endlessly? In its essence, it has changed not a whit in a year. Indeed, many of the participants are the same. As folks have pointed out, it is an important subject upon which many pieces of software depend. So I am merely expressing dismay that reasonable conventions have not sorted themselves out. Question: wouldn't it be reasonable for URN's in some schemes to be overloaded? For example, couldn't some portion of a namespace URN be the schema or dtd file declaring the namespace contents? Any host serving up documents (or portions thereof) using the namespace could easily resolve the filename and return the schema/dtd file itself. urn:: urn:xmlns:joebob/schema/widgets.dtd Generally, http servers and their ilk do *not* need literal paths to files. All kinds of path tranlation is performed. Thus, there is plenty of opportunity to resolve the name to a concrete resource (and return a "not found" if the request is not meaningful). Conventions like *not* including a file extension in the URN if the namespace is abstract will go a long way to helping NS users avoid making such requests. As many have said, it would be useful to have an explicit mechanism to reference a dtd/schema document associated w/ a namespace. Without such a mechanism, URN overloading is practically a requirement. Also, some folks are reasonably concerned about permanance. They don't like DNS names in URNs because DNS could go down or the domain name could become unregistered and then reregistered to someone else using the name in a completely different context, etc. etc. For applications that need it, I would investigate getting an ISO Object Identifier. Your organization can get a globally unique number from the ISO which identifies your organization and can be extended to identify important entities it publishes. Like DNS, you just get the one ID from the global registry which may then be used to qualify any additional IDs you define. Unlike DNS, there is no particular association with a given piece of software or data format and the registration body will not unregister your ID if you don't make annual payments. It shouldn't be too hard to use an OID within a URI/URN (you pick). If it is, go bug the appropriate IETF WG, because it shouldn't be. At any rate, I think the XML community can look to de facto standards (MIME/HTTP) for resolution of schema documents and standards bodies for permanent ID registration. It isn't *that* hard. Best regards, Charles Reitzel >From: "Jonathan Borden" >Subject: Re: Paul has volunteered (was Re: Overloaded URIs must GO!) > >Paul Prescod wrote: >> >>But there are specifications being built on top of the namespaces >>specification that make use of the URI. These specifications are not right >>or wrong -- the namespace spec is silent about what happens if you >>dereference the URI. >> >>When these specifications are deployed, software will attempt to >>dereference namespace URIs. That software will not know whether to report >>inaccessible URLs as errors or retry on the hope that it is available now >>or merely assume that that namespace doesn't have an associated document. >>Do we report an error or merely continue? > > This is a very difficult problem without an easy solution. > > This problem will arise with most data whose lifespan is expected to be >long. Short term problems include network outages as well as firewall >issues. Longer term problems include changes in DNS ownership. Still longer >term problems include changes in network protocols (i.e. when http becomes a >legacy and/or unsupported protocol). > > The only good solution to this problem is to keep schemas/DTDs together >with documents and not depend on any network protocol. > > URNs aren't a solution to this problem, because URN's don't allow >dereferencing (otherwise they become another type of URL). Wouldn't it also >be an error to attempt to dereference "urn:xxx..."? > >Jonathan Borden >http://jabr.ne.mediaone.net > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From puff at netcom.com Mon Jun 7 16:39:01 1999 From: puff at netcom.com (Steven J. Owens) Date: Mon Jun 7 17:12:52 2004 Subject: Cobol Copybooks? Message-ID: <199906071441.HAA19454@netcom17.netcom.com> Hey folks, I've been lurking for a few weeks; I tried to post this question when I first subscribed, but I never saw it show up. Maybe that should have warned me :-). Anyway, I'm working on a project where there seem to be some uses for XML. My part is in Java on several Solaris boxes, but another part of the project is an MQSeries connection to CICS/Cobol, mostly to grab data that's formatted via Cobol Copybooks. So we're writing classes to parse certain specific copybook formats; it seems to me that it'd be really nifty to have a generic system to generate XML DTDs from the copybooks, and then parse the data into XML-tagged format. Even better would be to do this on the CICS side of things, since that's where the data comes from, and send both the DTD and the XML-tagged data back through MQSeries. Then on the other side, a java XML parser (somebody suggested SAX would be a good place to start) could be used to parse the data. Is there anything out there that does this sort of thing? I'd think IBM would be working on something (they seem to be really investing in new technologies these days; Java, XML, Linux...) since they have such a big stake in the CICS/Cobol market. But I can't find anything on it. Steven J. Owens puff@netcom.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From csgallagher at worldnet.att.net Mon Jun 7 16:46:08 1999 From: csgallagher at worldnet.att.net (WorldNet) Date: Mon Jun 7 17:12:52 2004 Subject: Well-Formed SNAFU In-Reply-To: <3.0.32.19990606205607.0118a630@pop.intergate.bc.ca> Message-ID: <000201beb0f5$50cf6dc0$0a000a0a@csg> > David Brownell wrote: > >Paul Grosso wrote: > >>
> >Hmm, interesting. I'd not seen that one before. I wonder how > >widely that one is accepted? > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Tim Bray > Yes, new (and clever). I suspect that will work on any browser known > to humankind. -T. Yes, using
does seem to work in NC4.x and IE5.x using... Would the same hold true using 'strict'? I need to question for understanding wether the class itself needs to be defined somewhere as I've been needing to do with CSS? Does it not or is the recognition of the html-compatibility-mode attribute value something the parsing agent recognizes via the DOCTYPE mechanism? The document I'm using as a learning model was created using MS Word 2000...which arguably will be IMHO how most XML documents in the near future will be created by the larger population of users that in turn will require modification and refinement by others. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pgrosso at arbortext.com Mon Jun 7 17:08:46 1999 From: pgrosso at arbortext.com (Paul Grosso) Date: Mon Jun 7 17:12:52 2004 Subject: Well-Formed SNAFU Message-ID: <3.0.32.19990607101012.00d25aac@pophost.arbortext.com> At 20:57 1999 06 06 -0700, Tim Bray wrote: >At 08:14 PM 6/6/99 -0700, David Brownell wrote: >>Paul Grosso wrote: >>>
>>Hmm, interesting. I'd not seen that one before. I wonder how >>widely that one is accepted? > >Yes, new (and clever). I suspect that will work on any browser known >to humankind. -T. To give appropriate credit, I first heard of this approach in a posting by Chris Maden. It seems to work pretty universally in my (admittedly not exhaustive) experience. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 7 18:04:46 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:12:52 2004 Subject: Well-Formed SNAFU Message-ID: <3.0.32.19990607120639.007ff170@polaris.net> At 10:11 AM 6/7/1999 -0500, Paul Grosso wrote: >>>>
>To give appropriate credit, I first heard of this approach in a >posting by Chris Maden. Yes. I think Chris's preferred expression of it, though, is:
:) ============================================================= John E. Simpson | It's no disgrace t'be poor, simpson@polaris.net | but it might as well be. | -- "Kin" Hubbard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 7 18:18:19 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:52 2004 Subject: RDF and Resources References: <375A3D93.4B8E34D2@prescod.net> Message-ID: <375BDB87.8C8290EC@locke.ccil.org> Paul Prescod wrote: > According to RFC 2396, a resource is something addressable by a URI > (without fragment identifier) -- a complete HTML or XML document, not a > part of it. Technically you are correct: there is a discrepancy here between resources accessible by URIs simpliciter, and those accessible by URI references (possibly including anchors). > Also, I find it interesting to note that RDF does not seem to be able to > attach metadata to components of things that are not XML: frames of a > video, records in a database, paragraphs in a Word document and so forth. > We need the ability to do so. This is not an RDF problem; it reflects the fact that nobody has defined the meaning of fragment ids for those media types. Go thou forth and define. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 7 18:21:57 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:52 2004 Subject: HAX References: <199905280259.WAA14197@locke.ccil.org> <375BE1F1.515390DC@pacbell.net> Message-ID: <375BEB40.4486B0E1@locke.ccil.org> David Brownell wrote: > Hmm, I have a SAX2 driver that parses XML, which I'll release this week. I suppose you mean "parses HTML". > It uses the Swing HTML parser, which is pretty universally available > though (like all HTML parsers) it's got quirks with respect to how it > handles faulty XML. That was my first idea, but I learned that the Swing parser doesn't do the amount of cleanup I want, so I decided to roll my own. Don Park also has a SAX interface to Swing-HTML, freely available but closed source. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Mon Jun 7 18:28:04 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:12:52 2004 Subject: Posting Data Islands Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A1974@eukbant101.ericsson.se> > -----Original Message----- > From: Steve Muench [SMTP:SMUENCH@us.oracle.com] > > I don't quite understand the comment about replacing > a named temporary buffer for XML sent to me from a server > by a namespace, but here's an example of posting an > XML data island to a server: > The point of what I said about namespaces was that XML data islands are non-standard, and IE only. What would be better (IMHO) than the ugly non-standard bastardised HTML tag addition of Data islands would be a way of accessing an individual namespace embedded within an xhtml document, so instead of having:

Some xml below:

You would have:

Some namespace scoped XML below:

See what I mean? And then have some standardised (DOM) mechanism of accessing that data. I know I've just opened up a huge kettle of fish here, so I'm going to stand back as the worms spill out :) Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Mon Jun 7 18:54:12 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:12:52 2004 Subject: Cobol Copybooks? Message-ID: <01BEB0E5.67B1FDB0@cc398234-a.etntwn1.nj.home.com> Steven J. Owens wrote: "...it'd be really nifty to have a generic system to generate XML DTDs from the copybooks, and then parse the data into XML-tagged format." Steven, XML Convert can probably convert your legacy data into XML. XML Convert is a Java application that converts flat files into XML. It uses XFlat schemas to parse and validate the flat files, and to produce the XML output. XFlat is an XML language for defining flat file schemas. XML Convert supports a wide variety of flat file formats, including CSV, fixed length records and fields, multiple record types, groups of records, nested groups, etc. You can download XML Convert 1.0 for free at http://www.unidex.com/. By the way, XML Convert can not convert a COBOL copybook into a DTD. However, Metagenix (http://www.metagenix.com/) claims to have products that will parse cobol copy books and extract the metadata. I doubt that their products can convert a cobol copy book into a DTD; however, perhaps you could write a simple script to convert the Metagenix output into a DTD (or into an XFlat schema :-). Hope this helps. Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jun 7 19:39:00 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:52 2004 Subject: Posting Data Islands In-Reply-To: <5F052F2A01FBD11184F00008C7A4A800022A196C@eukbant101.ericsson.se> References: <5F052F2A01FBD11184F00008C7A4A800022A196C@eukbant101.ericsson.se> Message-ID: <14171.55470.707995.769641@localhost.localdomain> Matthew Sergeant (EML) writes: > Am I the only person that has come to the conclusion that XML Data > Islands are a really bad idea? I have heard almost no one suggest that they are a good one. Arguments range from "Microsoft is pushing them so hard that we have to do something" to "Let's ignore them and they'll go away", but never (yet) "Wow -- this is the solution I've been waiting for!". > I hope MS see it the same way, and deprecate them in favour of > namespaces instead. Or, better yet, (That way, legacy browsers don't have to bother downloading XML they cannot use, and one XML object can be shared among multiple Web pages.) Is anyone else but MS using these? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Mon Jun 7 19:47:30 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:12:52 2004 Subject: HAX In-Reply-To: <375BEB40.4486B0E1@locke.ccil.org> Message-ID: <000401beb10e$26c73300$efe5fea9@w21tp> > That was my first idea, but I learned that the Swing parser doesn't > do the amount of cleanup I want, so I decided to roll my own. We seem to be doing redundant work. I am also toying with my own HTML parser because Swing's HTML parser sucks mightly. I will likely use Kimbo Mundy's HTML 3.2 grammar as the starting point because Tidy source gives me a severe headache. We'll see who comes up with the best, eh?;-p > Don Park also has a SAX interface to Swing-HTML, freely available > but closed source. Actually, the source is available on request. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andyclar at us.ibm.com Mon Jun 7 19:56:16 1999 From: andyclar at us.ibm.com (andyclar@us.ibm.com) Date: Mon Jun 7 17:12:52 2004 Subject: IBM's xml4j 2.x and VisualCafe Message-ID: <87256789.0062A66B.00@d53mta06h.boulder.ibm.com> Version 2.0.x of the IBM XML4J parser uses exceptions to denote the end of an input stream (external and internal entities). These exceptions are handled internally and do not affect the running of applications using the parser. However, VisualCafe, by default, catches exceptions of type ArrayIndexOutOfBoundsException when running in debug mode. You need to turn off this automatic feature in VisualCafe in order to run an application using XML4J 2.0.x in debug mode. This option is found under Project | Options. Select the "Debugging" tab and change the category to "Exceptions". Now you'll see a list of exceptions that cause the debugger to automatically halt execution. Deselect java.lang.ArrayIndexOutOfBoundsException and select "Ok". -- Andy Clark * IBM, JTC - Silicon Valley * andyclar@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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andyclar at us.ibm.com Mon Jun 7 19:58:22 1999 From: andyclar at us.ibm.com (andyclar@us.ibm.com) Date: Mon Jun 7 17:12:52 2004 Subject: Delayed xml-dev Posts? Message-ID: <87256789.0062CFA7.00@d53mta06h.boulder.ibm.com> Did I miss a post somewhere regarding the xml-dev server? Whereas I used to receive the digest every day, I now receive it only every 5 days. Anyone else reading digest form see this? -- Andy Clark * IBM, JTC - Silicon Valley * andyclar@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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 7 20:05:19 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:12:52 2004 Subject: HAX References: <000401beb10e$26c73300$efe5fea9@w21tp> Message-ID: <375C0A56.8D7CA890@locke.ccil.org> Don Park wrote: > > Don Park also has a SAX interface to Swing-HTML, freely available > > but closed source. > > Actually, the source is available on request. By "closed-source" I mean "not Open-Source (SM)"; see http://www.opensource.org/osd.html . -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Mon Jun 7 21:13:18 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:12:53 2004 Subject: Posting Data Islands Message-ID: <805C62F55FFAD1118D0800805FBB428D0106AEED@cc20exch2.mobility.com> Actually, on the project I'm working on right now data islands have been exactly what we were looking for. (Before, when we were using IE4, we hacked up the same thing by using a hidden div.) I'm afraid it would take a huge email to explain WHY we love data islands so much, but suffice it to say that sometimes it's helpful to have some information embedded in the page that your application can read. As for the *syntax* of that data island, I don't really have a preference one way or the other. So if it was or if it was either one would be fine for me. I'd prefer not to have to use the data attribute, though, and link to a separate XML file. David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com -----Original Message----- From: David Megginson [mailto:david@megginson.com] Sent: Monday, June 07, 1999 10:43 AM To: XML development Subject: RE: Posting Data Islands Matthew Sergeant (EML) writes: > Am I the only person that has come to the conclusion that XML Data > Islands are a really bad idea? I have heard almost no one suggest that they are a good one. Arguments range from "Microsoft is pushing them so hard that we have to do something" to "Let's ignore them and they'll go away", but never (yet) "Wow -- this is the solution I've been waiting for!". > I hope MS see it the same way, and deprecate them in favour of > namespaces instead. Or, better yet, (That way, legacy browsers don't have to bother downloading XML they cannot use, and one XML object can be shared among multiple Web pages.) Is anyone else but MS using these? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Mon Jun 7 21:15:40 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:53 2004 Subject: Posting Data Islands In-Reply-To: <5F052F2A01FBD11184F00008C7A4A800022A196C@eukbant101.ericsson.se> References: <5F052F2A01FBD11184F00008C7A4A800022A196C@eukbant101.ericsson.se> Message-ID: * Matthew Sergeant | | Am I the only person that has come to the conclusion that XML Data | Islands are a really bad idea? Certainly not. I suppose most people think it's so obviously a terrible idea that they don't even bother to say so explicitly. | I hope MS see it the same way, and deprecate them in favour of | namespaces instead. I've seen nothing to indicate that this is the case. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jason at communicate.com Mon Jun 7 21:33:21 1999 From: jason at communicate.com (Jason Classon) Date: Mon Jun 7 17:12:53 2004 Subject: No subject Message-ID: <676B57969F72D211917100104B884EC6440B8F@scratchy.communicate.com> unsubscribe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990607/1ecfc19d/attachment.htm From david-b at pacbell.net Mon Jun 7 21:50:31 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:53 2004 Subject: HAX References: <199905280259.WAA14197@locke.ccil.org> <375BE1F1.515390DC@pacbell.net> <375BEB40.4486B0E1@locke.ccil.org> Message-ID: <375C22A5.3927EDF2@pacbell.net> John Cowan wrote: > > David Brownell wrote: > > > Hmm, I have a SAX2 driver that parses XML, which I'll release this week. > > I suppose you mean "parses HTML". Yes indeed ... typos abound, so much of the world has taken to writing XML when they mean HTML! I did so below, too ... ;-) > > It uses the Swing HTML parser, which is pretty universally available > > though (like all HTML parsers) it's got quirks with respect to how it > > handles faulty XML. > > That was my first idea, but I learned that the Swing parser doesn't > do the amount of cleanup I want, so I decided to roll my own. It's imperfect, but is pretty generally available (and getting moreso). It works for much, but not all, of the broken HTML in the world. And at a bare minimum, it's a good lead-in to more sophisticated packages!! I know they've worked to improve its error recovery, and will do more, though there are limits to how much broken HTML they'll accept. > Don Park also has a SAX interface to Swing-HTML, freely available > but closed source. I'll have this one under an Open Source (tm) license. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Mon Jun 7 22:51:48 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:12:53 2004 Subject: XSL Challenge Message-ID: <01BEB106.A616BA20@cc398234-a.etntwn1.nj.home.com> Roger wrote: "...Any way to do it with the Dec. 16 WD?" Roger, I thought of a kludgey way to do it with the Dec. 16 WD. You can create a stylesheet that generates a 2nd stylesheet, such that the 2nd stylesheet transforms your DynamicTable document into the desired HTML table. You would then invoke XT twice as follows: xt.exe table.xml first.xsl second.xsl xt.exe table.xml second.xsl table.htm The following XSL stylesheet converts your DynamicTable document into a stylesheet that transforms your XML doc into the desired HTML table: Dynamic Table Column[@name=""]
Hope this helps. Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Marc.McDonald at Design-Intelligence.com Tue Jun 8 03:19:21 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:12:53 2004 Subject: Namespaces are dead. Message-ID: <4454C011BDE5D211B6C800609776E5400F1814@master.design-intelligence.com> Steven Newcomb wrote: What, exactly, is the nature of the real-world problem that namespaces are the key to solving? Namespaces are still *perceived* as solving, and are often *sold* as solving, a problem that they do not in fact solve: the problem of allowing information to be exchanged in a truly open marketplace. Namespaces are being sold as the key to interchanging e-commerce information. And they will work for that purpose, BUT NOT IN A VENDOR-NEUTRAL CONTEXT, in which every system vendor can participate on a level playing field with every other system vendor, with a reasonable expectation that information will be reliably interchanged, regardless of who made the software that produces or applies the information. The problem Namespaces solve is ambiguity - the same name means different things. As Steven noted, that results in the creations of private islands of names. The problem architectures solve is synonym - the same meaning has a different name in the context of the architecture. To me, the problem with architectures is not their concept but their implementation: * If they are to work with well-formed but not valid documents, each element needs its mapping declaration attribute which is quite verbose and means a document must change with the addition of a new architecture. * If they are restricted to valid documents, then the architecture mapping attribute can be defaulted in the DTD and the content would not need to be changed with a new architecture (the DTD would). However, then it is restricted to validation parsers. It just breaks either way. I am viewing an architecture as the description of the expected form of some application that will use the document. It's preferable to not change a document just because there is a new consumer for it. I've suggested in the past that the problem that is trying to be solved is the re-use of documents under different organizational models (i.e. with different element labels). I see that as different applications parsing the same source document with different validation criteria. Such re-use should meet the following goals: * The content document should not reflect how it can be reused. * There should be a specification that describes how a document should be re-used. * The latter specification is associated with the consumer of the document, not the document itself. To put it plainly, the basic problem is putting document consumer information in the document. Doing so results in needing to modify every document every time a new consumer is created. Parsers need an additional mode - parse the element tree resulting from parsing a document according to a second DTD that is supplied by the application using the parser. This DTD expresses the mapping of elements ala architectures. This gives you architecture functionality without modifying document content in any way. It is trying to do everything in the document that creates the problem. Marc B McDonald Principal Software Scientist Design Intelligence, Inc www.design-intelligence.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From falk at icon.at Tue Jun 8 04:14:37 1999 From: falk at icon.at (Falk, Alexander) Date: Mon Jun 7 17:12:53 2004 Subject: Announcement: XML Spy 2.5 with DTD-Validation and three-view arch itecture Message-ID: Fellow XML developers, it is my pleasure to announce the release of XML Spy 2.5 final today! After many weeks of hard work and with the support of our beta testers we have finalized this new major update to our XML editor software for Windows. Version 2.5 introduces complete DTD-Validation support and the new three-view architecture: * The Enhanced Grid View is what already made XML Spy so popular with our existing customers. It shows the entire structure of an XML document in a hierarchical presentation that allows in-place editing of all elements. * The new Source View gives you the option to view the XML document in source form with customizable syntax-coloring and allows you to directly edit the source for low-level tasks. * The integrated Browser View uses Internet Explorer 5 to render your XML document inside XML Spy. This view fully supports CSS and XSL and can be displayed in a separate window so that you can keep one of the above editing views and the browser view side-by-side for maximum editing comfort. Please visit our web-server to download the new version: http://www.xmlspy.com If you have previously installed XML Spy, but not yet purchased a license and would like to evaluate this version, you may be getting reminders that your original evaluation period has already expired. If this happens to you, please send a short message to mailto:sales@xmlspy.com and request a free 30-day evaluation extension key-code to try the new version. We hope that you will enjoy this new release as much as we do! Please send any comments, feedback, or suggestions to mailto:support@xmlspy.com. Sincerely, Alexander Falk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jun 8 04:59:09 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:12:53 2004 Subject: Imminent death of Namespaces predicted (was: Namespaces are dead.) Message-ID: <001c01beb153$2fa4e450$4ff96d8c@NT.JELLIFFE.COM.AU> From: David Megginson >Rick Jelliffe writes: > > In other words, namespaces are dead (for database documents) as > > ways of uniquely naming elements independent of any other > > considerations. They are now > > "name-in-a-particular-schema-in-a-particular-schema-language--spaces". > > > > Congratulations to all concerned. > >This is a schema problem, not a Namespace one. If I have to change namespaces URIs to generate acceptable data for different uses, then namespaces are not providing universal names as they should. There are two ways around this that I see: 1) make sure that all specs that overload namespaces URIs allow content negotiation; 2) provide a way to allow multiple processes to use the same data (i.e., use PIs); These are not mutually exclusive options. I think BizTalk is a great looking framework: exciting. I have no objection to using the namespace URI to reference schemas, with the particular schema returned by content negotiation. And I have no objection to a framework only adopting a single schema language. But the current BizTalk and XML Schema details do not make any provision for multiple schemas in different languages. If both Microsoft and W3C have major applications that tie namespace names to particular technologies, then we do not have the nice layers that Dave sees: we have one layer limiting the previous layer. The namespace layer then has to be smarter, to know which namespaces to use for a document (which URI to point to schemas in the appropriate layer for the next languages). It is a schema (or higher layer) problem as Dave says, but it kills off namespaces. Another flaw I see in the idea that a document should only belong to a single schema, is that it ignores the practicalities of workflow. A document goes around through various processes and gets bits of markup added or removed as appropriate. Certain checks are appropriate to be reported at different times and to different users (this is one reason why BizTalk is exciting: the routing idea is very interesting). I hope a Schema PI would allow staged schemas for data, based on workflow phases: This allows schemas designed for particular purposes: for creating authoring templates, for asserting a consistant structure before acceptance at the browser end, etc. There should be a starting vocabulary defined for the phases. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dineshv at email.msn.com Tue Jun 8 08:40:28 1999 From: dineshv at email.msn.com (Dinesh Vadhia) Date: Mon Jun 7 17:12:53 2004 Subject: XML Search Engines ... Message-ID: <000001beb115$aae02b40$744895c1@thinkpad> Apologies for any recent repitition, but ... Could someone (or people) point me to the latest information on XML search engines ... Thank-you ... Dinesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990608/a47406c1/attachment.htm From RKarthik at CHN.CTS-CORP.COM Tue Jun 8 08:28:04 1999 From: RKarthik at CHN.CTS-CORP.COM (Raghavendra, Karthik (CTS)) Date: Mon Jun 7 17:12:53 2004 Subject: Using Data Islands with Applets Message-ID: <15BC1866E5CFD111900E00A0C9A6F35E013E47C6@CTSINCSISXUC> I have created an applet that will load a XML file and display the contents. I now want to use a data island with the applet to achieve the same thing. Is this possible and if so, how ? Thanks in advance Karthik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990608/8f30aa52/attachment.htm From james at xmltree.com Tue Jun 8 09:29:41 1999 From: james at xmltree.com (james@xmlTree.com) Date: Mon Jun 7 17:12:53 2004 Subject: XML Search Engines ... References: <000001beb115$aae02b40$744895c1@thinkpad> Message-ID: <00c601beb180$e53fb380$0500a8c0@fourleaf.com> Dinesh >Apologies for any recent repitition, but ... >Could someone (or people) point me to the latest information >on XML search engines ... Thank-you ... The ones I'm aware of are www.scoobs.com - clever XML robot which allows you to search in context (like altavista) i.e. nested inside instead of www.ibm.com/xml - plain XML robot (like altavista) www.xmltree.com - directory of XML content (like yahoo) and XML interfaces Walter Underwood tells me that Ultraseek Server 3.1 (in beta this month) will support the contextual searching that scoobs supports. Best regards, James Carlyle james@xmltree.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jun 8 15:20:18 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:53 2004 Subject: Imminent death of Namespaces predicted (was: Namespaces are dead.) In-Reply-To: <001c01beb153$2fa4e450$4ff96d8c@NT.JELLIFFE.COM.AU> References: <001c01beb153$2fa4e450$4ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <14173.3219.87318.852859@localhost.localdomain> Rick Jelliffe writes: > If I have to change namespaces URIs to generate acceptable data for > different uses, then namespaces are not providing universal names > as they should. No, Namespaces still provide a facility for universal names; that said, the provision of a facility is easy, while the process of getting people to agree to a single set of names is *very* hard. For example, I can declare that (using James Clark's notation) {http://www.megginson.com/ns/}person names an element or attribute referring a person; at the same time, Amazom.com can declare that {urn:urn-12345:ns}human names an element or attribute referring to a person. One can hardly claim in any fairness that this is a breakdown in Namespaces -- it's a business problem that (with any scheme) can be solved only by the long, laborious process of discussion, trial implementation, and standardization. Exactly the same problem could occur with Architectural Forms or any other mechanism for naming or subtyping. > If both Microsoft and W3C have major applications that tie namespace > names to particular technologies, then we do not have the nice layers > that Dave sees: we have one layer limiting the previous layer. Not at all -- Namespaces provide a universal naming layer, and RDF and BizTalk present (incompatible) application-specific mechanisms for using that information. It might be nice to standardize higher layers, but we'll have to see how things develop. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From balba at eancol.org Tue Jun 8 15:25:31 1999 From: balba at eancol.org (Bernardo Alba) Date: Mon Jun 7 17:12:53 2004 Subject: No subject 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From carl at catapultt.com Tue Jun 8 16:34:17 1999 From: carl at catapultt.com (Carl Schei) Date: Mon Jun 7 17:12:53 2004 Subject: XML Transport Mechanism Message-ID: <005201beb1bc$9b9c91d0$786f6f6f@womble> > Hi There, > > I have been pondering the following question. It is an easy one (perhaps > irrelevant), but has been bothering me - > XML is considered to be an excellent way of allowing two > applications/platforms to be able to share data in a common format. My > question is, what are going to be the accepted ways of interfacing to this > common format, i.e., If I were to develop an application that could > receive/deliver requests in XML Format, how exactly would it receive/deliver > the XML Data? > > I can think of, > > 1/ > Flat Files. An Application generates an XML File which is sent to the > another application to read and parse. > > 2/ > Over HTTP. An application will generate an XML stream that will be passed > via HTTP to a listening application. How exactly would this work - > specifically in Java? Is there a standard way of opening up an HTTP > connection and piping down the XML? Unfortunately I am not familiar with > java.net.* classes. > > 3/ > Through some specified API call. One application would call a pre-defined > method on another application using COM, DCOM, RMI etc > > -- > Carl Schei > Catapult Technology, Inc. > (630) 515-3670 phone > carl@catapultt.com > http://www.catapultt.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From malliks at rocketmail.com Tue Jun 8 17:44:09 1999 From: malliks at rocketmail.com (Mallikarjuna Sangappa) Date: Mon Jun 7 17:12:53 2004 Subject: XML Document to ascii text file Message-ID: <19990608153917.7335.rocketmail@attach1.rocketmail.com> Hi All, This is very urgent. Is there any program or tool which converts an XML document to ascii text file. Thanks in advance. CU, Malliks _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Tue Jun 8 18:39:11 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:12:54 2004 Subject: XML Document to ascii text file Message-ID: <01BEB1AC.718315A0@cc398234-a.etntwn1.nj.home.com> Malliks wrote: "Is there any program or tool which converts an XML document to ascii text file." Malliks, XSLT can do this. See http://www.w3.org/TR/WD-xslt There are several free XSL processors available. For example, James Clark's XT (http://www.jclark.com/xml/xt.html). Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gebhardt at integraliscentaur.de Tue Jun 8 18:41:43 1999 From: gebhardt at integraliscentaur.de (Gebhardt, Uwe) Date: Mon Jun 7 17:12:54 2004 Subject: How can I get an attribute datatype? Message-ID: <902B574B9DBED211BAA60008C79FE49B31C15C@exchange.centaur.de> Hello! I created a XML-File with its DTD an a schema. Then I wrote a program in Java which works with my XML data. I used the DataChannel XJParser. It is necessary for me to save the datatypes of elements and attributes. For instance, I have an element "EXTRAS". This element is empty, but it has attributes, which are from type boolean. (EXTRAS is a tag from a car-description and it should save what extras the car has, for instance: car includes Airbages: Airbag="1" else Airbag="0". ) Therefor the attribute "Airbag" has to be from type "boolean". So I tried to make my attributes from type boolean, but it doesnt work. My schema looks like this: ... ... In this case even the parsing goes wrong. I get the message: XMLDOMException18 If I change , my program gets the datatype of MODEL (from all elements) but not from Airbag (from all attributes). The dt of attributes are "null". Can anybody help me any further? Thank you, Uws -- Uwe Gebhardt Connect-X GmbH Tel.: 07131/799-100 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Tue Jun 8 20:12:26 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:12:54 2004 Subject: XML Document to ascii text file In-Reply-To: <01BEB1AC.718315A0@cc398234-a.etntwn1.nj.home.com> Message-ID: Hi, Can you explain how with just a simple example. Let's say the XML document is: This is the title One upon a time... How would you transform this XML document above into a plain asci text? Can you show it with a XSL script? regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Robert C. Lyons Sent: Tuesday, June 08, 1999 12:43 PM To: 'Mallikarjuna Sangappa'; xml-dev@ic.ac.uk Subject: RE: XML Document to ascii text file Malliks wrote: "Is there any program or tool which converts an XML document to ascii text file." Malliks, XSLT can do this. See http://www.w3.org/TR/WD-xslt There are several free XSL processors available. For example, James Clark's XT (http://www.jclark.com/xml/xt.html). Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ksievers at novell.com Tue Jun 8 21:01:20 1999 From: ksievers at novell.com (Kent Sievers) Date: Mon Jun 7 17:12:54 2004 Subject: All this buisiness about namespace URNs... Message-ID: Clearly, if we had a DNS server that was capable of mapping the URN of a name space to a URL then the requirements would be met of having both a unique identifier and a way of getting information about the namespace. Is someone stepping forward to do this sort of thing? . >>> Steve Dahl 06/04/99 02:57PM >>> Kent Sievers wrote: > I see how Paul's proposal meets the "forever unique" requirement, but how is it usefull for retrieving the namespace information? Imagine something like a DNS server, or maybe imagine subverting existing DNS servers--I don't know how well adapted or scalable they are in their current incarnations. This new DNS-like server, rather than mapping "smtp.goshawk.com" to "38.247.98.2", would instead map: urn:urn-22:19990603:xml-dev@ic.ac.uk:e-mail ..to: http://xml.org/XML/namespaces/e-mail So, when I want the documentation for the "e-mail" namespace, my browser asks the DNS-like server to map the URN to an URL, then looks up the URL as normal. If we assume that such URN servers existed, we could also assume that browsers include enough intelligence to recognize that URIs which begin with "urn:" need to be mapped through this special server. > Reguarding the collisions, I for one would be willing to live with either 1) a "forever unique" ID or 2) taking my chances with the odds on a more descriptive ID. Right, but the point is, there are a lot of people out there who wouldn't be willing to live with taking their chances. If you're creating your own namespace for your own project, I wouldn't dream of forcing you to use an ugly but forever unique ID. But if I were a customer who cared about long-term uniqueness, and I had to use your namespace, I might rebel against using an identifier that doesn't have any guarantee of uniqueness. Every marketplace that defines XML namespaces, or any sort of "global identifier", has to answer for itself what the most important characteristics of that identifier should be. And besides, who said forever unique IDs can't be descriptive? They can't be descriptive if you restrict yourself to a 20 digit integer, but if you use a more descriptive (but unique) name, they can be perfectly self-describing. > Finnally, I think that you missunderstood me on my third question. I never suggested making the URL part of the document. I am proposing that it be part of the ID. For example xmlns="xxxxxxxxx:http://www.novell.com/myproject/mynamespace" where xxxxxxx is a "forever unique" identifier and the rest is an indication of where it can be retrieved. The point is that the second part can be used to retreive, while the unique identifier can be used to identify and possibly perform a search in case the information is moved. It would be replacable/ignorable without breaking the essence of the identifier. Respectfully, no, I did not misunderstand you. What you describe here is exactly what I understood the first time. The question of whether the URL is part of the ID or is independently encoded somewhere else in the document is not important. In general, if the URL is part of the ID, it is part of the document. Namespace ids frequently are embedded in the document. If my document's root element looks like this: ... ..then the URL (by being part of the namespace ID) is part of the document, and when the URL becomes obsolete, the document contains a lie (or at best, an invalid cache). At that point, I either have a choice of modifying the document, or letting it continue to contain a very descriptive (but very wrong) URL. Neither proposition appeals to me--the first because my document may have been digitally signed, so any modification invalidates the signiture. I can't speak to the issue of leaving the URL incorrect in the ID--I don't know whether you imagine the search for the new URL based on "xxxxxxx" would be something that any browser could do, and do quickly, or not. But (IMHO) this ability to map "xxxxxxx" to an URL would have to be something that *almost* any URL-using software could do, and do quickly and transparently--let me justify that for a moment: - "any URL-using software" -- if there's documentation there, we might want to see it in a browser, or if it's in a formal language, we might want to have some program read it. Both the browser and the other programs would need the ability to map "xxxxxxx" to an URL. - "quickly" -- so that mission critical software doesn't degrade very much even when the original URL is wrong - "transparently" -- because the logic of detecting a bad URL and then searching for "xxxxxxx" is not something that we want to require human intervention to do--we would (presumably) want it to just happen. Human intervention would be especially bad if this needed to be done in a batch program. Now, assume that the act of mapping "xxxxxxx" to an URL was something most software (including browsers) could do, and it was quick, and it was transparent. If it's important enough, assume further that "xxxxxxx" is a descriptive identifier, and not just a number. If all that were true, there would be no compelling reason to use the URL that's in the identifier--if you use the provided URL, you have to include some sort of validation mechanism to make sure the URL points to a resource that matches "xxxxxxx". But assuming that searching for "xxxxxxx" is fast, you don't need to do validation on it. If you believe all that (for example, that mapping "xxxxxxx" must be fast, therefore it will be fast), then why would we ever use the URL? And if we never used it, what was the benefit of including it in the first place? Essentially, as I see it, you're saying that there *must* be a way to search for the current URL based on the string "xxxxxxx"--otherwise, if the URL disappears, the documentation disappears. And at the top of this message, I described how "xxxxxxx" could be mapped to an URL, with good performance. So if "xxxxxxx" is an URN, and we can map URNs to URLs transparently, isn't the URL redundant? -- - Steve Dahl sdahl@goshawk.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RDaniel at DATAFUSION.net Tue Jun 8 22:10:45 1999 From: RDaniel at DATAFUSION.net (Ron Daniel) Date: Mon Jun 7 17:12:54 2004 Subject: All this business about namespace URNs... Message-ID: <0D611E39F997D0119F9100A0C931315C60F755@datafusionnt1> > -----Original Message----- > From: Kent Sievers [SMTP:ksievers@novell.com] > Sent: Tuesday, June 08, 1999 11:34 AM > To: xml-dev@ic.ac.uk > Subject: Re: All this buisiness about namespace URNs... > > Clearly, if we had a DNS server that was capable of mapping the URN of > a name space to a URL then the requirements would be met of having > both a unique identifier and a way of getting information about the > namespace. > > Is someone stepping forward to do this sort of thing? . > [Ron Daniel] This has been done. See RFC 2168 and 2169 (if memory serves, I'm offline at the moment). The first defines a new resource record, NAPTR, which has been implemented in BIND for a couple of years now. It is used for finding one or more 'resolvers'. The second RFC defines a trivial protocol for communicating with resolvers using HTTP. Together, they will let URNs in a new "foo" namespace be mapped to a URL. The bottleneck here is that for the "foo" namespace you need to get the domain name "foo.urn.net" and put the NAPTR resource record there. The only way to get that domain is to fill out the application form the IETF's URN WG has been defining. It doesn't cost anything right now, and there are no plans to charge for such names that I know of, but its safe to see the registration procedure is not a smooth and polished process. (The purpose of the procedure is to prevent cyber-squatting on URN namespace identifiers, and to insulate the owner of the urn.net domain from lawsuits if he had to make the call on whether or not to register "foo"). Later, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmcdonou at library.berkeley.edu Tue Jun 8 22:27:14 1999 From: jmcdonou at library.berkeley.edu (Jerome McDonough) Date: Mon Jun 7 17:12:54 2004 Subject: All this buisiness about namespace URNs... In-Reply-To: Message-ID: <3.0.5.32.19990608131922.013e7520@library.berkeley.edu> At 12:34 PM 6/8/1999 -0600, Kent Sievers wrote: >Clearly, if we had a DNS server that was capable of mapping the URN of a name space to a URL then the requirements would be met of having both a unique identifier and a way of getting information about the namespace. > >Is someone stepping forward to do this sort of thing? . > >Imagine something like a DNS server, or maybe imagine subverting existing DNS servers--I don't know how well adapted or scalable they are in their current incarnations. > Basically, you're talking about URN resolution, and a variety of people are working on the problem. Justin Couch is writing a java package for dealing with URNs in conjunction with the IETF's working group on the topic. See http://www.vlc.com.au/~justin/java/ for more information and to have a look at his code. Some folks at MIT have proposed extending HTTP to support URNs more directly; see http://www.w3.org/People/Frystyk/draft-ietf-http-wire.txt. A lot of the focus for URN resolution has been on the THTTP convention proposed by Ron Daniel (RFC 2169). Justin's package includes a basic THTTP resolver, and I've also hacked together a THTTP server for experimental work here at Berkeley (which I haven't released, because the UI truly, truly sucks). Most of the URN crowd has been reluctant to put URN resolution on to DNS. While DNS has the advantage of being a pre-existing, proven system, it is already slightly strained, and putting URN resolution on it would add a very significant burden once URNs are more widely adopted. For more information on this, see Ron Daniel and Michael Mealling's discussion in the introduction to RFC 2169. My take on looking over the URN Working Group's documents is that the default assumption by the IETF is that client software will first turn to DNS and ask where it can find a resolver for a particular URN namespace (DNS will use NAPTR records to identify resolvers for particular URN name spaces) and then go to the resolver identified by DNS to resolve particular URNs. So if you have a URN like urn:urn-ns:ns-identifier in hand, client software will query DNS to find out where a URN resolver for the urn-ns URN namespace lives and what protocol it needs to use to communicate with it, and then will query the URN resolver using that protocol as to where the resource identified by ns-identifier lives. So, we can use DNS to establish globally where the resolver for a namespace lives and what protocol it speaks, and then let clients contact that resolver directly for resolving individual URNs. In short, yes people are working on the problem, and if you don't mind being a bit bleeding edge, there's code you can start playing with available. Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......) Library Systems Office, 386 Doe, U.C. Berkeley | \ * * / Berkeley, CA 94720-6000 (510) 642-5168 | \ <> / "Well, it looks easy enough...." | \ -- / SGNORMPF!!! -- From the Famous Last Words file | |||| xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmcdonou at library.berkeley.edu Tue Jun 8 22:57:01 1999 From: jmcdonou at library.berkeley.edu (Jerome McDonough) Date: Mon Jun 7 17:12:54 2004 Subject: All this business... In-Reply-To: <3.0.5.32.19990608131922.013e7520@library.berkeley.edu> References: Message-ID: <3.0.5.32.19990608135007.013e8100@library.berkeley.edu> At 01:19 PM 6/8/1999 -0700, Jerome McDonough wrote (without proof-reading very carefully): >Most of the URN crowd has been reluctant to put URN resolution on to DNS. >While DNS has the advantage of being a pre-existing, proven system, it is >already slightly strained, and putting URN resolution on it would add a >very significant burden once URNs are more widely adopted. For more >information on this, see Ron Daniel and Michael Mealling's discussion >in the introduction to RFC 2169. ^^^^^^^^ That's RFC 2168, not 2169. Sorry about that. Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......) Library Systems Office, 386 Doe, U.C. Berkeley | \ * * / Berkeley, CA 94720-6000 (510) 642-5168 | \ <> / "Well, it looks easy enough...." | \ -- / SGNORMPF!!! -- From the Famous Last Words file | |||| xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From fischer17 at llnl.gov Wed Jun 9 00:14:10 1999 From: fischer17 at llnl.gov (Aaron Fischer) Date: Mon Jun 7 17:12:54 2004 Subject: Inquiry: XSL Processor Engines Message-ID: <199906082216.PAA26438@poptop.llnl.gov> Greetings! I am in dire need of software that allows for the execution of XSL. Ideally, I would like an XSL engine which compiles XSL code into Java applets, but at this point I will entertain anything. Thank you for your time and whatever help you can provide. Sincerely, Aaron Fischer xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RDaniel at DATAFUSION.net Wed Jun 9 01:44:13 1999 From: RDaniel at DATAFUSION.net (Ron Daniel) Date: Mon Jun 7 17:12:54 2004 Subject: All this business about namespace URNs... Message-ID: <0D611E39F997D0119F9100A0C931315C60F759@datafusionnt1> Just to clarify a point or two in Jerry's message: > Most of the URN crowd has been reluctant to put URN resolution on to > DNS. > [Ron Daniel] Very true. Cowards that we are, none of us would like to be fingered as the person responsible for breaking the global Domain Name System. > My take on looking over the URN Working > Group's documents is that the default assumption by the IETF > is that client software will first turn to DNS and ask where it can > find a > resolver > for a particular URN namespace (DNS will use NAPTR records to identify > resolvers > for particular URN name spaces) and then go to the resolver identified > by DNS > to resolve particular URNs. [Ron Daniel] A couple of clarifications. The main point is that the DNS itself is not used for looking up individual documents, instead it is used for locating 'resolvers' which hold databases of lots of document IDs and locations. Also, we want people to use this method LAST, not first. Use local resolvers first. (For example, to resolve UUID URNs someone might write some code that first looked into the client machine's registry. Catalogs could also be used for local resolution info). If that fails, try a workgroup or enterprise resolver. (For example, at Los Alamos we used to have a demo resolver which was a proxy server that trapped URNs, looked to see if they were from a namespace our library knew a lot about, and sent them to the library's resolver if they were. Only if that failed or if they were from another namespace did we try using the NAPTR-based resolution. regards, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cpxml at yahoo.com Wed Jun 9 06:52:52 1999 From: cpxml at yahoo.com (CP XML) Date: Mon Jun 7 17:12:54 2004 Subject: XSL Challenge Message-ID: <19990609045504.18180.rocketmail@web1005.mail.yahoo.com> Hi Folks, This didn't work for me (I am using IE5). Can anybody give me the correct working version of this application. Thanks so much. -Swamy --- James Clark wrote: > You have to use the variables feature of the current > WD. Replace the > second TR element in your attempted solution by the > following: > > > > > select="../../Columns/Column"> > > expr="@name"/> > select="$cols[@name=$colname]"/> > > > > > > Roger Costello wrote: > > > > Hi Folks, > > > > Are you up for a mind-bending XSL problem? > Someone presented > > me with this problem several weeks ago and I have > yet to find > > a solution. It looks simple. It is deceptively > challenging. > > > > An XML document stores database data as follows: > > > > > > > > > > > > > > > > > > > > A > > B > > C > > > > > > S > > E > > > > > > R > > G > > Q > > > > > > > > > > Note that the columns that we are interested in > are col1 and col2. > > A element may contain data from columns not > of interest. > > But, it will always contain at least data for col1 > and col2. > > > > The problem is to create an XSL stylesheet that > generates an > > HTML table with a table header: > > > > col1 col2 > > > > and within the table it has the row data. So the > HTML table > > should look like this: > > > > col1 col2 > > A C > > E S > > Q G > > > > I have shown an XML document which has just two > columns. However, > > the XSL stylesheet needs to be generic and capable > of handling > > XML documents with any number of columns (as > listed in the > > section). > > /Roger > > > > P.S. Below is what I tried, which doesn't work. > > > > > > xmlns:xsl="http://www.w3.org/TR/WD-xsl" > > result-ns="html"> > > > > > > > > Dynamic Table > > > > > > > > > > select="Columns/Column"> > > > > > > > > select="Rows/Row"> > > > > select="../../Columns/Column"> > > > > > > > > > >
select="@name"/>
> > > > select="../../Rows/Row/Column[@name='{@name}']"/>
> > > > > > > > > > > xml-dev: A list for W3C XML Developers. To post, > mailto:xml-dev@ic.ac.uk > Archived as: > http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the > following message; > (un)subscribe xml-dev > To subscribe to the digests, > mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa > (mailto:rzepa@ic.ac.uk) > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Wed Jun 9 08:23:51 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:12:54 2004 Subject: Imminent death of Namespaces predicted (was: Namespaces are dead.) Message-ID: <001801beb238$f1230770$53f96d8c@NT.JELLIFFE.COM.AU> From: David Megginson >Rick Jelliffe writes: > > > If I have to change namespaces URIs to generate acceptable data for > > different uses, then namespaces are not providing universal names > > as they should. > One can hardly >claim in any fairness that this is a breakdown in Namespaces -- it's a >business problem that (with any scheme) can be solved only by the >long, laborious process of discussion, trial implementation, and >standardization. What has it has it got to do with business or discussions? Any application family (stylesheets, schemas, etc) which does not have a mechanism (like the stylesheet PI) to allow plurality of alternate technologies (like CSS, XSL, DSSSL) ties its names into a specific technology. W3C needs to make it standard procedure to define PIs (in whatever syntax) to allow this plurality. Everytime there is a major application family with no accompanying mechanism, it subverts the intent and use of namespaces. Instead of providing universal names, it provides application-specific names. Do you see the difference? It is a matter of providing a level playing-field. Of course we can reprocess a document at the server end and rename the namespace URIs for every different application; of course we can use content negotiation to use the namespace URI as a key to the specific application we are using; of course we can have a PI at the client that rewrites part of the DOM so that other applications can get to use the data. But it is an unnecessary complication: if we want open and extensible documents, they shouldn't gratuitously make it difficult to retarget the document for different applications. Of course when we use a different stylesheet language we may have to restructure the document for best use: but we should only have to do that to reflect the nature of the specific stylesheet language, not merely because we are allowing an *alternative* language. It is inefficent and promotes data capture, which is one of the reasons everyone wants to escape proprietary syntaxes. Data capture is when a data format gratuitously ties in data to a particular (vendor's or consortium's) technology: "embrace and extend" or "embrace and lock-out" are the same. We users demand that application-specific markup be cleanly partitioned in a documents; we want namespaces to be equally accessible for every use. > Exactly the same problem could occur with >Architectural Forms or any other mechanism for naming or subtyping. Without going into details about how much namespaces share with architectural forms...yes: it is a basic fragility of namespaces as currenly specified. It should not be solved ad hoc by discussion, but a standard procedure to enable extensibility and plurality. Namespaces are dead, not because they are wrong IMHO, but because they can be killed and are being killed, and we can safely predict that without a mechanism to prevent data capture in every public application area, they will be killed again in the future. The reason why I excluded literature in my initial post is that, with the Schema PIs, namespaces have escaped death for rendering applications. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Wed Jun 9 14:32:28 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:12:55 2004 Subject: XML Document to ascii text file Message-ID: <01BEB253.30BFF9F0@cc398234-a.etntwn1.nj.home.com> Didier wrote: "Can you explain how with just a simple example. ... How would you transform this XML document above into a plain asci text? Can you show it with a XSL script?" Didier, I have an example of an XSLT stylesheet that converts an XML document into a plain ascii text file. The XML document is not the same as yours, but it's fairly simple. Here's the XML document: ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ -----Original Message----- From: Didier PH Martin [SMTP:martind@netfolder.com] Sent: Tuesday, June 08, 1999 2:18 PM To: Robert C. Lyons; 'Mallikarjuna Sangappa'; xml-dev@ic.ac.uk Subject: RE: XML Document to ascii text file Hi, Can you explain how with just a simple example. Let's say the XML document is: This is the title One upon a time... How would you transform this XML document above into a plain asci text? Can you show it with a XSL script? regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Robert C. Lyons Sent: Tuesday, June 08, 1999 12:43 PM To: 'Mallikarjuna Sangappa'; xml-dev@ic.ac.uk Subject: RE: XML Document to ascii text file Malliks wrote: "Is there any program or tool which converts an XML document to ascii text file." Malliks, XSLT can do this. See http://www.w3.org/TR/WD-xslt There are several free XSL processors available. For example, James Clark's XT (http://www.jclark.com/xml/xt.html). Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Wed Jun 9 14:37:10 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:12:55 2004 Subject: XML Document to ascii text file Message-ID: <01BEB253.D85DD3D0@cc398234-a.etntwn1.nj.home.com> Didier wrote: "Can you explain how with just a simple example. ... How would you transform this XML document above into a plain asci text? Can you show it with a XSL script?" Didier, Oops. I sent that last message too soon. See below for an example of an XSLT stylesheet that converts an XML document into a plain ASCII text file. The XML document is not the same as yours, but it's fairly simple. Here's the XML document: Nancy Magill lil.magill@blackmountainhills.com (100) 555-9328 molly.jones@oblada.com Molly Jones (200) 555-3249 Penny Lane plane@bluesuburbanskies.com Here's the XSLT stylesheet that converts the XML document into an ASCII text file: [contact] name= email= phone= Here is the ASCII text file that is produced by the XSLT processor: [contact] name=Nancy Magill email=lil.magill@blackmountainhills.com phone=(100) 555-9328 [contact] email=molly.jones@oblada.com name=Molly Jones [contact] phone=(200) 555-3249 name=Penny Lane email=plane@bluesuburbanskies.com Hope this helps. Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 9 15:30:19 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:55 2004 Subject: Imminent death of Namespaces predicted (was: Namespaces are dead.) In-Reply-To: <001801beb238$f1230770$53f96d8c@NT.JELLIFFE.COM.AU> References: <001801beb238$f1230770$53f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <14174.27231.414880.15098@localhost.localdomain> Rick Jelliffe writes: > What has it has it got to do with business or discussions? Any > application family (stylesheets, schemas, etc) which does not have > a mechanism (like the stylesheet PI) to allow plurality of > alternate technologies (like CSS, XSL, DSSSL) ties its names into a > specific technology. There's a many-to-many relationship between names and processes. I can take names from, say, the XHTML namespace, and process them any way I want. > W3C needs to make it standard procedure to define PIs (in whatever > syntax) to allow this plurality. I think that would be a little sloppy -- I strongly dislike mechanisms that force the document itself to specify how it should be processed (and I include the stylesheet PI in that list). > Everytime there is a major application family with no accompanying > mechanism, it subverts the intent and use of namespaces. Instead of > providing universal names, it provides application-specific names. > > Do you see the difference? Not at all -- the names are universal, and the processing applied to them is application specific. Consider, again, the XHTML element. Q. What does it represent? A. A thing known as 'HTML anchor' (or {http://www.w3.org/TR/xhtml1}a). Q. How do you process it? A. Any way you want: 1. Render it underlined and in blue. 2. Allow fielded searches to find specific words in its content. 3. Recursively index the document referred to by its 'href' attribute, if any. 4. Traverse a unidirectional link. 5. Generate a loud BEEP on the user's console. 6. Typeset the contents, and generate a footnote containing the value of the 'href' attribute, if any. 7. Ignore it. 8. Use a synthesized voice with a different pitch to read it aloud. Should I have a PI present to link to some sort of action sheet for each of these, and for 1,000 other processes that I could think of? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Wed Jun 9 17:44:45 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:55 2004 Subject: XML Transport Mechanism Message-ID: <01c201beb28e$138d7390$0b2e249b@fileroom.Synapse> Carl Schei wrote: >>If I were to develop an application that could >> receive/deliver requests in XML Format, how exactly would it >receive/deliver >> the XML Data? >> >> I can think of, >> >> 1/ >> Flat Files. An Application generates an XML File which is sent to the >> another application to read and parse. Yep. >> >> 2/ >> Over HTTP. An application will generate an XML stream that will be passed >> via HTTP to a listening application. How exactly would this work - >> specifically in Java? Is there a standard way of opening up an HTTP >> connection and piping down the XML? Unfortunately I am not familiar with >> java.net.* classes. The XML data is placed into the body of the MIME message which is an HTTP request and/or response. This allows XML to be transmitted by SMTP as well. You can use a standard Content-Type: "text/xml" or "application/xml to indicate that the body is in XML format. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From carl at catapultt.com Wed Jun 9 18:10:56 1999 From: carl at catapultt.com (Carl Schei) Date: Mon Jun 7 17:12:55 2004 Subject: XML Transport Mechanism References: <01c201beb28e$138d7390$0b2e249b@fileroom.Synapse> Message-ID: <009901beb293$4b7e7d30$786f6f6f@womble> Hey Jonathan, Thanks for the info. > >> 2/ > >> Over HTTP. An application will generate an XML stream that will be passed > >> via HTTP to a listening application. How exactly would this work - > >> specifically in Java? Is there a standard way of opening up an HTTP > >> connection and piping down the XML? Unfortunately I am not familiar with > >> java.net.* classes. > > The XML data is placed into the body of the MIME message which is an > HTTP request and/or response. This allows XML to be transmitted by SMTP as > well. You can use a standard Content-Type: "text/xml" or "application/xml to > indicate that the body is in XML format. I gather that what you are proposing is that the Java program listen directly for the HTTP requests? Could this piggyback onto a web server somehow? Another proposal I found was using XML-RPC (http://www.xml-rpc.com). In the POST method inside your HTML you can execute an RPC and use as the transport mechanism XML, both as the request and the reply. I haven't figured out how your Java program would register itself with the Web Server, to expose the RPC calls that it is expecting. This would require a bit more research, on my side. Carl Schei Catapult Technology, Inc. (630) 515-3670 phone carl@catapultt.com http://www.catapultt.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Jun 9 19:28:21 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:55 2004 Subject: XML Transport Mechanism References: <01c201beb28e$138d7390$0b2e249b@fileroom.Synapse> <009901beb293$4b7e7d30$786f6f6f@womble> Message-ID: <375EA4B0.A271433F@pacbell.net> Carl Schei wrote: > > I gather that what you are proposing is that the Java program listen > directly for the HTTP requests? Could this piggyback onto a web server > somehow? Certainly. See the rpc/transport example in Sun's package, at http://developer.java.sun.com/developer/products/xml (it's now an updated release, TR2). That has both a client and a servlet component. Servlets plug into web servers; that could be Apache, or any other servet that talks servlets. The application can define whatever standard it chooses for how the data is exchanged. If XML is already in use it's easy to just exchange documents. If not, it may be desirable to use some predefined least-common-denominator DTD like "XML-RPC" does. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From stetina at icsd.mot.com Wed Jun 9 21:28:38 1999 From: stetina at icsd.mot.com (Jennifer Stetina) Date: Mon Jun 7 17:12:55 2004 Subject: scope of XML Message-ID: <910446169854D1119D4000805FED16B2927AFF@sam.casd.mot.com> I am looking for information on the following: XML-supported websites; specifically, a statistic or percentage that expresses how many of them there are today. An estimate or percentage of how big this will grow in the future How many of these sites are UK-based? US-based? If anyone knows the answers to these, or knows someone who does, please contact me. Jennifer Stetina -----Original Message----- From: Carl Schei [mailto:carl@catapultt.com] Sent: Wednesday, June 09, 1999 11:15 AM To: Jonathan Borden Cc: xml-dev@ic.ac.uk Subject: Re: XML Transport Mechanism Hey Jonathan, Thanks for the info. > >> 2/ > >> Over HTTP. An application will generate an XML stream that will be passed > >> via HTTP to a listening application. How exactly would this work - > >> specifically in Java? Is there a standard way of opening up an HTTP > >> connection and piping down the XML? Unfortunately I am not familiar with > >> java.net.* classes. > > The XML data is placed into the body of the MIME message which is an > HTTP request and/or response. This allows XML to be transmitted by SMTP as > well. You can use a standard Content-Type: "text/xml" or "application/xml to > indicate that the body is in XML format. I gather that what you are proposing is that the Java program listen directly for the HTTP requests? Could this piggyback onto a web server somehow? Another proposal I found was using XML-RPC (http://www.xml-rpc.com). In the POST method inside your HTML you can execute an RPC and use as the transport mechanism XML, both as the request and the reply. I haven't figured out how your Java program would register itself with the Web Server, to expose the RPC calls that it is expecting. This would require a bit more research, on my side. Carl Schei Catapult Technology, Inc. (630) 515-3670 phone carl@catapultt.com http://www.catapultt.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From james at xmltree.com Wed Jun 9 22:00:47 1999 From: james at xmltree.com (james@xmlTree.com) Date: Mon Jun 7 17:12:55 2004 Subject: scope of XML References: <910446169854D1119D4000805FED16B2927AFF@sam.casd.mot.com> Message-ID: <007001beb2b1$eea83870$0500a8c0@fourleaf.com> Dear Jennifer Some websites that provide xml content or xml interfaces are listed at www.xmlTree.com > XML-supported websites; specifically, a statistic or percentage that > expresses how many of them there are today. The number of websites which have made public their activities is still extremely small - I would guess less than 1000. I am sure that more private ones exist (I am informed, for example, that the intranet systems that Dialog Corp supplies are being rewritten, based on xml, and that Dell is exchanging product information using xml), but the business case for making public xml interfaces and content available hasn't been clearly identified yet. If anyone does know of other cases of xml content provision, I'd sure like to know! Best regards, James Carlyle james@xmltree.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Jun 9 23:56:18 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:12:55 2004 Subject: scope of XML References: <910446169854D1119D4000805FED16B2927AFF@sam.casd.mot.com> <007001beb2b1$eea83870$0500a8c0@fourleaf.com> Message-ID: <375EE261.4C7031D2@pacbell.net> "james@xmlTree.com" wrote: > > I am sure that more private ones exist... but the business case for > making public xml interfaces and content available hasn't been clearly > identified yet. And it's been complicated by inconsistent browser implementations of XML (vendors: get behind the Oasis effort!) and its supporting standards (ditto, www.webstandards.org). For example, I've gotten very good XML+CSS support out of Mozilla M6 but it hasn't worked very well with IE5 (no list styles, "pre" breaks, etc); and no browser conforms to XSL yet. Given that status quo -- the role of XML isn't yet downloading XML to clients. But I suspect that role will increase ... :-) - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jun 10 00:43:59 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:12:55 2004 Subject: Inquiry: XSL Processor Engines In-Reply-To: <199906082216.PAA26438@poptop.llnl.gov> References: <199906082216.PAA26438@poptop.llnl.gov> Message-ID: (Replying only to xml-dev.) * Aaron Fischer | | I am in dire need of software that allows for the execution of XSL. | Ideally, I would like an XSL engine which compiles XSL code into | Java applets, but at this point I will entertain anything. SAXON can compile XSL stylesheets into Java code (intended for server-side use, but worth a look): --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mlelist at citec.fi Thu Jun 10 01:17:50 1999 From: mlelist at citec.fi (Michael Leventhal) Date: Mon Jun 7 17:12:56 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach References: <805C62F55FFAD1118D0800805FBB428D0106AE8D@cc20exch2.mobility.com> Message-ID: <375EF568.CB9DC3FF@citec.fi> The following article was posted on the xsl-list and the newsgroup comp.text.xml. My apologies to those that read more than one of these lists. Although most of you are probably tired on the XSL debate by now I felt this would interest some on this list. Mr. Deach, chair of the XSL Working Group, issued a personal response to my article in xml.com "XSL Considered Harmful" in the xsl-list mailing list. I felt his thoughtful article merited a follow-up from me. My other responsibilities have prevented me from answering many other equally compelling articles, for which I beg your understanding. I think Mr. Deach has done a good job of bringing most of issues into sharp focus so I hope these comments will answer the questions of many others as to my views. I am happy to let anyone that wishes to follow up on this article have the last word as I have had ample opportunity to let my thoughts be known but if anyone is terribly keen to pursue any particular point further please cc my email address at michael@textscience.com. I am at your service. The complete text of Mr. Deach's Response is quoted in sections in this article. > As a member of the XSL working group and having worked in the computer > industry for over 20 years on a broad spectrum of products to author, format, > and render communications vehicles of many kinds, (word processors; DTP > applications; commercial newspaper, magazine, directory, catalog, and > advertising production tools; slide show authoring; data base and document > management systems; web site authoring; photo image editing and retouching; > charting, illustration and engineering graphics; font creation and rendering; > and the internal software in typesetters and printers, etc.), some making > extensive use of structured content and stylesheets and some making little or no > use of stylesheets, I certainly qualify as an expert in document modeling, > content editing, styling, and formatting tools. I have seen debates of this > nature many times and prefer to ignore them, as they usually blow over. In this > case, due to the timing and the stridence of his statements, I feel it is > necessary to respond with my personal opinions on Mr. Leventhal's so-called > challenge. I further feel that it is necessary to respond because he makes a > series of claims (which I believe to be false) and then directs you to reach the > same conclusions and so vote. I appreciate the fact that my colleague, Mr. Deach, chair of the XSL Working Group, has taken the time to respond to my article and has taken considerable care in so doing. Perhaps it is appropriate to state something about my background as well. I have spent slightly little less time than Mr. Deach in the computer industry, about 16 years. One important difference in our experience is that the greater part of my career was not spent in the area of document-related tools and products. Among other things I spent many years working on software used in the design of integrated circuits and in magnetic resonance imaging. The last seven years of my career have been dedicated to electronic document software, touching on both structured and unstructured document technologies. I worked on a pre-Web SGML browser called Oracle Book, have been involved in the Web since its earliest days at CERN, and am currently working on my second browser, this one based on the mozilla open-source code. The reason I think my non-document related background is important is that it has always given me a different perspective on technologies like SGML and XML from that which is common to the vast majority of people working in this area. Most of my colleagues have traditionally had publishing-related backgrounds. I felt that SGML had the potential to fill a very critical niche as an information as opposed to document-related technology but simply had too much dross in it originating from the technical view of the publishing industry professionals that made the heaviest contribution to the development of the standard. I argued for a "purification" of SGML and at least some of my ideas had an influence on the creation of XML. I am still dissatisfied with XML as it still carries some of the dross from SGML but in this imperfect world it is something I can live with. I believe that at the core of the debate is the difference in view between those that see XML and the web primarily as an engine for traditional ideas about document publishing and a broader view not tied exclusively to publishing that sees XML as the primary interface layer to the multitude of ways in which we can use knowledge, computers, and networks. I should also mention again (it was already stated in the article) something about my experience with transformation. It did occur several times in the debate that noted advocates for XSL made the claim that I or anyone else that disagreed with their position did not understand XSL. Along similar lines some have said that my article was motivated by my economic interests. I have not responded to such statements since to the discerning reader they do more discredit to the person making them than they could ever do to me. But I do know and understand XSL as well as DSSSL as well as at least a dozen other approaches to transformation and have made my living as a professional in this area for several years, choosing the best and most efficient tool for the job without the least interest in ideological debates. I may add that I have received very strong support from my colleagues in this field who are today, as I was in the past, making their living from doing XML transformation. And my support for and preference for CSS goes back at least to 1997, long before I undertook my current project, as is evidenced by my article "XML and CSS", published in the W3C Journal in that year and reproduced in the very first issue of xml.com. Mr. Deach mentions the "timing and stridence" of my article. While I will always be extremely quick to apologize for rhetorical excess and any hint of impoliteness (difficult to avoid from time to time in this medium) I do think that the timing is appropriate and the stridence is proportionate with respect to the overall situation. I would like to share with you my view of "how the war began". I don't think you will find any stridence at all in my article "XML and CSS" or my book published last year, "Designing XML Internet Applications" (where I discuss both XSL and CSS) although I did not hesitate to express some doubts about XSL (or DSSSL) and to praise the simplicity and power of CSS. However, the situation begin to look very different in the last six to nine months when we saw Microsoft refusing to commit to correct support of CSS while introducing XML to web world in IE5 beta through XSL and conversion of XML to HTML on the client. I begin routinely encountering web users who had absolutely no idea that it was even possible to display XML without transformation to HTML - using, of course, Microsoft XSL. To make matters worse, what users were encountering was a proprietary implementation of XSL far in advance of even the Proposed Recommendation stage which would give it status as at least a probable future web standard that would be reliable in its broader outlines. In my view experts in the XML community were doing everything possible to encourage this state of affairs - there was quite nearly a "blackout" on the mention of alternatives to transformation and alternatives to formatting such as CSS. You can not find better proof of this than the fact that neither CSS nor the DOM is even mentioned as a "standards related to XML" on the SGML/XML on the Web Page. As I said to Robin Cover, the editor of the SGML/XML on the Web Page, this is a profound disservice to the newcomer to XML who has no indication that the simple stylesheet language he may already know from his use of HTML can be used to quickly display his XML in a web browser supporting current W3C standards. Instead he is directed to use a declarative transformation language which is still a W3C Working Draft to do a document-to-document transformation to a new presentation-oriented XML language for which no implementation in browsers currently exists. I realized what a disastrous situation had emerged, and to large measure been created by the XML community itself. The Microsoft browser supports XSL transformations and the Mozilla browser took the CSS route. The very raison-d'?tre of the W3C had been shot straight through the heart as it was not going to be possible to create one XML web page with one stylesheet and to see it correctly displayed in any browser. And all partisanship aside it was obvious who was right and who was wrong: CSS is a W3C Recommendation, XSL is not. I decided that I must speak out on this issue. I began posting to comp.text.xml but met mostly incomprehension from people coming over from the Microsoft XML list that were convinced that the only proper way to handle XML documents was to use Microsoft XSL to convert them to HTML and from the few XML folks that deigned to pay attention and only wanted to deflect the argument into a pointless debate about whether transformation programs were better written in XSL declarative syntax or in a procedural language. One person who finally did respond was Ken Holman after I confronted him on the stage at the Swedish XML/SGML User's conference with the statement that XSL advocates bore heavy responsibility for ensuring that we did not have a common stylesheet language for XML in browsers. Ken was unable to respond directly to my perfectly accurate assertion but reiterated that he thought that transformation was important and that XSL was the way to do it. He later wrote the article that appeared in xml.com where he attempted to diffuse the "perceived controversy" between XSL and CSS although without addressing the major points of the controversy. My article in xml.com was originally entitled "A Rebuttal" and was no more than attempt to present the an "other side" which heretofore had been suppressed by the XML community. But it was not actually when I read Ken's article that the "war" began, it was a bit earlier when I read Tim Bray and Jon Bosak's article in Scientific American where it was stated that XSL was "the" stylesheet language for XML. In demographic terms Scientific American readers are one of the most influential publication-defined communities on the planet. It was then that I said "This is war, it has to be a war." Finally, Mr. Deach says I make a series of claims which he believes to be false and goes on to, in his view, refute them. When I made my "declaration of war" I did make a strong and open challenge to XSL and thereby exposed myself and my ideas to, shall we say, extremely intense scrutiny by XSL advocates. Frankly, I am surprised that I did as well as I did, I think that in that an impartial judge would say that each of my major points essentially held. On many points there was essentially no debate whatsoever. For example: A programming or scripting language with the DOM provides a more powerful transformation capability than XSL-transformation. XSL-FO does not provide any clear advantages over CSS formatting and CSS is, in fact, a powerful formatting language for XML. XSL provides no solution to interactivity. These three points alone represent to me an enormous, "captured ground". The fact is that the whole situation is completely reversed from what it was before I launched my "war". The person looking into XML today is not going to hear that XSL is "the" stylesheet language for XML. No one is going to claim that CSS, which happens to be the current W3C Recommendation, is not a viable alternative to XSL, no XML consultant would dare not to mention CSS. No one can claim that there are no alternatives to XSL transformations or even that XSL transformations are indispensable. No one can ignore the fact any longer that vendors have not agreed on a single stylesheet standard for the Web. The large numbers of people that do not want a declarative transformation language, do not want to go through a document-to-document transformation to even see their XML documents, and do not want a supercharged FONT tag language to replace semantically-rich XML now understand that there are viable alternatives - that these things are not "the" XML story. Those that think XML should be useful in creating a real application environment in Web browsers are relieved to know that XSL is not "the" XML story. I have not enjoyed the "war", I would rather express myself in very cool code rather than write articles, but I think I have reason to be proud of these accomplishments. And on these points alone it is clear that the correct action for W3C members remains, clearly, to vote against an XSL Recommendation. As it currently stands this is very essential because XSL-FO must be dropped. XSL-FO is entirely redundant with CSS, restricts or eliminates interactivity, and encourages or even requires the elimination of semantic information from transformed Web documents. Even among those who staunchly defended XSL-transformations there was broad support for this position. The least that should be done is to separate XSL-FO and XSL-transformations into two entirely separate initiatives. I also advocate against approving a separate XSL-transformation Recommendation as XSL-transformation does not serve any of the purposes for which the W3C creates Recommendations. Recommendations are there for key infrastructure which must be interoperable. Multiple and redundant recommendations work against, not for, interoperability. A document-to-document transformation language like XSL has not been shown to be an interoperability requirement and in any case is redundant with already existing Recommendations. No one has successfully argued that the existing Recommendations are inadequate, let alone that they could not improved to add new capabilities. That said, there is no reason why work on XSL-transformation can not or should not continue outside of the W3C. An additional XML tool is always welcome as long as it does not compromise the interoperable environment of the Web. > I must at this point, for legal reasons, re-emphasize that these are my own > opinions and not necessarily those of the XSL-WG nor necessarily those of my > employer. > The timing of his challenge is inappropriate because XSL is still a working > draft, yet he claims XSL is deficient because: If the timing of the challenge is inappropriate it is clear that the timing of the debate is not. But the XSL community has accepted my point that other transformation methods are more powerful than XSL. No one has suggested that a later point in time XSL will be more powerful than can be imagined or realized today. > a) XSL is a future technology > Response: This is what a working draft is, by definition, a future > technology. Every technology goes through this phase. > > b) The specification is in flux and there is significant change from > draft to draft > Response: Keeping the public informed about the current state of the > W3C's efforts, making the rate of change and degree of change visible to the > public is exactly W3C's goal in requiring the publication of working > drafts. > > c) Only limited preliminary tools to use it exist > Response: but tools do exist and the users of these tools have > provided substantive feedback that has lead to improvements in XSL. > > d) Those tools are incomplete or don't implement the latest version > of the draft > Response: Again, exactly what one would expect as a specification > evolves. Yes, so I have said myself, and stated that responsible conduct by the XML community would have been to point new users and vendors at existing Recommendations. > The terms of the challenge are extremely vague, they can be tailored so that > both sides could declare victory. The outcome of a challenge whose 2 criteria > for measurement "better" and meaningful" is guaranteed to be indeterminate. Both > terms can only be measured "in the eye of the beholder". > A number of claims are made about the value of XSL on the web. Many of these > claims are either false or they completely miss the point. Well, ok. Let's see. > Claim 1 Interactivity is a requirement for a technology to be useful > on the web. > Response: This is completely false. The vast majority of web sites are > essentially static. Interactivity, beyond traversal/addressing and some level of > data-entry (form fill-in) has little value for a huge class of meaningful > sites/documents. I really can't see the connection between "completely false" and the explanation of why that might be so. I think I'll just stick to it, a transformation technology which does support interactivity and the browser environment pretty much has no role to play in a browser. As I put it, "in the evolution of web technology into the new desktop", close to an irrefutable statement. It may not be true that the vast majority of web sites are essentially static but certainly the fast majority of web pages are. But evolving web technology doesn't exist to create a web as it exists today. I think I provided a pretty good list of real interesting things that can be done with interactivity "beyond traversal/addressing and some level of data-entry" in my article. And I don't think the web community in general is going to share Mr. Deach blas? feeling about interactivity. > Claim 2 XSL precludes interactivity. > Response: No more so than CSS. Well, does Mr. Deach care about interactivity or not? It is DOM+CSS that I described as the combination that gives transformation and interactivity and styling. > Claim 3 Print has no place on the web. I said the Web is "not about paper documents" and the web was not the place to do page composition. Everyone likes to be able to print documents, that isn't the issue, it is whether you should expect to get FrameMaker+SGML documents out of a web browser or not using a page composition engine. > Response: This issue has been discussed extensively in the XML.com > mail forum and on the mulberrytech.com's xsl-list (public comment list for XSL). > The fundamental responses have been: > For a large number of people, print is important. The web is as much about > formerly paper-only documents and print-on-demand as it is about interactive > and animated ones. For which there are existing technologies, fortunately not inside the browser. > Paged composition is not significantly more computationally intensive than > browser formatting. Ridiculous. > Paged views (fit to the window and/or page) are extremely useful for some > content. For which ... existing technologies ... > Claims that the market for repurposing is a handful do not explain the > robust attendance in these sessions at Seybold Seminars and other conferences > for the past 3 years. Repurposing has nothing to do with whether a page composition engine should be inside a browser. > Though one could create separate stylesheets in CSS for viewers, XSL for > print-on-demand, PDF for critical print, etc. I don't want to if I'm not > forced to. The training cost and error rate is unacceptable. The vast majority of web users don't even want to create stylesheets, let alone declarative transformation programs like XSL. FINALLY, as H?kon Lie has pointed out, even if you want to do page composition in the browser XSL still does not do that for you. Transformation is far from enough. > Claim 4 XSL is a danger because it removes semantic meaning. > Response: XSL allows you to preserve the semantic meaning of your XML > by not polluting the XML with presentation (as happens in HTML and in HTML+CSS > today with semantic-free divs & spans and with the widespread misuse of the > remaining tags). What does HTML have to do with using XML and a stylesheet? FOs are a font tag language which remove the semantics from otherwise perfectly fine XML that could be displayed with CSS or transformed with the DOM and keep all the semantic information. That simple! > Claim 5 FOs are bad > Response: A related FUD issue to the claim that they remove semantic > meaning. This issue originated in a paper posted by Mr. Lie (and referenced by > Mr. Leventhal). You should also look at the archives of the mulberrytech.com's > xsl-list to evaluate the response to Mr. Lie's paper and e-mails. Many of his > key points were disputed or discredited. Our distinguished colleague and author of a very thoughtful and cautious paper is furthest thing from a dispenser of "FUD" that I can possibly think of. I combed through every single article in the Lie-Prescod FO debate and I came to conclusion that Mr. Lie's arguments were rock solid which is why I simply pointed to his paper rather than try to better his statement of the problem. There was a major sidetrack on HTML and divs which I found not at all relevant. > I refer you also to James Tauber's response to this issue: CSS tags ARE > formatting objects. The 'display' property identifies the fundamental formatting > behavior of the element, this is exactly what an XSL-FO does. I would add: > XSL-FOs are simply more general (cover a broader scope), and defined in a manner > that has fewer side-effects (interdependencies). If anything, CSS is the > "supercharged FONT tag", XSL at least compartmentalizes the side effects. Yes, I like this line of argument very much because I realized the reverse is even more true and it blows away your entire rationale for having an FO standard. Just improve CSS however you like and if someone wants an FO language they can make elements fo1 to fo653 and map each of them to a CSS style. Fortunately it is going to be really rare than anyone needs to do that and for the majority of users they will be introduced to simple CSS stylesheets that encourage them to think stylesheet and semantics rather than going into the whole business of transformation to another language. The FOs nearly guarantee word processor-like stylesheet abuse. Really, it often seems to me that you want to turn the Web browser into Microsoft Word! > Claim 6 XSL gives me nothing new > Response: There is a huge class of documents that are not made > available on the web, because either formatting/pagination is inadequate using > existing standards, or because they must be broken into little sub-documents for > presentation. XSL gives me a much more convenient and format-rich way to > transition this broad class of paper documents to the web. XSL also makes it > easier to build stylesheets for those documents that need to be authored for > both online and print media (including print-on-demand). We are back to the Print arguments, please see above. Nothing new in this nothing new section! > In this class of documents I would include: any document used in a business > transaction or legal context (including proposals, requirements documents, > contracts, court filings, insurance policies, tax documents, safety notices, > forms); any document used in a design or manufacturing context (design and > manufacturing specifications); any document used in a service, customer > relations or customer support context (various types of manuals, instructional > inserts); any document used in promotional context (catalogs, e-catalogs, > newsletters, brochures, and mailings); any document used in an educational > context (including textbooks); and the bastions of traditional print > (books/e-books, newspapers (?), magazines/e-zines). These documents are > meaningful because people either pay for them or pay to produce them. > Claim 7 I can do all the formatting you can by adding a few minor > tweaks to CSS > Response: Anyone who has built more than one or two formatters (and I > have built over a dozen) recognizes that to add proper pagination and layout to > CSS requires quite a bit more than a few tweaks. Again, see Print. Where should page composition be done and with what tools? XSL isn't enough. Let's have the whole story. On the other hand, simple pagination is a reasonable CSS goal. > Claim 8 Anything you can do in XSL, Mr. Leventhal claims he can do in > some combination of existing web standards: the DOM, CSS, and scripting > Response: One, not all the technologies referred to are web standards or W3C Two, at least. Right? And for the scripting, ECMAscript by reference and the language-specific binding in the DOM make the third at least debatable. > Recommendations. Two, this misses a key point. As a programmer, Mr. Leventhal > can do anything. But most users aren't programmers and vehemently don't want to > become one. XSL can be built into tools that the web designer or graphic artist > can use, that are predictable and implementable. Dealt with adequately and fairly in my paper. What is false is that XSL makes anything difficult any easier. Just about any serious transformation takes someone with the skills equivalent to some kind of programmer. Fortunately the vast majority of web documents will be very happy with a CSS stylesheet. It is XSL that sets the entry bar unreasonably high. And not only are we not going to see reasonable transformation scripting tools that for graphic artists but most people would rather you didn't hand them a language for which they must have such tools before they can do anything. > Claim 9 XSL didn't take into account anything learned from history (I > assume this means CSS) I don't know where this is from. My two favorite themes have been the history of the development of programming languages (declarative transformation languages have been tried and failed) or the history of the evolution of the web (stepwise refinement of the existing environment unless there is a truly compelling leap possible). The discussion which follows about XSL and CSS is not a point I have ever gone into. > Response: This is completely false. XSL had significant participation > from users and implementors of CSS as well as participation by a number of > members of the CSS WG, including the CSS&FP chair. In addition, the XSL WG > membership includes participants that worked on DSSSL and/or have experience in > building commercial formatting and authoring products that averages 10+ years > each. > XSL includes all the formatting capability of CSS and nearly all the CSS > properties (verbatim). It similarly includes much of the capability of DSSSL, in > a more approachable manner. > And no, XSL is not "DSSSL in sheep's clothing". The XSL submission and > charter require the XSL WG to support the functionality of both CSS & DSSSL. > Well over half the effort of the group defining the XSL formatting objects was > to understand the full capabilities, the property interactions, the > discrepancies, and the limitations of BOTH these formatting languages, then > redefine the formatting model in a compatible manner. XSL fully incorporates the > formatting capability of CSS. > DSSSL was a well-thought-out solution to most of the problems that they were > trying to solve. That problem differs from XSL's, hence DSSSL is not a > sufficient answer to the web formatting problem. > The same can be said of CSS, it is a good solution for the problem that it > was originally intended to solve. However, attempting to extend it to solve the > range of problems that XSL is intended to address will make it an ugly and > unimplementable language. A different architecture is required to support some > of the extensibility that XSL requires. > As with any solution there are things one didn't consider, mistakes that are > made, and features deferred to the next release. Because a solution isn't > perfect doesn't mean it isn't useful. (If that were true, we should ban HTML, > CSS, XML, XSL, SGML, & every other W3C, ISO, ECMA, IETF, etc. standard. None > are perfect.) But we have never had a complete implementation of CSS1, let alone CSS2. I wonder how much we can all really understand so we can build on this effectively? We had many years to think about the flaws of SGML before we created XML. We had an enormous test bed for each revision of HTML before the next came along. We have not gone up the learning curve with CSS. I hear claims like "DSSSL is not a sufficient answer to the web formatting problem", and a "different architecture [from CSS'] is needed to support some of the extensibility that XSL requires" without support for the assertions. I don't think either of these assertions are true. DSSSL does arbitrary transformation, period. What is wrong with DSSSL? What is meant with "different architecture" is usually simply the transformation capability. Which has been shown can be done in other ways, when and where it is needed. > Claim 10 XSL is in competition with CSS. > Response: Most of the developers of XSL consider the 2 complementary, > not competing. CSS provides a convenient and workable mechanism for those > documents to which it is suited. XSL extends the market to documents and styling > requirements that are not well addressed by CSS. The W3C has established a joint > committee to maintain compatibility between XSL's & CSS's formatting models > and properties. Well, let's see you get 100% beyond a full CSS1 and CSS2 implementations in browsers, let's see you second my (polite and appreciative) note of protest to the SGML/XML on the Web page about the omission of CSS as a related XML standard, let's see you amplify my warning about the fact that we do not have a single stylesheet standard for XML today and maybe, maybe, I will begin to lend some credence to your claim here. > Claim 11 XSL is hard > Response: Experience with the preliminary implementations of XSLT have > shown this to be untrue. For simple things, XSL is no harder than CSS. For some > of the more complex things (that one can't do in CSS alone, it does become more > difficult, but it is less difficult than learning the DOM and scripting for > someone who doesn't already know them or for someone who isn't a programmer. Stylesheets have been a part of the web for years as well as part of authoring tools for many more years. This is a somewhat familiar concept to the average computer literate person. It is preposterous to suggest that document-to-document transformation is as easy as a stylesheet. I have compared the difficulty of DOM and scripting compared to XSL on the basis of experience with declarative vs. procedural languages on the fact that programming languages support modular construction and other features to ease the writing of maintainable programs, and that virtually any programming language is will permit one to perform a plethora of common and essential tasks that are not supported in XSL. I haven't seen any refutation of these points. > Claim 12 Scripting is more powerful than a declarative language > Response: This is true, as far as it goes. It also forces everyone to > be a programmer. XSL is a declarative language, not because declarative > languages are easier to use or more powerful, it is because declarative > languages are more implementable and more reliable. Having had firsthand > experience with PostScript (a procedural language) and PDF (a declarative > language) prior to joining Adobe, one finds that one gets only moderate gains in > the ease of authoring in the declarative language and that the declarative > language does have some limitations in capability. The biggest gain in switching > to a declarative language is in predictability and reliability of the authored > input (it can be validated) and in the ease of developing correct > implementations of the formatter. If the goal of all this were just to write a formatter. So are you willing to say that as a general transformation engine XSL is not really useful and that it really is designed only to provide one part of a page composition engine? > I can always find a class of problems where a highly tailored solution is > cheaper than a general one (or where a specific programming language solves a > problem better than another language), however, this is not the true cost of > that solution. I must always ask: a.) Does the general solution cover my problem > space? If not use another tool or a mixture of tools. (However, because it > doesn't meet this criteria for your problems doesn't mean it isn't useful for > mine.) b.) Does it support my aggregate of problems at a lower cost than custom > tailored solutions to each individual problem. (However, because it doesn't meet > this criteria for your problems doesn't mean it isn't useful for mine.) c.) If > there is a significant subset of my problem space that can be answered by a > cheaper solution, shouldn't I adopt it? (YES). If the remaining problem space > can't be cost-effectively covered by the cheap solution, shouldn't I be allowed > to solve the problem using a solution appropriate to that problem space? (YES, > if truly cost-effective) The analysis is fine but the question still remains - how narrow is the solution space? The professionals from the transformation field are saying that XSL is too narrow for general transformation. I don't see any disagreement with this essential point. I think that in addition to joining me supporting CSS you probably should also be with me on the DOM and transformation as well. If you are willing to admit that all XSL can and should do is perform page composition I'll be only too happy to leave you in peace. > Claim 13 XSL stands no chance of being accepted on the web. > Response: I don't think this claim holds any water. IBM, Lotus, and > Microsoft have all announced support for XSLT. James Clark, Lotus and Microsoft > have released demonstration implementations. Several implementations of > formatting software have been announced and James Tauber demonstrated his at > WWW8 (two weeks after the latest Draft was available). I think there is clear > support for both the transformation and the formatting components of XSL, and > this is a fairly strong commitment for a draft specification. The feedback these > implementors and the WG are receiving do NOT substantiate Mr. Leventhal's > claims. People find this language useful, sufficient for most intended tasks, > and understandable (albeit non-trivial to learn). Improvements have been made to > the transformation language as a result of this substantive feedback." Well, I've been getting different feedback. I don't think we've heard from the broad web community yet. The W3C is not a purely industrial consortium and we have a self-interest as well as human interest in taking into account the effect of what we do on humankind for whom the Web has become the gateway to our collective knowledge. XSL is not a technology which is going to make participating in the Web easier or better for the majority of users and it is not to enable critical applications with additions to the infrastructure which do not exist today. > Conclusion > With every change in technology, there are a number of people who have fallen > in love with the status quo and attempt to derail the evolving new technology. > They say such things as: the new technology is some pipe dream of the future, it > is unproven, it is inefficient, it is hard to learn and hard to use. It is a > threat to what I know and love; something new I am being forced to learn. -- On > the new technology's inception, certainly all those things are true, but what > happens in 2 years? What happened when people moved from FORTRAN to Pascal? from > Pascal to C? from C to C++? from proprietary printer/typesetter languages to > PostScript? from PostScript to PDF? from proprietary composition systems to DTP? > from ink, rubylith and darkrooms to Illustrator and Photoshop? The same thing > will happen to the web's content and styling standards, the technology that > provides an answer to your problem will become the one that you use. Some will > fall to disuse, the remainder will live on and complement each other. > Mr. Leventhal appears to be saying that the web world can not be allowed to > advance beyond what it has today. Nor does it appear that he would allow the W3C > to define alternate approaches to a problem or define new approaches to problems > that are not well served by existing W3C Recommendations if there is any overlap > between this alternate solution and an existing Recommendation. Such a policy > would be crippling to the future growth of the Web. The most amusing thing I read in the whole XSL debate was the article by a gentleman who attempting to depict me as a grouchy old grandpa sitting in a rocking chair on his sagging porch, chewing on a pipe and grumbling "Dag-nabit, all those young whipper-snappers want to go and change everything, why in my day we didn't have all those darn-tootin fancy languages, why we wrote computer programs in Assembler and if it didn't work we just tapped on those darn transistor tubes and everything worked just fine, those were the days". Arguing against a technology which one considers a wrong turn and a serious one at that is not the same as being against technology progressing. Obviously. > If XSL provides a better mechanism to support online presentation, it is > clearly in the web community's interest. Not demonstrated. > If it provides a better solution to > print it is clearly in the web community's interest. First we need to define the problem as such and not a problem of general transformation or styling. Once we do that we need to know a little bit more about the formatting backend. And than we will decide if it is all worth it. > If it provides a common > mechanism to support print and online presentation it is clearly in the web > community's interest. If it does all of these, even better. There is no sense to "common mechanism". It appears that we have a good online presentation system, Mr. Deach argues that we need a page composition system, and there is no argument defending the idea that they need to be common. > From preliminary indications, XSL seems implementable and useful, thus Mr. > Leventhal's request to stop work on XSL (at least until CSS-2 is fully > implemented on every platform) is not only unrealistic, but is detrimental to > the web, since it would delay widespread support for XSL. > One size does not fit all. If you are happy with CSS, the DOM, and scripting > then use them; but don't prevent me from solving my problem. You are welcome to solve your problem. The question whether you should have a W3C Recommendation to do it with since W3C Recommendations, if they are to remain meaningful, become an indispensable part of the interoperable Web infrastructure. Michael Leventhal xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at qub.com Thu Jun 10 03:12:47 1999 From: paul at qub.com (Paul Tchistopolskii) Date: Mon Jun 7 17:12:56 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach Message-ID: <005201beb2de$fed35860$dad6d6cf@g0f2n0> Hello. >> Claim 3 Print has no place on the web. > I said the Web is "not about paper documents" and the web was not the > place to do page composition. Everyone likes to be able to print > documents, that isn't the issue, it is whether you should expect to get > FrameMaker+SGML documents out of a web browser or not using > a page composition engine. One practical comment. Even Web is "not about paper documents" ( actualy I don't understand what does it mean ) there is some constant need to place documents with complex layouts to the Web. (It's why we have a buch of RTF2HTML, MIF2HTML e t.c. converters, Net-It startup e t.c.). I spent a couple of months implementing '1-to-1' converters for RTF and MIF, trying to keep tables, N-columns layouts e t.c. Of course supporting all the goods is impossible with HTML, but it is not my point. With MIF you can ( more or less ) do XML / CSS without reimplementing FrameMaker rendering engine, because MIF keeps columns content separated ( thanks to Frame ). With RTF if you want to render layout with 2 columns and if you want to go XML / CSS you *should* reimplement some *significant* part of Word rendering engine ( simply to understand where the contents of first column ends ;-) It's why MS Word from Office 2000 still has some ...problems ... with complex RTF layouts... Being implemented, FO can handle both RTF and MIF resanobly easy ( resanoble and easy ). I'm just saying that FO model can handle some things with complex layouts *much* better than CSS / DOM e t.c and people *do* need complex layouts on the Web. > XSL-FO does not provide any clear advantages over CSS formatting and > CSS is, in fact, a powerful formatting language for XML. That is not true. Mapping complex RTF document to FO is doable. Mapping it to CSS seems to be *impossible* without rewriting significant part of Word rendering engine ( or FO engine ;-). The funny thing is that after implementing XSL FO you *can* render such things to CSS, because ... well ... XSL FO rendering is hard to implement, but being implemented it is powerful. Of course, you can replace 'RTF' with 'FORMAT X' ( even FORMAT X would be XML. Nobody can predict what particular XML would be created by some vendor in the future ). > If the goal of all this were just to write a formatter. So are you > willing to say that as a general transformation engine XSL is not really > useful and that it really is designed only to provide one part of a > page composition engine Maybe you are right. Maybe some day it would be possible to redesign FO and CSS so that : XSLT would be for transformations FO objects would handle page composition CSS objects would handle single page ( Definately, CSS objects have many common with FO objects, where FO is a superset of CSS. Actualy some kind of mapping FO's to some kind of CSS already inside FO implementations on the level of internal structures. ;-) Or something like that. Until such redesign: XSL already has XSL XSL already has FO XSL already has superset of CSS As a result - it is very powrful engine and when first FO implementation would appear, it'l be not easy for you to beat it with DOM / CSS ( especialy if you'l be asked to do something that deals with N-columns RTF document ;-) My 2c. Rgds.Paul. paul@pault.com www.pault.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu Jun 10 03:17:27 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:56 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <375EF568.CB9DC3FF@citec.fi> Message-ID: <000901beb2de$0b645080$1b19da18@ne.mediaone.net> The XSL WG is doing a terrific job of developing an excellent standard in a difficult problem domain. There is ample room in this world for ideas, languages and implementations. The concept that development of one idea stiffles development of competetive ideas is at best amusing. The world has too few ideas and too few languages for expressing these ideas not to many. In a good competitive environment, you pick the features your product will support. The 'marketplace' will either accept or reject your product based upon these features. I have a right to use and develop systems using XSL. You are arguing against my freedom to develop systems using the standard of my choice. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lucio.piccoli at one2one.co.uk Thu Jun 10 10:50:20 1999 From: lucio.piccoli at one2one.co.uk (LUCIO PICOLLI) Date: Mon Jun 7 17:12:56 2004 Subject: XML Transport Mechanism Message-ID: <3603e7c3.100599@smtpgate1.ONE2ONE.CO.UK> > > > > The XML data is placed into the body of the MIME > message which is an > > HTTP request and/or response. This allows XML to be > transmitted by SMTP as > > well. You can use a standard Content-Type: "text/xml" or > "application/xml > to > > indicate that the body is in XML format. > > I gather that what you are proposing is that the Java program listen > directly for the HTTP requests? Could this piggyback onto a web server > somehow? The easiest way i have found is to use a servlet. Creating a XML processing servlet is easy to implement as all the HTTP protocol is handled by the servlet engine. Of cause this is a Java only solution;-) -lp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 10 11:57:38 1999 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:12:56 2004 Subject: Specifying numbers as attribute values In-Reply-To: Mallikarjuna Sangappa's message of "Fri, 21 May 1999 12:54:14 -0700 (PDT)" References: <19990521195414.19283.rocketmail@attach1.rocketmail.com> Message-ID: MS> Mallikarjuna Sangappa 0> In article 0> <19990521195414.19283.rocketmail@attach1.rocketmail.com>, MS wrote: MS> MS> MS> MS> MS> It is not working in both the cases. Please throw MS> some light on this. Thank U. Members of an enumerated type must be NMTOKENs (production 59 in section 3.3.1). -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From steven.livingstone at scotent.co.uk Thu Jun 10 12:20:04 1999 From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM) Date: Mon Jun 7 17:12:56 2004 Subject: X-Schema Message-ID: <8DCB90532FF7D211B34400805FD48853140184@SENMAIL3> I've just started to work with Microsoft's Data Schema's instead of DTD's and it is so much easier and intuitive. I am thinking of moving exclusively to using schema. But, I know this is still in draft, so who is using it and what's likely to change - I imagine that this shall definitely overtake DTD's, but how soon ?? steven Join Association of Internet Professionals - http://www.citix.com/aip Steven Livingstone President, AIP Scotland. ceo@citix.com http://www.citix.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Thu Jun 10 12:30:12 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:12:56 2004 Subject: Specifying numbers as attribute values Message-ID: <01BEB33C.F923B870@grappa.ito.tu-darmstadt.de> Toby Speight wrote: > MS> Mallikarjuna Sangappa > > 0> In article > 0> <19990521195414.19283.rocketmail@attach1.rocketmail.com>, MS wrote: > > MS> > MS> > MS> > MS> > MS> It is not working in both the cases. Please throw > MS> some light on this. Thank U. > > Members of an enumerated type must be NMTOKENs (production 59 in > section 3.3.1). 1 and 2 are NMTOKENs; they are not Names. See productions [7] and [4]. -- Ron Bourret -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Jun 10 12:32:16 1999 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:12:56 2004 Subject: XHTML DTDs failing in IE5 In-Reply-To: Mark Birbeck's message of "Thu, 3 Jun 1999 18:34:36 +0100" References: Message-ID: Mark> Mark Birbeck 0> In article 0> , 0> Mark wrote: Mark> It's annoying because if I remove the DOCTYPE declaration to get Mark> past the parser, then I lose the ability to use ' ' and Mark> such-like. Does it help to override the relevant ATTLIST declarations earlier in the DTD (e.g. in the internal subset if you have the main DTD in the external one)? Or does IE dislike this also? -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mcheek at NetVendor.com Thu Jun 10 14:01:43 1999 From: mcheek at NetVendor.com (Mark Cheek) Date: Mon Jun 7 17:12:56 2004 Subject: q: as/400 idiot-proof xml conversion tool Message-ID: does anyone know if software exists for the as/400 platform that would make it easy for an as/400 database administrator to convert an xml document to a flat file before mapping that flat file into their database? we're looking for something that is a GUI or command line commercial product ready to work 'out of the box'. the issue is that we provide an xml document to our customers and they don't have the expertise to input that xml into their database - if there was a tool available for them (they are NOT tech-savvy), then they might be able to convert the xml into a flat file on the as/400 in the format that they need to do the database insert. also, it would be wonderful if this xml tool could also do the reverse and convert a flat file into an xml document for them to give us.... am I dreaming? thanks for your time, -mark cheek p/s - I've been all over www.xmlsoftware.com but cannot find a tool that fits this scenario.. most tools appear to be java or Perl modules that you drop in to your existing projects... ..Mark Cheek.. ''The two most important tools an architect has are the eraser in the drawing room and the sledge hammer on the construction site.'' - Frank Lloyd Wright xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bd at internet-etc.com Thu Jun 10 13:59:27 1999 From: bd at internet-etc.com (Brandt Dainow) Date: Mon Jun 7 17:12:56 2004 Subject: X-Schema In-Reply-To: <8DCB90532FF7D211B34400805FD48853140184@SENMAIL3> Message-ID: <000601beb338$72388600$de8ebc3e@p300> We use schemas instead of DTD's for all work around IE5 and Office2000, and are now tapping into the Office2000 schemas (though we'd like more info from Microsoft on these). We have it from Microsoft that they will follow the W3C as it defines schema standards. Currently these are still in early draft. In theory you can expect changes in the MS schema platform as W3C finalises, possibly as service releases, certainly in new products. However, this could create problems for people who have already developed schemas to Microsoft's spec - forcing Microsoft to support both schema standards. Another problem which could occur after standardisation if you're trying to develop W3C-compliant schemas on a Microsoft product using an older MSXML object which supports only MS Schemas. We have two ways around this - namespaces is the most obvious. Alternatively, a dirty trick is to call the W3C schema DTD's, which should impose the W3C schema onto the MSXML object (assuming it processes external DTD's after loading its own schema, not the other way around). Brandt Dainow bd@internet-etc.com Internet Etc Ltd http://www.internet-etc.com >-----Original Message----- >From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On >Behalf Of >Steven Livingstone, ITS, SENM >Sent: Thursday, June 10, 1999 11:16 AM >To: xml-dev@ic.ac.uk >Subject: X-Schema > > >I've just started to work with Microsoft's Data Schema's >instead of DTD's >and it is so much easier and intuitive. > >I am thinking of moving exclusively to using schema. > >But, I know this is still in draft, so who is using it and >what's likely to >change - I imagine that this shall definitely overtake DTD's, >but how soon >?? > >steven > >Join Association of Internet Professionals - http://www.citix.com/aip > >Steven Livingstone >President, AIP Scotland. >ceo@citix.com >http://www.citix.com > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jun 10 15:00:41 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:56 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <000901beb2de$0b645080$1b19da18@ne.mediaone.net> References: <375EF568.CB9DC3FF@citec.fi> Message-ID: <199906101302.JAA30157@hesketh.net> At 09:10 PM 6/9/99 -0400, Jonathan Borden wrote: >I have a right to use and develop systems using XSL. You are arguing against >my freedom to develop systems using the standard of my choice. Rights? Are you kidding? In standards you have no rights, except maybe the right to complain. You still have plenty of freedom to develop systems - it just may not be the 'standard' of your choice. Like it or not, if Tim Berners-Lee decides he doesn't like XSL (seems unlikely but possible to me), it won't become a W3C recommendation. Period. XSL will probably just move someplace else, but the 'standard' of your choice will have to come from another body. (And yes, I know the W3C isn't technically a 'standards' body in the IS0 sense.) W3C process may suck, but it hardly means that you have rights. This is almost as irritating as those people who go on about Microsoft's 'right to innovate'. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From steven.livingstone at scotent.co.uk Thu Jun 10 15:20:32 1999 From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM) Date: Mon Jun 7 17:12:56 2004 Subject: IE4 & XML Message-ID: <8DCB90532FF7D211B34400805FD48853140194@SENMAIL3> I read recently that MS are to make a realease for IE 4 which shall upgrade it's XML capabilities - to what level?? Direct Browing & XSL support?... Anybody know? steven Join Association of Internet Professionals - http://www.citix.com/aip Steven Livingstone President, AIP Scotland. ceo@citix.com http://www.citix.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ckaiman at i3solutions.com Thu Jun 10 15:44:39 1999 From: ckaiman at i3solutions.com (Charlie Kaiman) Date: Mon Jun 7 17:12:56 2004 Subject: X-Schema Message-ID: <01BEB326.09769C90.ckaiman@i3solutions.com> I received some good insight into this just yesterday: [Which you should use depends upon] when you need it and what you need it to do. If you need to reach the most parsers, and are willing to give up datatypes and namespace support, use DTDs. We are recommending that many of our clients use XML-Data Reduced, as documented at http://msdn.microsoft.com/xml/XMLGuide/schema-overview.asp because this gives you datatypes and namespace support, though this is currently supported only in shipping Microsoft and Datachannel parsers. If you can wait six months to a year, the W3C is working on a new schema language that may or may not be similar to XML-Data Reduced. Hope that helps you. Charlie Kaiman http://www.i3solutions.com/quote.asp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Jun 10 16:47:27 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:12:56 2004 Subject: X-Schema Message-ID: <002d01beb348$5e7cb180$11f96d8c@NT.JELLIFFE.COM.AU> From: Brandt Dainow >However, this could create problems for people who have already developed >schemas to Microsoft's spec - forcing Microsoft to support both schema >standards. Another problem which could occur after standardisation if >you're trying to develop W3C-compliant schemas on a Microsoft product using >an older MSXML object which supports only MS Schemas. We have two ways >around this - namespaces is the most obvious If I get this right, they are changing the namespace URI in order to use a different schema syntax. So they are not using namespaces as universal names, but as the names of a schema in a particular schema language, as I am saying. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mike at DataChannel.com Thu Jun 10 17:23:34 1999 From: mike at DataChannel.com (Mike Dierken) Date: Mon Jun 7 17:12:57 2004 Subject: Byte on XML-RPC Message-ID: <8EAE75D3D142D211A45200A0C99B6023B6E99F@ZEUS> Good overview, but he forgot to mention the WebBroker W3C Note: http://www.w3.org/TR/1998/NOTE-webbroker/ Many people do. Mike D DataChannel -----Original Message----- From: Dave Winer [mailto:dave@userland.com] Sent: Monday, June 07, 1999 6:53 AM To: xml-dev@ic.ac.uk; XML-L@LISTSERV.HEANET.IE; frontier-users@userland.com; userland-internal@userland.com; community@lists.scriptmeridian.org Subject: Byte on XML-RPC Gotta read this one! http://byte.com/features/1999/06/0607XML_RPC.html Success! Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mike at DataChannel.com Thu Jun 10 17:32:37 1999 From: mike at DataChannel.com (Mike Dierken) Date: Mon Jun 7 17:12:57 2004 Subject: XSL Challenge Message-ID: <8EAE75D3D142D211A45200A0C99B6023B6E9A5@ZEUS> This is conceptually a join operation. I've always felt that there should be a declarative syntax for doing this. The IE5 and DataChannel XSL processors have a method called 'context()' which is meant to help with this situation. Take a look at: http://msdn.microsoft.com/xml/reference/xsl/ChangingContext_context.asp for documentation of the IE5 context() method. Mike DataChannel xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mike at DataChannel.com Thu Jun 10 17:34:27 1999 From: mike at DataChannel.com (Mike Dierken) Date: Mon Jun 7 17:12:57 2004 Subject: XML Transport Mechanism Message-ID: <8EAE75D3D142D211A45200A0C99B6023B6E9A6@ZEUS> There is also some more background info in this W3C Note: http://www.w3.org/TR/1998/NOTE-webbroker/ Mike DataChannel -----Original Message----- From: David Brownell [mailto:david-b@pacbell.net] Sent: Wednesday, June 09, 1999 10:30 AM To: Carl Schei Cc: xml-dev@ic.ac.uk Subject: Re: XML Transport Mechanism Carl Schei wrote: > > I gather that what you are proposing is that the Java program listen > directly for the HTTP requests? Could this piggyback onto a web server > somehow? Certainly. See the rpc/transport example in Sun's package, at http://developer.java.sun.com/developer/products/xml (it's now an updated release, TR2). That has both a client and a servlet component. Servlets plug into web servers; that could be Apache, or any other servet that talks servlets. The application can define whatever standard it chooses for how the data is exchanged. If XML is already in use it's easy to just exchange documents. If not, it may be desirable to use some predefined least-common-denominator DTD like "XML-RPC" does. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From asmith at drumbeat.com Thu Jun 10 18:25:52 1999 From: asmith at drumbeat.com (Smith, Adrian) Date: Mon Jun 7 17:12:57 2004 Subject: General Architecture Message-ID: I am not sure if this is the place to ask but I am looking for a diagram or set of diagrams that show the architecture of the collaboration and actors involved in serving up a web page to a browser. If any knows of a set of the diagrams I would like to see them. Thanks! Adrian xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mcheek at NetVendor.com Thu Jun 10 20:34:08 1999 From: mcheek at NetVendor.com (Mark Cheek) Date: Mon Jun 7 17:12:57 2004 Subject: xml/edi Message-ID: Just how close are 'they' to forming an XML standard that can be used in place of, or conjunction with EDI? and who are 'they'? the x12 group? my employer writes b2b eCommerce apps that are dropped into existing EDI and non-EDI infrastructures... it would be nice to offer low-cost XML alternatives... that are EDI/OBI compliant. thanks for your time, -mark ..Mark Cheek.. "I count him braver who overcomes his desires than him who conquers his enemies; for the hardest victory is over self." -- Aristotle _____________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu Jun 10 21:12:18 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:57 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach Message-ID: <027c01beb374$3c324be0$0b2e249b@fileroom.Synapse> Simon St.Laurent wrote: >At 09:10 PM 6/9/99 -0400, Jonathan Borden wrote: >>I have a right to use and develop systems using XSL. You are arguing against >>my freedom to develop systems using the standard of my choice. > >Rights? Are you kidding? In standards you have no rights, except maybe >the right to complain. You still have plenty of freedom to develop systems >- it just may not be the 'standard' of your choice. > >Like it or not, if Tim Berners-Lee decides he doesn't like XSL (seems >unlikely but possible to me), it won't become a W3C recommendation. >Period. XSL will probably just move someplace else, but the 'standard' of >your choice will have to come from another body. (And yes, I know the W3C >isn't technically a 'standards' body in the IS0 sense.) > >W3C process may suck, but it hardly means that you have rights. > James Clark gave me the right to use his implementation of XSL, IBM gave me the right to use its implementation of XSL, Microsoft gave me the right to use its implementation of XSL. (no intention to leave out other implementations, but this makes the point :-) From msabin at cromwellmedia.co.uk Thu Jun 10 21:21:49 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:57 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach Message-ID: Jonathan Borden wrote, > James Clark gave me the right to use his > implementation of XSL, IBM gave me the right to use > its implementation of XSL, Microsoft gave me the right > to use its implementation of XSL. (no intention to > leave out other implementations, but this makes the > point :-) Huh? In what way does criticism of XSL deprive you of those rights you've just listed? Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Jun 10 21:23:23 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:57 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <027c01beb374$3c324be0$0b2e249b@fileroom.Synapse> Message-ID: <199906101925.PAA15715@hesketh.net> At 03:05 PM 6/10/99 -0400, Jonathan Borden wrote: > James Clark gave me the right to use his implementation of XSL, IBM gave >me the right to use its implementation of XSL, Microsoft gave me the right >to use its implementation of XSL. (no intention to leave out other >implementations, but this makes the point :-) They gave you licenses to use their software, sure. They didn't give you the right to use a _standard_, however. Subtle but important. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jun 10 22:58:31 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:57 2004 Subject: SAX2: Namespaces and syntax of compound names Message-ID: <14176.9816.632368.748497@localhost.localdomain> I have just heard a good argument for using the "{URIpart}localpart" syntax for compound names rather than the "URIpart localpart" I have always preferred the second format because it is easier to split (most libraries have a built-in function for splitting around a single character), but someone pointed out that the first format has the advantage that you can tell simply by testing the first character whether or not you have a compound name. Of course, Java will still be happier with the second, since String operations in Java are painfully expensive. What does everyone else think? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hoxford at dtai.com Thu Jun 10 23:48:59 1999 From: hoxford at dtai.com (Hank Oxford) Date: Mon Jun 7 17:12:57 2004 Subject: XML Schema errata (and digest question) Message-ID: <37603321.807FD94D@dtai.com> Anyone put together errata for the W3C XML Schema draft's Schema schema or schema DTD? (Is that confusing enough?) I'm trying to cobble together something that can work with it and have found one small discrepancy so far. The schema schema says: The DTD says: If I'm reading the Schema schema right, well, it's wrong. It wouldn't allow mixed bounds in the form of, say, a minInclusive and a maxExclusive. The DTD says you may or may not have either a minInclusive or minExclusive (but not both) and may or may not have either a maxInclusive or maxExclusive (but not both). I believe the DTD is correct. Am I missing something? Should the Schema schema be something like this: And speaking of tools for the Schema draft, anyone know of any? Any on the horizon? I know it's early and still in flux, but some of us need that functionality now... or yesterday would be even better. :) Also, anyone know what's going on with the xml-dev-digest? I prefer the digest to the individual mailings, but the digest seems to have stopped. -- Hank Oxford DTAI, Incorporated hoxford@dtai.com 3900 Harney St Suite 210 1-619-542-7243 San Diego, CA 92110 1-888-222-3824 x243 http://www.dtai.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Fri Jun 11 00:47:43 1999 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:12:57 2004 Subject: question for a friend Message-ID: <376046C6.646E1390@finetuning.com> Hello, A friend of mine asked me a question I didn't feel like I gave him a good enough answer for, so I bring it to you... say we have a part of a document below (probably a part of a very long document). Yes i KNOW this is misnested. this is the point. he was saying that this kind of context couldn't be represented using a well-formed structure: FFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFFFFFFFFFFF where the two paragraphs in the middle are "realestate:newyork", but only if they are taken together. No matter how I represented the structure above in a well-formed manner, I couldn't quite pull off the "only when taken together" part. Any suggestions? thanks, lisa 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From daniela at cnet.com Fri Jun 11 01:05:01 1999 From: daniela at cnet.com (Daniel Austin) Date: Mon Jun 7 17:12:57 2004 Subject: question for a friend Message-ID: <77A952A6B467D211855D00805F9521F13A6A77@cnet10.cnet.com> Lisa, This sort of structure cannot be represented easily in XML, since it cannot be mapped to a simple heirarchichal tree structure. In practice, what usually happens is that a third element is used to contain the internal paragraphs and additional information beyond the DTD is required for complete validity testing/processing. But your friend is correct in the sense that there are (many) data structures that cannot be mapped to XML; XML really applies only to semi-structured data sets where relationships between elements are restricted to parent-child relationships - a heirarchical tree. Additional, more complex relationships among elements must be specified outside of XML. Regards, D- ********************************************************************* Daniel Austin, Director of Research and Development, CNET daniela@cnet.com 415-395-7800 x1438 "To change the old into the new, and the shapes of things to come..." > -----Original Message----- > From: Lisa Rein [mailto:lisarein@finetuning.com] > Sent: Thursday, June 10, 1999 4:14 PM > To: xml-dev@ic.ac.uk > Subject: question for a friend > > > Hello, > > A friend of mine asked me a question I didn't feel like I gave him a > good enough answer for, so I bring it to you... > > > say we have a part of a document below (probably a part of a very long > document). Yes i KNOW this is misnested. this is the point. he was > saying that this kind of context couldn't be represented using a > well-formed structure: > > > FFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFF > > FFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFF > > FFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFF > > > FFFFFFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFF > FFFFFFFFFFFFFFFFFFFFFFFFF > > > where the two paragraphs in the middle are "realestate:newyork", but > only if they are taken together. > > > No matter how I represented the structure above in a > well-formed manner, > I couldn't quite pull off the "only when taken together" part. > > Any suggestions? > > thanks, > > lisa > > 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Fri Jun 11 01:18:55 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:12:57 2004 Subject: XML Schema errata (and digest question) Message-ID: <84285D7CF8E9D2119B1100805FD40F9F255366@MDYNYCMSX1> Anyone put together errata for the W3C XML Schema draft's Schema >schema or schema DTD? (Is that confusing enough?) The www-xml-schema-comments@w3.org address described in the Note's "Status of this Document" part is the best place to send errata. Previously submitted comments are available at http://lists.w3.org/Archives/Public/www-xml-schema-comments/. Bob DuCharme www.snee.com/bob "The elements be kind to thee, and make thy spirits all of comfort!" Anthony and Cleopatra, III ii xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jun 11 02:35:43 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:57 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: Message-ID: <000701beb3a1$5f24daf0$1b19da18@ne.mediaone.net> Miles Sabin wrote: > > Jonathan Borden wrote, > > James Clark gave me the right to use his > > implementation of XSL, IBM gave me the right to use > > its implementation of XSL, Microsoft gave me the right > > to use its implementation of XSL. (no intention to > > leave out other implementations, but this makes the > > point :-) > > Huh? > > In what way does criticism of XSL deprive you of those > rights you've just listed? > I never said it did. The above paragraph was used to defend my prior statement that I have a right to use XSL if I choose. What I wish, is to use XSL as a standard, and further, to define a common platform for web native distributed computing (this specifically goes beyond a desire to browse documents). To be practical about this we need to things to occur: 1) standards to be defined (e.g. role of W3C,IETF,ISO etc.) 2) standards to be adopted. To suggest, as Leventhal does, that work on XSL be suspended until 'major' browser vendors have completed implementation of CSS2, is a suggestion that fits his personal agenda, and the agenda of a subset of individuals and corporations which are engaged in document browsing. I have nothing against CSS, to the contrary I use it every day, however it alone does not help me with distributed computing tasks that I use XSL for, even in its current pre-standard implementation. CSS is not in competition with XSL in regards to WNDC, to the contrary, a reasonable argument would be that DSSSL is already an ISO standard which can handle many of the tasks that XSL is being designed to handle. This argument unfortunately is lost in the current static regarding XSL vs. CSS, and though DSSSL does meet requirement (1) above, it has not met requirement (2) for whatever reasons. My agenda is to speak loudly and hopefully clearly about the need for browsers to support client side XSLT in order to enable browsers to be used for web native distributed computing systems. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Arved_37 at chebucto.ns.ca Fri Jun 11 04:09:04 1999 From: Arved_37 at chebucto.ns.ca (Arved Sandstrom) Date: Mon Jun 7 17:12:57 2004 Subject: Mailing List for Perl XML Indexing Project Message-ID: Hi, all I've been remiss in not posting this. Some weeks back Sami Poikonen was kind enough to set up a mailing list for the Perl+C XML indexing project I proposed in various forums. The address of the ML is perl-xml-index@majordomo.jyu.fi Subscribe by sending a message subscribe perl-xml-index to majordomo@majordomo.jyu.fi There has already been some exploratory work done by myself and Wade Stebbings, and others have expressed interest, but I believe that this mailing list will make all the difference in getting this project moving. We have some interesting ideas, and welcome anyone with input or interest regarding the indexing of XML document collections. I will be posting a working description of what we're about on the list at the end of the weekend, and again every few weeks. Thanks for your interest and attention, Arved Sandstrom xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Fri Jun 11 09:28:01 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:12:57 2004 Subject: XML Schema errata (and digest question) Message-ID: <01BEB3EC.AD003BC0@grappa.ito.tu-darmstadt.de> Hank Oxford wrote: > Anyone put together errata for the W3C XML Schema draft's Schema schema > or schema DTD? (Is that confusing enough?) I'm trying to cobble > together something that can work with it and have found one small > discrepancy so far. > > The schema schema says: > > > > > > > > > > > > > > The DTD says: > (maxInclusive | maxExclusive)?)"> > > If I'm reading the Schema schema right, well, it's wrong. It wouldn't > allow mixed bounds in the form of, say, a minInclusive and a > maxExclusive. > > The DTD says you may or may not have either a minInclusive or > minExclusive (but not both) and may or may not have either a > maxInclusive or maxExclusive (but not both). I believe the DTD is > correct. [correct schema snipped] You are correct, as is your suggested syntax (except for the commas between attributes and that you have mislabeled a closing choice as a closing sequence). I also noted two other problems: i) In the schema definition of the attribute group "occurrence", the default for maxOccur is 1. This doesn't work, as it means there is no way for maxOccur to be infinity -- the DTD is correct here as well. ii) In the schema for data types (appendix A of part 2), maxOccur of "*" is used. This is illegal because "*" is not an integer. (It looks like the WG played around with different strategies on how to model infinity and didn't catch everything after settling on the current strategy.) -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dirkg at tectrade.be Fri Jun 11 10:06:25 1999 From: dirkg at tectrade.be (Dirk Germonpre) Date: Mon Jun 7 17:12:57 2004 Subject: tools to generate DTD from a relational database schema Message-ID: <3.0.6.32.19990611100550.0094fc70@relay.tectrade.be> Hello, Does anyone know of tools to generate a DTD from a relational database schema? Thanks in advance. ---------------------------------- Dirk Germonpr? - dirkg@tectrade.be Tectrade NV Pieter de Conincklaan 33 B-8200 Brugge Belgium xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From heikki at citec.fi Fri Jun 11 10:16:01 1999 From: heikki at citec.fi (Heikki Toivonen) Date: Mon Jun 7 17:12:57 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <000701beb3a1$5f24daf0$1b19da18@ne.mediaone.net> Message-ID: <000101beb3e2$afab1c00$2500a8c0@hto.citec.fi> Jonathan Borden wrote: > Miles Sabin wrote: > > In what way does criticism of XSL deprive you of those > > rights you've just listed? > > I never said it did. The above paragraph was used to defend my prior > statement that I have a right to use XSL if I choose. What I > wish, is to use > XSL as a standard, and further, to define a common platform for web XSL is not a standard, at least not yet. It might actually never become a standard. Until there is a standard you can not claim you are using one. > To suggest, as Leventhal does, that work on XSL be > suspended until 'major' > browser vendors have completed implementation of CSS2, is a Actually, suspension was more like my view. Perhaps you should read Michael's last mail again to see his view. -- Heikki Toivonen http://www.doczilla.com http://www.citec.fi xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From didier at cln46ae.der.edf.fr Fri Jun 11 10:53:40 1999 From: didier at cln46ae.der.edf.fr (Didier BOLF) Date: Mon Jun 7 17:12:58 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach Message-ID: <199906110853.KAA19246@cln46ms.der.edf.fr> > XSL is not a standard, at least not yet. It might actually never become a > standard. Until there is a standard you can not claim you are using one. I really hope that XSL is about to become a standard. We already use XSLT (WD 04/21/1999) in an EDI application at EDF. From my point of view, the last WD is mature and ready to be promoted as a recommendation. Thanks to James Clark to do such a *GREAT* work with XSLT and XT. Best regards. Didier Bolf. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RKarthik at CHN.CTS-CORP.COM Fri Jun 11 10:57:58 1999 From: RKarthik at CHN.CTS-CORP.COM (Raghavendra, Karthik (CTS)) Date: Mon Jun 7 17:12:58 2004 Subject: Data Islands and applets Message-ID: <15BC1866E5CFD111900E00A0C9A6F35E013E47DE@CTSINCSISXUC> Hi, I have an applet that loads a XML file and displays the contents as a table. Is it possible to use data islands instead ? I want to have the data island and the applet in the same html page and make the applet access the XML data in the data island. The reason for doing this is to give the user the option to save the data island for reuse elsewhere. This is similar to the way in which Office 2000 products save data in XML format. Thanks in advance. Karthik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990611/867be994/attachment.htm From Michael.Kay at icl.com Fri Jun 11 12:20:51 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:12:58 2004 Subject: question for a friend Message-ID: <93CB64052F94D211BC5D0010A800133170EEE7@wwmess3.bra01.icl.co.uk> Lisa Rein: > say we have a part of a document below (probably a part of a very long > document). Yes i KNOW this is misnested. this is the point. he was > saying that this kind of context couldn't be represented using a > well-formed structure: [snip] I don't really understand the semantics of your example. But yes, there are situations where you want to impose multiple hierarchic structures over the same linear data. An obvious one is logical structure vs layout structure (e.g. sections and pages) another is logical structure vs change history and authorship. I'm only aware of two answers: 1. Represent one of the hierarchies using empty tags, e.g. . 2. Split the units of one of the heirarchies to achieve proper nesting: OTHELLO Most potent, grave, and reverend signiors, My very noble and approved good masters, That I have ta'en away this old man's daughter, It is most true; true, I have married her: The very head and front of my offending Hath this extent, no more. Rude am I in my speech, And little bless'd with the soft phrase of peace: For since these arms of mine had seven years' pith, Till now some nine moons wasted, they have used Their dearest action in the tented field, And little of this great world can I speak, More than pertains to feats of broil and battle, And therefore little shall I grace my cause In speaking for myself. Yet, by your gracious patience, I will a round unvarnish'd tale deliver Of my whole course of love; what drugs, what charms, What conjuration and what mighty magic, For such proceeding I am charged withal, I won his daughter. BRABANTIO A maiden never bold; Of spirit so still and quiet, that her motion Blush'd at herself; and she, in spite of nature, Of years, of country, credit, every thing, To fall in love with what she fear'd to look on! It is a judgment maim'd and most imperfect That will confess perfection so could err Against all rules of nature, and must be driven To find out practises of cunning hell, Why this should be. I therefore vouch again That with some mixtures powerful o'er the blood, Or with some dram conjured to this effect, He wrought upon her. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Fri Jun 11 13:02:19 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:58 2004 Subject: SAX2: Namespaces and syntax of compound names Message-ID: David Megginson wrote, > Of course, Java will still be happier with the second, > since String operations in Java are painfully > expensive. What does everyone else think? I don't think '{URIpart}localpart' will be significantly more expensive to split in Java than 'URIpart localpart' on some reasonable assumptions about what's typical (nested braces in URIpart relatively rare; localpart short relative to URIpart etc.) Maybe we need to see the splitting code for the two cases? Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at isogen.com Fri Jun 11 13:32:01 1999 From: robin at isogen.com (Robin Cover) Date: Mon Jun 7 17:12:58 2004 Subject: question for a friend In-Reply-To: <376046C6.646E1390@finetuning.com> Message-ID: On Thu, 10 Jun 1999, Lisa Rein wrote: > document). Yes i KNOW this is misnested. this is the point. he was > saying that this kind of context couldn't be represented using a [...] > No matter how I represented the structure above in a well-formed manner, > I couldn't quite pull off the "only when taken together" part. > > Any suggestions? The question is not entirely clear to me, but if you're looking for markup strategies used to represent non-hierarchical structures (or structures with multiple overlapping hierarchies predicated upon multiple analytical perspectives) you may want to look at hints in: http://www.oasis-open.org/cover/topics.html#hierarchy "SGML/XML and (Non-) Hierarchy" The TEI teams in particular have dealt with this problem, since the encoding of text for literary and linguistic features often forces one to reckon with four or five "concurrent" hierarchies -- and SGML/XML (sans CONCUR) forces you to choose. The dogma of SGML changed somewhere along the line from a simplistic OHCO model ("ordered hierarchy of content objects") to something like "non-hierarchy / multiple-hierarchy is the rule rather than the exception". Cheers, Robin Cover xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jun 11 14:28:27 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:58 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach Message-ID: <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> Heikki Toivonen wrote: >Jonathan Borden wrote: > >> To suggest, as Leventhal does, that work on XSL be >> suspended until 'major' >> browser vendors have completed implementation of CSS2, is a > >Actually, suspension was more like my view. Perhaps you should read >Michael's last mail again to see his view. > The more I read, the more pathetic the argument against XSL sounds. Let me quote from Leventhal's last e-mail: >But it was not actually when I read Ken's article that the "war" began, >it was >a bit earlier when I read Tim Bray and Jon Bosak's article in Scientific >American where it was stated that XSL was "the" stylesheet language for >XML. >In demographic terms Scientific American readers are one of the most >influential publication-defined communities on the planet. It was >then that I said "This is war, it has to be a war." Please, have some respect. The Scientific American article is an accomplishment. They wrote it, Leventhal didn't. This just sounds like sour grapes. and further: >And on these points alone it is clear that the correct action for W3C members > remains, clearly, to vote against an XSL Recommendation. Noted and filed. Whine all you want about XSL and its so called failings. I for one am using XSL even in its early implementation to do real work. The people who use my application will need a browser which supports client side XSL+DOM+ECMAScript. This can be accomplished via Java,COM,XPCOM etc. I suspect that IE5 and Mozilla will be able to handle this. If your company's browser isn't up to the task, then so be it, but in this context, this whining about XSL and pleading for people to stop using it (and for the W3C not to support it ) sounds alot like a vendor with an agenda. If my comments are inflamatory I apologize. They are in reaction to a done discussion that I have been hoping will just go away. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jun 11 15:23:35 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:58 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> Message-ID: <199906111325.JAA21943@hesketh.net> At 08:13 AM 6/11/99 -0400, Jonathan Borden wrote: >Please, have some respect. The Scientific American article is an >accomplishment. They wrote it, Leventhal didn't. This just sounds like sour >grapes. Actually, I brought this up when the article first appeared. Tim Bray acknowledged that this was a significant omission. (http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Apr-1999/0347.html) I think the sour grapes come from having to put up with a group that launched off in its own direction without much regard for prior work _on the Web_ and that keeps insisting that it is _the_ solution for XML formatting. Listening to the opening XTech keynote in March was a particularly painful moment in this regard, but it's a theme that goes on and on. This "CSS and XSL don't compete" stuff is a load of condescending garbage that should have been disposed of long ago. > Noted and filed. Whine all you want about XSL and its so called >failings. I for one am using XSL even in its early implementation to do real >work. The people who use my application will need a browser which supports >client side XSL+DOM+ECMAScript. This can be accomplished via Java,COM,XPCOM >etc. I suspect that IE5 and Mozilla will be able to handle this. If your >company's browser isn't up to the task, then so be it, but in this context, >this whining about XSL and pleading for people to stop using it (and for the >W3C not to support it ) sounds alot like a vendor with an agenda. I think you've come to the conclusion that anyone who disagrees with you is whining. From the other side, I've come to the conclusion that you're whining. I write books. The existence of standards makes those books worth writing, but it makes very little difference (financially, at least) whether those books cover CSS or XSL. I have no vendor agenda. Still, I think Michael Leventhal is making some very important points. I would genuinely like the W3C to sit down and ask if XSL is _good for the Web_. Not good for the XSL community, not good for the DSSSL community, but whether it is good for _the Web_. That is, after all, their job. If, after some serious, preferably public, pondering, they conclude that it's good for the Web, then fine. XSL can become a recommendation. If they decide that it's not good for the Web, they'd better drop it. XSL can move on to a different organization if necessary - I don't see it dying any time soon. > If my comments are inflamatory I apologize. They are in reaction to a >done discussion that I have been hoping will just go away. If you keep inflaming it, it'll keep going, not go away. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Fri Jun 11 16:19:28 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:12:58 2004 Subject: Namespaces are dead. Message-ID: <002d01beb40d$88c1cf50$29f96d8c@NT.JELLIFFE.COM.AU> From: Marc.McDonald@Design-Intelligence.com >To put it plainly, the basic problem is putting document consumer >information in the document. Doing so results in needing to modify every >document every time a new consumer is created. I have written to the W3C a suggestion on this topic. It is in an article "How to Promote Organic Plurality on the WWW" at http://www.ascc.net/xml/en/utf-8/monolith.html The concrete suggestions are these: 1) To prevent "data kidnap", every new technology or application class introduced onto the WWW must be preceded by a mechanism, as an intermediate layer, to allow alternatives to that technology 2) To prevent "workflow kidnap", that mechanism should have a phase attribute. 3) To prevent "data lockout", names should be fixed for a schema: vocabularies that require a schema with to check names based on regular expressions should be deprecated. I hope anyone interested in building an open WWW that provides a level-playing field for innovators can support it. Rick Jelliffe P.S. "Organic Plurarity" sounds like something from Barbarella I know, but it is the best I could come up 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 11 16:16:43 1999 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:12:58 2004 Subject: question for a friend In-Reply-To: Kay Michael's message of Fri, 11 Jun 1999 11:09:55 +0100 Message-ID: <199906111418.PAA11191@stevenson.cogsci.ed.ac.uk> > But yes, there are > situations where you want to impose multiple hierarchic structures over the > same linear data. An obvious one is logical structure vs layout structure > (e.g. sections and pages) another is logical structure vs change history and > authorship. > I'm only aware of two answers: Another solution, for some purposes, is to have two documents, one for each hierarchy. Of course, you don't want to to duplicate the data itself. We avoid this by using "standoff markup", which we implement with XLinks (we have our own software to perform the transclusion process). The context we use this in is markup of linguistic corpora, and we often have an ID on every word. For the Shakespeare example it might be something like this: fragment of base file (othello.xml): charged withal , I won his daughter . A maiden never bold ; Of spirit fragment of speech file: Message-ID: <005001beb41b$db64b700$f5f6b5cf@evans.dnai.com> (NOTE: this is not an attack on anybody!!! ) One way of looking at is that if one waited for 'standards' bodies and major vendors to agree on things, java would still be a cup of coffee, and the WEB would be what a spider captures prey on. (up to you to decide if this would be good or bad :-) I suspect that I use XSL for the same reasons that the early adopters of Java had. I know it is a bit rough, I know it is not really a standard, but it does what I want it to do, in a way that I have decided makes my job easier. It's support from MS and IBM comforts me. I believe in its future. I do not believe that it is a 'provable' good thing. I would like to see it uniformly in browsers, but have architected my product so that it does not have to be. I have never looked to standard's bodies to make my choices. I suspect that I am not alone... erik -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Simon St.Laurent Sent: Friday, June 11, 1999 6:29 AM To: 'XML Developers' List' Subject: Re: XSL Debate, Leventhal responds to Stephen Deach At 08:13 AM 6/11/99 -0400, Jonathan Borden wrote: >Please, have some respect. The Scientific American article is an >accomplishment. They wrote it, Leventhal didn't. This just sounds like sour >grapes. Actually, I brought this up when the article first appeared. Tim Bray acknowledged that this was a significant omission. (http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Apr-1999/0347.html) I think the sour grapes come from having to put up with a group that launched off in its own direction without much regard for prior work _on the Web_ and that keeps insisting that it is _the_ solution for XML formatting. Listening to the opening XTech keynote in March was a particularly painful moment in this regard, but it's a theme that goes on and on. This "CSS and XSL don't compete" stuff is a load of condescending garbage that should have been disposed of long ago. > Noted and filed. Whine all you want about XSL and its so called >failings. I for one am using XSL even in its early implementation to do real >work. The people who use my application will need a browser which supports >client side XSL+DOM+ECMAScript. This can be accomplished via Java,COM,XPCOM >etc. I suspect that IE5 and Mozilla will be able to handle this. If your >company's browser isn't up to the task, then so be it, but in this context, >this whining about XSL and pleading for people to stop using it (and for the >W3C not to support it ) sounds alot like a vendor with an agenda. I think you've come to the conclusion that anyone who disagrees with you is whining. From the other side, I've come to the conclusion that you're whining. I write books. The existence of standards makes those books worth writing, but it makes very little difference (financially, at least) whether those books cover CSS or XSL. I have no vendor agenda. Still, I think Michael Leventhal is making some very important points. I would genuinely like the W3C to sit down and ask if XSL is _good for the Web_. Not good for the XSL community, not good for the DSSSL community, but whether it is good for _the Web_. That is, after all, their job. If, after some serious, preferably public, pondering, they conclude that it's good for the Web, then fine. XSL can become a recommendation. If they decide that it's not good for the Web, they'd better drop it. XSL can move on to a different organization if necessary - I don't see it dying any time soon. > If my comments are inflamatory I apologize. They are in reaction to a >done discussion that I have been hoping will just go away. If you keep inflaming it, it'll keep going, not go away. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 11 17:11:24 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:58 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: References: <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> Message-ID: <199906111513.LAA27001@hesketh.net> At 10:48 AM 6/11/99 -0400, Ann Navarro wrote: >At 09:29 AM 6/11/99 -0400, Simon St.Laurent wrote: >>I would genuinely like the W3C to sit down and ask if XSL is _good for the >>Web_. Not good for the XSL community, not good for the DSSSL community, >>but whether it is good for _the Web_. > >That's the wrong question. It's "is XSL good for *XML*". XML right now >isn't the Web. The Web is moving in that direction, and will certainly be >embracing XML, but there's no real "there" there yet. I'm afraid it is the right question, unless the World Wide Web Consortium has changed their mission statement substantially. The current process document (http://www.w3.org/Consortium/Process/) makes it rather clear the W3C is about the Web. "W3C's mission is to lead the evolution of the Web -- the universe of information accessible through networked computers. " That certainly doesn't limit it to the 'public Web', but it does say Web loud and clear. In any case, it's all going to come back to one lucky individual - Tim Berners-Lee - and there isn't much the rest of us can do about it except hope that he listens. >There is certainly overlap between CSS and XSL, and I don't think anyone's >attempted to say there's not -- but they're not mirror duplicates either, >and both have their place in the large world of internet-based documents. Both may have their place. Still, it seems like it would have been a good idea for the W3C to sit both groups down at the same table and make them work together, rather than pretending they don't compete. (Common vocabulary would have been a good start. XSL FOs are finally moving toward CSS, after wasting a lot of time elsewhere.) Making them work together would have spared us a lot of the conflict we've had and possibly let us get on with more real work. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Fri Jun 11 17:22:30 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:12:58 2004 Subject: SAX2: Namespaces and syntax of compound names References: <14176.9816.632368.748497@localhost.localdomain> Message-ID: <37612A46.62E8F732@mecomnet.de> i would actually prefer to have the option requesting that names be parsed to interned symbols. symbols without uri are simply in a package either without a name, or with a constant default name. this mechanism also offers numerous advantages. for example, giving the package more than one name, or constructing and using packages programmatically while delaying binding to the uri. a consequence of which is that it would be trivial to shifting the uri systematically for compiled applications... David Megginson wrote: > > I have just heard a good argument for using the > > "{URIpart}localpart" > > syntax for compound names rather than the > > "URIpart localpart" > > ... What does everyone else think? > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Jun 11 17:50:30 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:12:58 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <199906111513.LAA27001@hesketh.net> References: <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> Message-ID: At 11:14 AM 6/11/99 -0400, Simon St.Laurent wrote: >In any case, it's all going to come back to one lucky individual - Tim >Berners-Lee - and there isn't much the rest of us can do about it except >hope that he listens. Simon, you usually don't resort to hyperbole :) TBL may be the director of the Consortium, but the membership votes on what will or won't be made into a Recommendation. If the membership gives it a resounding "YES!" the director, Tim or anyone else who may hold that spot later, isn't just going to play despot and say "NO!". 300+ individuals (representing their member organizations) make the choice -- the director just puts the final stamp on it, or when there is controversy and dissent within the membership, makes a determination of appropriate action, which the members also voice. The vote isn't just "yes" or "no" -- it's "yes, as is" "yes, with these minor corrections" "no - go back for more work on this area" and "we think this is bad and we shouldn't be working on it any more". W3C groups do indeed "sit down" together through several coordination groups. CSS and XSL groups aren't operating in a vacuum. Now all this reminds me to go vote on a pending issue right now... Ann --- Author of Effective Web Design: Master the Essentials Buy it Online - http://www.webgeek.com/about.html Coming this summer! --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 11 18:01:09 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:58 2004 Subject: W3C (was Re: XSL Debate, Leventhal responds to Stephen Deach) In-Reply-To: <199906111552.LAA28839@hesketh.net> References: <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> Message-ID: <199906111603.MAA29611@hesketh.net> At 11:51 AM 6/11/99 -0400, you wrote: >At 11:14 AM 6/11/99 -0400, Simon St.Laurent wrote: >>In any case, it's all going to come back to one lucky individual - Tim >>Berners-Lee - and there isn't much the rest of us can do about it except >>hope that he listens. > >Simon, you usually don't resort to hyperbole :) If only it weren't such fun... >TBL may be the director of the Consortium, but the membership votes on what >will or won't be made into a Recommendation. If the membership gives it a >resounding "YES!" the director, Tim or anyone else who may hold that spot >later, isn't just going to play despot and say "NO!". Yes, but in the end, it's up to Tim. Legal reasons, I understand, as he's pretty well judgment-proof. I also understand that he takes the job pretty seriously. Given the fairly dim view I have of W3C membership rules and process, Tim's idealism (at least in public) is one of the few bright spots that gives me reason to pay attention to a vendor consortium. I disagree with plenty of W3C decisions, and it may well all be Tim's fault, but it's good to know that somebody out there - with power - actually seems to care about the semantic web for reasons that have to do with more than stock valuations. Otherwise, I'll stick to the IETF and informal (ala SAX2) efforts, thanks. They ain't perfect either, but they're a lot more open about participation. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Jun 11 18:05:42 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:12:59 2004 Subject: W3C (was Re: XSL Debate, Leventhal responds to Stephen Deach) In-Reply-To: <199906111603.MAA29611@hesketh.net> References: <199906111552.LAA28839@hesketh.net> <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> Message-ID: At 12:06 PM 6/11/99 -0400, Simon St.Laurent wrote: > is one of the few bright spots that gives me >reason to pay attention to a vendor consortium. Making me feel like an evangelist this morning ;) There are many many W3C members besides the major "web" vendors, HWG is but one of them. There's a growing balance in the group, which has been fun to see happen (I've been involved directly at the AC level since January 98) Ann --- Author of Effective Web Design: Master the Essentials Buy it Online - http://www.webgeek.com/about.html Coming this summer! --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 11 18:05:53 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:59 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <199906111552.LAA28839@hesketh.net> References: <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> Message-ID: <199906111608.MAA29936@hesketh.net> At 11:51 AM 6/11/99 -0400, Ann Navarro wrote: >W3C groups do indeed "sit down" together through several coordination >groups. CSS and XSL groups aren't operating in a vacuum. All I can say on this one is that it sure hasn't felt like it from the outside. At times, the public comments of W3C staff (plus former W3C folk) and WG members on both sides have felt pretty much like open warfare, and coordination on vocabulary feels like an afterthought, nothing more. If this is coordination, I'd hate to see chaos... Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jun 11 18:12:08 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:59 2004 Subject: W3C (was Re: XSL Debate, Leventhal responds to Stephen Deach) In-Reply-To: <199906111608.MAA29932@hesketh.net> References: <199906111603.MAA29611@hesketh.net> <199906111552.LAA28839@hesketh.net> <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> Message-ID: <199906111614.MAA30348@hesketh.net> At 12:07 PM 6/11/99 -0400, Ann Navarro wrote: >At 12:06 PM 6/11/99 -0400, Simon St.Laurent wrote: > >> is one of the few bright spots that gives me >>reason to pay attention to a vendor consortium. > >Making me feel like an evangelist this morning ;) > >There are many many W3C members besides the major "web" vendors, HWG is but >one of them. There's a growing balance in the group, which has been fun to >see happen (I've been involved directly at the AC level since January 98) I'm glad to hear that there are more 'customers' joining. I remain disgusted with the pay for play mode of operation, however. Inviting technical experts is good, but the W3C is still a closed operation to most of the world. No, I'm not asking to be made an expert, and no, I'm not interested in joining a W3C member organization to get access. I'm hoping that someday the W3C will find an endowment or some other means of supporting itself so it can drop this $5000+/year charade that keeps the smoke-filled rooms closed to small firms and individuals. I'll remain an outsider until the W3C gets rid of the rules that separate insiders and outsiders. In the meantime, I'll have to put up with the organization and hope that it takes its mission as seriously as its membership. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jun 11 18:59:33 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:59 2004 Subject: Inline markup considered harmful? (was RE: question for a friend) In-Reply-To: <199906111418.PAA11191@stevenson.cogsci.ed.ac.uk> References: <199906111418.PAA11191@stevenson.cogsci.ed.ac.uk> Message-ID: <14177.16104.75947.888156@localhost.localdomain> Richard Tobin writes: > Another solution, for some purposes, is to have two documents, one for > each hierarchy. Of course, you don't want to to duplicate the data > itself. We avoid this by using "standoff markup", which we implement > with XLinks (we have our own software to perform the transclusion > process). Way back in the 1980's, about 40 Internet years ago, the computer part Oxford English Dictionary project at the University of Waterloo (Ontario) published a short monograph on this issue. I no longer have my copy, and remember neither the title nor author, but the premise was that inline markup like SGML should be considered harmful, and that out-of-line markup was much more flexible (since you can apply more than one hierarchy to the same content). Tim Bray knows the OED people much better than I do, and he might be able to provide more useful details and/or correct my possibly-faulty recollection of the thesis. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jun 11 19:03:48 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:59 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <199906111513.LAA27001@hesketh.net> References: <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111513.LAA27001@hesketh.net> Message-ID: <14177.16743.489116.315637@localhost.localdomain> Simon St.Laurent writes: > In any case, it's all going to come back to one lucky individual - > Tim Berners-Lee - and there isn't much the rest of us can do about > it except hope that he listens. In using the word "lucky", is Simon implying that he'd like to trade places with Tim B-L, and have his phone number on Microsoft's, IBM's, Sun's, Oracle's, Netscape's, and everyone else's speed dialers? Heavy lies the head... All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Fri Jun 11 19:09:03 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:12:59 2004 Subject: Inline markup considered harmful? Message-ID: David Megginson wrote, > Tim Bray knows the OED people much better than I do, > and he might be able to provide more useful details > and/or correct my possibly-faulty recollection of the > thesis. I would be very interested in any references to this (or related) work that might me lying around. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mcdowella at mcdowella.demon.co.uk Fri Jun 11 19:16:25 1999 From: mcdowella at mcdowella.demon.co.uk (A. G. McDowell) Date: Mon Jun 7 17:12:59 2004 Subject: XHTML DTDs failing in IE5 In-Reply-To: References: Message-ID: I have made a quick search for RFCs promoting the well-known internet dictum "Be liberal in what you accept and conservative in what you send" So far I have found RFC 1122 (perhaps the widest quoted), RFC 791, and RFC 1896. This dictum sounds sensible and has been tested in practice. I don't see how a browser could justify going any further than raising some sort of warning indicator when faced with something it could interpret unambiguously, but dislikes. -- A. G. McDowell xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 11 19:31:50 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:12:59 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <14177.16743.489116.315637@localhost.localdomain> References: <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111513.LAA27001@hesketh.net> Message-ID: <199906111734.NAA01570@hesketh.net> At 01:05 PM 6/11/99 -0400, you wrote: >Simon St.Laurent writes: > > > In any case, it's all going to come back to one lucky individual - > > Tim Berners-Lee - and there isn't much the rest of us can do about > > it except hope that he listens. > >In using the word "lucky", is Simon implying that he'd like to trade >places with Tim B-L, and have his phone number on Microsoft's, IBM's, >Sun's, Oracle's, Netscape's, and everyone else's speed dialers? Heavy >lies the head... No, actually I was being sarcastic on lucky. I just can't stand to use smileys, so the deadpan creeps by unnoticed... I don't envy him one bit - it's a hell of a responsibility, and seems to be pretty thankless. Maybe if/when we have XML email, I can rewrite that as "one lucky individual". Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Jun 11 19:36:53 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:12:59 2004 Subject: Inline markup considered harmful? (was RE: question for a friend) Message-ID: <3.0.32.19990611103736.0221c6b0@pop.intergate.bc.ca> At 01:01 PM 6/11/99 -0400, David Megginson wrote: >Way back in the 1980's, about 40 Internet years ago, the computer part >Oxford English Dictionary project at the University of Waterloo >(Ontario) published a short monograph on this issue. I no longer have >my copy, and remember neither the title nor author, but the premise >was that inline markup like SGML should be considered harmful, and >that out-of-line markup was much more flexible (since you can apply >more than one hierarchy to the same content). Not sure I recall the paper, but I recall the work. You save a lot of space, but juggling N data files + M markup indices in parallel is just immensely more complex than chugging through tags, so you'd better be sure the benefits are high. Anyhow, stand-off markup as a concept has a long & distinguished intellectual history - it was at the core of Ted Nelson's Xanadu thinking, and sometime in the last 2 or 3 years there was a real good presentation on it at one of the Web conferences... Daniel Rivers-Moore if memory serves. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jun 11 19:40:19 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:59 2004 Subject: XHTML DTDs failing in IE5 In-Reply-To: References: Message-ID: <14177.18806.787173.252240@localhost.localdomain> A. G. McDowell writes: > I have made a quick search for RFCs promoting the well-known > internet dictum > > "Be liberal in what you accept and conservative in what you send" > > So far I have found RFC 1122 (perhaps the widest quoted), RFC 791, > and RFC 1896. This dictum sounds sensible and has been tested in > practice. I don't see how a browser could justify going any further > than raising some sort of warning indicator when faced with > something it could interpret unambiguously, but dislikes. It really depends on how serious the consequences of misinterpretation might be. Imagine, for example, that the browser tried to supply a missing tag and incorrectly rendered a chemical from the list of cleaning agents that *shouldn't* be used to the list of cleaning agents that *should* be used. Now, imagine that an aircraft maintenance mechanic then used that cleaning agent on the insulation around the wiring that passes through a jet's fuel tank. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at isogen.com Fri Jun 11 20:01:28 1999 From: robin at isogen.com (Robin Cover) Date: Mon Jun 7 17:12:59 2004 Subject: Inline markup considered harmful? (was RE: question for a friend) In-Reply-To: <14177.16104.75947.888156@localhost.localdomain> Message-ID: On Fri, 11 Jun 1999, David Megginson wrote: > Way back in the 1980's, about 40 Internet years ago, the computer part > Oxford English Dictionary project at the University of Waterloo > (Ontario) published a short monograph on this issue. I no longer have > my copy, and remember neither the title nor author, but the premise > was that inline markup like SGML should be considered harmful, and > that out-of-line markup was much more flexible (since you can apply > more than one hierarchy to the same content). Not from "Way back in the 1980s," but perhaps what you were thinking of was Raymond's TR (an early version of the monograph I reviewed was called "Markup Considered Harmful?".) --------------------- http://www.oasis-open.org/cover/bib-or.html#raymond356 **See the HTML source for links: Raymond, Darrell R.; Tompa, Frank Wm.; Wood, Derick. Markup Reconsidered. Department of Computer Science, Technical Report No. 356. The University of Western Ontario, 1993. 20 pages, 32 references. ISBN: 0-7714-1504-4. Abstract: We describe some of the implications of markup for document management systems. Markup's properties are inherited from text, since it is embedded in text. These properties are most advantageous when document structure is reducible to substrings of characters, and when the update characteristics of the structure are similar to the update characteristics of the text. We describe situations in which these characteristics are disadvantageous. Markup is not a data model, but one of several possible techniques for representing structure. For this reason it should not be the foundation of document management systems. Also available under the title [Technical Report] OED-93-01, UW Centre for the New Oxford English Dictionary, University of Waterloo (April 1993). A presentation under the same title was given at the First International Workshop on Principles of Document Processing, Washington, D.C. (October 21-23, 1992). An earlier version (unpublished") was written as "Markup Considered Harmful" and a related work was entitled "Reading Between the Tags: An Appraisal of Descriptive Markup" ["Markup Considered Harmful"?]. The UWO version of the paper is available via FTP to UWO; ftp://ftp.csd.uwo.ca/pub/csd-technical-reports/356/. The report is also available in PostScript format from UWaterloo, or here. - Robin Cover xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 11 20:10:08 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:12:59 2004 Subject: Inline markup considered harmful? In-Reply-To: References: <14177.16104.75947.888156@localhost.localdomain> Message-ID: <14177.20621.708944.301446@localhost.localdomain> Robin Cover writes: > On Fri, 11 Jun 1999, David Megginson wrote: > > > Way back in the 1980's, about 40 Internet years ago, the computer part > > Oxford English Dictionary project at the University of Waterloo > > (Ontario) published a short monograph on this issue. I no longer have > > my copy, and remember neither the title nor author, but the premise > > was that inline markup like SGML should be considered harmful, and > > that out-of-line markup was much more flexible (since you can apply > > more than one hierarchy to the same content). > > Not from "Way back in the 1980s," but perhaps what you were > thinking of was Raymond's TR (an early version of the > monograph I reviewed was called "Markup Considered Harmful?".) Thanks, Robin, yes, that's it. It cannot really be 1993, though, because I'm certain that I read it while I was still a graduate student in Toronto, and I had left Toronto for a teaching appointment in Ottawa in summer 1992. Memory fades with age, I guess. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Fri Jun 11 20:14:26 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:12:59 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach Message-ID: <03ae01beb435$263fbbd0$0b2e249b@fileroom.Synapse> Simon St.Laurent wrote: > >I think you've come to the conclusion that anyone who disagrees with you is >whining. Not at all. Anyone who disagrees with me is just plain wrong, and this is a longstanding fact :-)) The whining comment is directed not at those who disagree with my position, rather at browser vendors who complain that the attention given to XSL takes away from the ability or desire to use CSS. My position is that browsers should implement *both*. The argument against XSL is starting to sound like "I already have too much work to do..." > >I write books. The existence of standards makes those books worth writing, >but it makes very little difference (financially, at least) whether those >books cover CSS or XSL. I have no vendor agenda. Still, I think Michael >Leventhal is making some very important points. And I respect this position. My fear is that a few inflamatory comments in a newsgroup and on xml.com will generate an impression that there is widespread dissatisfaction with XSL in general. The WWW is a large place and I think there is more than enough room for CSS, XSL and DSSSL. If the browser vendors implement both CSS and XSL, then the WWW has choice about what to use. Let me clarify this position. I am concerned almost entirely with XSLT not XSL-FO. The XSL-FO vs. CSS argument is an entirely reasonable one ... and one which my mind is not yet made up on. XSLT is an entirely different issue. The "war" however has been declared on XSLT. > >I would genuinely like the W3C to sit down and ask if XSL is _good for the >Web_. Not good for the XSL community, not good for the DSSSL community, >but whether it is good for _the Web_. That is, after all, their job What is the Web aside from what the W3C says it is? Is the idea of a web native distributed computing platform _good_ for the "web"? If so, ought this include ECMAScript? Java? XSLT? Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Fri Jun 11 20:28:14 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:12:59 2004 Subject: Inline markup considered harmful? Message-ID: <84285D7CF8E9D2119B1100805FD40F9F25537A@MDYNYCMSX1> For those who are interested in learning more, Ted Nelson's essay "Embedded Markup Considered Harmful" is included in the O'Reilly/W3C 1997 book "XML Principles, Tools and Techniques." Bob DuCharme www.snee.com/bob "The elements be kind to thee, and make thy spirits all of comfort!" Anthony and Cleopatra, III ii xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Jun 11 20:48:54 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:13:00 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <03ae01beb435$263fbbd0$0b2e249b@fileroom.Synapse> Message-ID: <199906111851.OAA05005@hesketh.net> At 01:56 PM 6/11/99 -0400, Jonathan Borden wrote: > Not at all. Anyone who disagrees with me is just plain wrong, and this >is a longstanding fact :-)) The whining comment is directed not at those who >disagree with my position, rather at browser vendors who complain that the >attention given to XSL takes away from the ability or desire to use CSS. My >position is that browsers should implement *both*. The argument against XSL >is starting to sound like "I already have too much work to do..." Remember, not everyone has Microsoft's resources, and implementing a spec you flat out disagree with isn't a pleasant task. >My fear is that a few inflamatory comments >in a newsgroup and on xml.com will generate an impression that there is >widespread dissatisfaction with XSL in general. The WWW is a large place and >I think there is more than enough room for CSS, XSL and DSSSL. If the >browser vendors implement both CSS and XSL, then the WWW has choice about >what to use. I'm afraid that there _is_ widespread dissatisfaction with XSL in general. The XSL-List discussions and the XML.com discussions have made that clear. It's very hard to say negative things on XSL-list about the XSL project, unless you enjoy getting beaten up. I'm impressed that we detractors have held out as well as we have, and for so long. I may just be a lightning rod for people who don't like XSL, but I've had at least 10 Java developers say they thought XSLT was a horrible mess, along with about 15 Web developers. The 'FOs Considered Harmful' discussions raised real problems, that most XSL enthusiasts seemed inclined to ignore rather than solve, and those arguments go to the heart of what the 'Web' is about. > Let me clarify this position. I am concerned almost entirely with XSLT >not XSL-FO. The XSL-FO vs. CSS argument is an entirely reasonable one ... >and one which my mind is not yet made up on. XSLT is an entirely different >issue. The "war" however has been declared on XSLT. The 'war' has been declared on both fronts, though it sounds like the FO folks are at least trying to use CSS vocabulary at this point. (See recent postings on XSL-List.) > What is the Web aside from what the W3C says it is? Is the idea of a web >native distributed computing platform _good_ for the "web"? If so, ought >this include ECMAScript? Java? XSLT? If Netscape hadn't seen the W3C as Microsoft-friendly hostile territory, it might be W3Cscript rather than ECMAScript, or so I've read a few times. I doubt that Java will get anywhere near the W3C. XSLT may or may not be the business of the W3C - the membership is going to have to decide that. The best I can say for XSL is that the XSL community got off on the wrong foot by describing themselves as DSSSL-Lite and ignoring/denigrating CSS rather than focusing on shared vocabularies. Transformation to XML+CSS (even a rather modified and extended CSS) rather than transformation to FOs of whatever vocabulary would have sidestepped 90% of these issues. Instead, they forged ahead on their own, making enemies rather than allies. It's unfortunate, but that's where it's at, from my perspective. XSL could have looked very different had cooperation between XSL and CSS begun earlier, but the core functionality you keep demanding would probably have worked about the same. Disclaimer: I have no access to W3C proceedings - this is purely an outsider's perspective on what may have/could have happened. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at isogen.com Fri Jun 11 20:55:01 1999 From: robin at isogen.com (Robin Cover) Date: Mon Jun 7 17:13:00 2004 Subject: Inline markup considered harmful? In-Reply-To: <84285D7CF8E9D2119B1100805FD40F9F25537A@MDYNYCMSX1> Message-ID: On Fri, 11 Jun 1999, DuCharme, Robert wrote: > For those who are interested in learning more, Ted Nelson's essay > "Embedded Markup Considered Harmful" is included in the O'Reilly/W3C > 1997 book "XML Principles, Tools and Techniques." For those not familiar with the utter brilliance of Ted Nelson (the world should have a few more like him!) see for example "Ted Nelson's Computer Paradigm, Expressed as One-Liners" http://www.sfc.keio.ac.jp/~ted/TN/WRITINGS/TCOMPARADIGM/tedCompOneLiners.html Among which we find: Trying to fix HTML is like trying to graft arms and legs onto hamburger. There's got to be something better -- but XML is the same thing and worse. EMBEDDED MARKUP IS A CANCER. (see the "HTML" section) *apologies for failing to use transquotation strings (TQstrings) as required by the Transcopyright -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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From malliks at rocketmail.com Fri Jun 11 22:40:19 1999 From: malliks at rocketmail.com (Mallikarjuna Sangappa) Date: Mon Jun 7 17:13:00 2004 Subject: Function call in XSL using XT Message-ID: <19990611203541.18487.rocketmail@attach1.rocketmail.com> Hi All, I'm new to XSL. How do I call the function in the XSL? My XSL file looks like this. function currentDate() { return Date().toString() }

When multiple alternative implementations are provided, it is up to the XSLT processor to determine which to use.

 When I compile this using XT I'm getting the following error file:/C:/Mallik/XSLSamples/booklist.xsl:9: undefined prefix Thanks in advance. CU, Malliks _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Jun 11 23:10:19 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:00 2004 Subject: Two more SAX2 (0601) Parsers Message-ID: <37617BC0.999A02B7@pacbell.net> Have a look at http://home.pacbell.net/david-b/xml/ You can download adapters that put SAX2 interfaces onto Sun's "Project X" parsers (current release: TR2) and the Swing HTML parser. This release can be used with only the addition of the TR2 release; it includes classes and javadoc, as well as the full sources (not like they're that huge, though). SAX2 "Feature" list: true, false validation true external-{general,parameter}-entities true use-locator false namespaces, normalize-text The XML parser supports both the "DeclHandler" and "LexicalHandler" from the SAX2 draft. The only known caveats there: you won't see paramter entities exposed, or expansions of general entities from attribute values. The license is a modified QPL (Open Source). - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Jun 11 23:37:55 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:00 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java References: <14163.61975.304542.267110@localhost.localdomain> Message-ID: <3761821C.4446F61B@pacbell.net> > http://www.megginson.com/SAX/SAX2/ I thought I'd pass on some comments from having implemented to this API. (Does anyone have "user" comments yet?) Issues with what's now in the draft API: - I think the "validation" property should be immutable during parses; nonvalidating parses will generally discard data that a validating parse requires. - Why shouldn't declaration and lexical handlers be set "at any time" during a parse, like the SAX1 handlers? - When I implemented reporting of entity expansion for Sun last fall, I ran into a problem case that hasn't been addressed in the SAX2 draft. Namely, entities in attributes ... consider will generally get reported as startEntity ("entity"); endEntity ("entity"); startElement ("element", {"attr", value-of-entity, ...} ...); endElement ("element"); which doesn't really make sense. Sun's parser deals with this issue by not reporting such entity expansions. It's not clear to me how SAX2 will deal with the issue. - There's a similar issue with expanding parameter entities: And so on with conditional sections and other declarations; Sun's parser deals with that issue by not reporting parameter entity expansions through those reporting callbacks. Issues with what's NOT in the draft API, and where the lack is IMHO a notable API completeness issue for a "core" in SAX2: - Information re NOTATION attributes is discarded. In the example above, the attributeDecl() callback discards the list of which notations are permitted. Suggested fix: update the API. Sun's API doesn't discard this info, others are also possible. - The internal DTD subset isn't available. This means one can't reproduce the declaration; some applications have convinnced me that they absolutely require that capability. Suggested fix: as above, update the API (look at Sun's for one solution known to work). - The SAX1 handlers aren't "gettable" in the way the SAX2 ones are. Suggested fix: just define handler IDs for them. I thought I'd pass these along, since I've not seen much other feedback that relates to SAX2 implementation issues. - Dave p.s. http://home.pacbell.net/david-b/xml/ for the adapter I did to Sun's parsers. With those and AElfred, I think folk have a pretty good basis to experiment with validating and nonvalidating XML parsers (and an HTML parser!) to get some user experience with these APIs. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Jun 11 23:50:13 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:00 2004 Subject: SAX2: Namespaces and syntax of compound names References: <14176.9816.632368.748497@localhost.localdomain> Message-ID: <376184FA.B662EDAC@pacbell.net> David Megginson wrote: > > I have just heard a good argument for using the > > "{URIpart}localpart" > > syntax for compound names rather than the > > "URIpart localpart" > > I have always preferred the second format because it is easier to > split (most libraries have a built-in function for splitting around a > single character), but someone pointed out that the first format has > the advantage that you can tell simply by testing the first character > whether or not you have a compound name. I guess I'm still not at all sold on the notion of turning legal XML names into illegal ones that embed namespace URIs. To each his/her own, I guess. > Of course, Java will still be happier with the second, since String > operations in Java are painfully expensive. What does everyone else > think? The cost of answering the "what is the namespace for this element?" and "what is the unscoped/unprefixed name of this element" questions will be about the same in both cases. The cost of comparing the long strings (URI + local name) for equality will also not differ much, but of course the parser could intern them so that the comparison is a constant time "==" operation. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sat Jun 12 02:30:30 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:13:00 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <199906111851.OAA05005@hesketh.net> Message-ID: <000a01beb469$cde7aa30$1b19da18@ne.mediaone.net> Simon St.Laurent wrote: > > Remember, not everyone has Microsoft's resources, and implementing a spec > you flat out disagree with isn't a pleasant task. Yes but there are several source code available XSL implementations which could be reused. > > I'm afraid that there _is_ widespread dissatisfaction with XSL in general. > The XSL-List discussions and the XML.com discussions have made that clear. > It's very hard to say negative things on XSL-list about the XSL project, > unless you enjoy getting beaten up. I'm impressed that we detractors have > held out as well as we have, and for so long. > > I may just be a lightning rod for people who don't like XSL, but I've had > at least 10 Java developers say they thought XSLT was a horrible mess, > along with about 15 Web developers. Mess? why? Aside from the fact that declarative 'programming' can be a paradigm shift for those used to procedural programming. But that old argument aside, isn't there room for both styles? We have ECMAScript, Java, Python, PERL etc as common languages. Why not add XSLT? Diversity in languages is a Good Thing. I have used most major computer languages over the past 2 decades and support XSLT as a unique and useful addition to this family. > >The "war" however has been declared on XSLT. > > The 'war' has been declared on both fronts, though it sounds like the FO > folks are at least trying to use CSS vocabulary at this point. > (See recent > postings on XSL-List.) > And the XSLT folks? What would you have them do? Do you believe: 1) transformations are not important 2) procedural languages (e.g. ECMAScript+DOM) can handle transformations just fine. 3) DSSSL can be modified to better handle transformations 4) XSLT is just not a good way to transform (and if so please suggest another) What is your position here? Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Sat Jun 12 02:48:55 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:13:00 2004 Subject: Two more SAX2 (0601) Parsers In-Reply-To: <37617BC0.999A02B7@pacbell.net> Message-ID: <000001beb46d$b2ad7660$fd67fea9@w21tp> > Have a look at > > http://home.pacbell.net/david-b/xml/ > Looks pretty good. I think I'll steal some of your SAX2 support code to upgrade my own non-Schwinging SAXy HTML parser. At this point, I am past my first coding frenzy and getting ready to send out a HTML parser droid out to the sea of HTML world to see what percentage of the Net it can parse correctly. One big problem with this sort of testing is that it runs into the banner ad sites. I probably raised Yahoo's revenue by a few K in my trial run last night. Best, Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sat Jun 12 18:00:09 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:13:00 2004 Subject: My.UserLand.Com FAQ Message-ID: <4.2.0.56.19990612081520.01dcff00@mail.userland.com> This morning we released a new user interface for My.UserLand.Com, our XML-based syndication aggregation server. Along with this new release is a new FAQ page, which I thought would be interesting to XML content developers: http://my.userland.com/faq Key points: We're compatible with My.Netscape.Com, building on RSS.. There are over 100 compatible channels, including The Motley Fool, Robot Wisdom, Internet Alchemy, MacWEEK, ZDNet, Webmonkey, Mozilla.Org and XML.COM.. The registration system is open to all members.. Our server scans each hour on the hour, the home page lists the changes during each day. Many sites are updating their RSS files several times a day, the most frequently recently updated ones rise to the top.. The service is open, we publish our channel list.. Not stated on the FAQ page, we are archiving all the XML text every night at midnight. So as this takes off, each news site leaves a trail behind, so that others can pick up the information later. Time is an important factor here, and we've captured it. Now that the flow is happening, we're starting to build more aggregation services. The first step was to figure out the user interface. I think we're there now. Questions, comments and suggestions are welcome. Dave Winer UserLand Software xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Jun 12 18:48:38 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:00 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach References: <199906111851.OAA05005@hesketh.net> Message-ID: <37626DC5.CB1F94AB@prescod.net> "Simon St.Laurent" wrote: > > I'm afraid that there _is_ widespread dissatisfaction with XSL in general. Note that there is also widespread dissatisfaction with namespaces, RDF, XLink and XML itself. > I may just be a lightning rod for people who don't like XSL, but I've had > at least 10 Java developers say they thought XSLT was a horrible mess, > along with about 15 Web developers. I thought that you liked XSLT. Did you change your mind? I think that it would be more productive to separate concerns about XSLT from concerns about FOs. > The 'FOs Considered Harmful' > discussions raised real problems, that most XSL enthusiasts seemed inclined > to ignore rather than solve, and those arguments go to the heart of what > the 'Web' is about. Nobody solved the FOs considered harmful problems because they are *insoluable*. You cannot force people to put semantic markup on the Web. CSS can't force them to do so. CSS (by itself) doesn't even *allow* them to. XSLT allows them to (just as the DOM does). In my mind that is a Good Thing. > The best I can say for XSL is that the XSL community got off on the wrong > foot by describing themselves as DSSSL-Lite and ignoring/denigrating CSS > rather than focusing on shared vocabularies. Transformation to XML+CSS > (even a rather modified and extended CSS) rather than transformation to FOs > of whatever vocabulary would have sidestepped 90% of these issues. > Instead, they forged ahead on their own, making enemies rather than allies. 20/20 hindsight is great but don't we all as individuals have the responsibility to move on to technical issues instead of talking about how things should have been done three years ago? Please, let's talk about technology! XSL FOs are very much based on CSS properties. Where do you see the conflicts occurring? What exactly is your complaint? If we changed the prefix from FO: to CSS: would that address your concern? > XSL could have looked very different had cooperation between XSL and CSS > begun earlier, but the core functionality you keep demanding would probably > have worked about the same. It would look very different *how*? What technical proposal are you making? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Jun 12 18:48:29 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:00 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach References: <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> Message-ID: <37626FCB.457EF174@prescod.net> "Simon St.Laurent" wrote: > > All I can say on this one is that it sure hasn't felt like it from the > outside. At times, the public comments of W3C staff (plus former W3C folk) > and WG members on both sides have felt pretty much like open warfare, Differences of opinion are healthy. I don't see what the problem is with this. > and > coordination on vocabulary feels like an afterthought, nothing more. It is true that the W3C process encourages bottom up development where a spec. is developed and then integrated with the rest later. Of course the IETF and ISO have the same problem. The only way to do better would be to SLOW DOWN and map out the data and processing models before developing syntax. But who has time to figure out where we are going before we start driving? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at w3.org Sat Jun 12 23:00:27 1999 From: chris at w3.org (Chris Lilley) Date: Mon Jun 7 17:13:00 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) References: <03fd01bea2a6$19f351c0$6f6167cb@james.harvestroad.com.au> <374AE345.152015E4@prescod.net> <37591984.32F697C5@w3.org> <37597341.40FE2768@prescod.net> Message-ID: <3762C848.688DABB0@w3.org> Paul Prescod wrote: > > Chris Lilley wrote: > > > > > It strikes me as clearly poor design to use an HTTP url for something not > > > retrievable by the HTTP protocol. > > > > It would be, but no such examples were given. > > The XSL namespace is: > > http://www.w3.org/XSL/Transform/1.0 > > Is someone going to put something retrievable there? Why should something retrievable be put there? It functions just fine as a unique name without having to retrieve anything. -- Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Jun 12 23:27:06 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:13:00 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) Message-ID: <3.0.32.19990612142719.012242f0@pop.intergate.bc.ca> At 10:51 PM 6/12/99 +0200, Chris Lilley wrote: >> The XSL namespace is: >> http://www.w3.org/XSL/Transform/1.0 >> Is someone going to put something retrievable there? > >Why should something retrievable be put there? It functions just fine as >a unique name without having to retrieve anything. Might be a good idea to put a human-readable HTML doc there with a few words of explanation and a pointer to the WDs and other useful related resources. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sun Jun 13 06:04:44 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:00 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) References: <03fd01bea2a6$19f351c0$6f6167cb@james.harvestroad.com.au> <374AE345.152015E4@prescod.net> <37591984.32F697C5@w3.org> <37597341.40FE2768@prescod.net> <3762C848.688DABB0@w3.org> Message-ID: <37633558.3D983B93@prescod.net> Chris Lilley wrote: > > Paul Prescod wrote: > > > > Chris Lilley wrote: > > > > > > > It strikes me as clearly poor design to use an HTTP url for something not > > > > retrievable by the HTTP protocol. > > > > > > It would be, but no such examples were given. > > > > The XSL namespace is: > > > > http://www.w3.org/XSL/Transform/1.0 > > > > Is someone going to put something retrievable there? > > Why should something retrievable be put there? It functions just fine as > a unique name without having to retrieve anything. That's all very well and good but nameespace URIs are URIs *first* and (by definition) and whatever the namespace spec says they are ("globally unique name prefixes") second. According to the transcript above, you and I agree that HTTP URIs should not be used unless there is something retrievable by the HTTP protocol. That strikes me as common sense but can also be backed up by the relevant RFCs. (I'd rather not start the conversation again here...) URI must have a resource (even the null set) in order to be a URI. The 404 message is issued when there is no resource by a given name. Therefore the W3C's web server contradicts the recommendations of the (e.g.) XSLT specification. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Jun 13 09:12:12 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:13:01 2004 Subject: Inline markup considered harmful? References: Message-ID: <012801beb56b$9ba40b60$0300000a@cygnus.uwa.edu.au> > I would be very interested in any references to this > (or related) work that might me lying around. I spoke on this at SGML/XML Asia Pacific last year, taking Ted Nelson's article in the W3J as my starting point. I showed how XLink/XPointers could be used to achieve "parallel" markup then went on to discuss more philosophical issues relating to what assertions one is actually making when they mark up documents, arriving at the conclusion that the distinction between markup, content and presentation is a blurred, application-specific one (presentation is just another markup language, as is content). James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From csgallagher at worldnet.att.net Sun Jun 13 18:25:13 1999 From: csgallagher at worldnet.att.net (WorldNet) Date: Mon Jun 7 17:13:01 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) In-Reply-To: <3762C848.688DABB0@w3.org> Message-ID: <001101beb5ba$1bbbf580$0a000a0a@csg> > >http://www.w3.org/XSL/Transform/1.0 > > > > Is someone going to put something retrievable there? > > Why should something retrievable be put there? It functions just fine as > a unique name without having to retrieve anything. If someone could explain, I don't understand yet why a reference to such a 'namespace' would be useful, particularly if there is nothing there to access other than the seemingly ephemeral reference itself. -- Regards Clinton Gallagher NET cpio@metromilwaukee.com URL http://www.metromilwaukee.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sun Jun 13 18:42:11 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:13:01 2004 Subject: Inline markup considered harmful? References: Message-ID: <3763DF2B.6071@hiwaay.net> Robin Cover wrote: > > For those not familiar with the utter brilliance of Ted > Nelson (the world should have a few more like him!) see > for example > Trying to fix HTML is like trying to graft arms and legs > onto hamburger. There's got to be something better -- but > XML is the same thing and worse. EMBEDDED MARKUP IS A CANCER. Perhaps he is, Robin. I've a hard time with this comment as an expression of it. HTML, XML, SGML, etc. are all CS techniques to get work done: tradeoffs. Hypermedia floundered for years on the "brilliance" of such statements and only got working systems when some accepted engineering tradeoffs. More historical attention should be paid by the hypermedia communities to the niceties of scholarship with regards to the history of hypertext. The heroMachine of the WWW is disgusting even when it is just naivete. Still, for better or worse, and better IMHO, we now have tools that work because the Web starts with HyperText 101 (

and ) and grows from there. The advantage has been to get the entire world involved instead of just theorists, visionaries, and Brown U postDoc grads that made up most of the community prior to 1993. The one lesson I learned with no small portion of crow was, "we need to make this easier if we expect anyone to use it" - Jean Paoli For that to happen, like rock returns to blues, painters return to white, an writers return to haiku, sometimes to go forward, the blessed thing has to be torn down to basics and rebuilt. That is what the 1993 WWW was. It has a ways to go to reach Xanadu, but at least there are more people on the trek than were or could have been following Ted Nelson. HTML is dirt easy. XML is one step up. When you remove all the markup and just point, that's cool, but that is what relational systems do better than Xanadu. The good engineers use each tool where it works best. That's all. If the WWW has committed one mortal sin, it has been to work with the media to cannonize an effort that is simply that. Ted gets his 32 minutes of fame anyway. If he is committing a social faux pas, it is to denigrate the achievements of engineers who were willing, able, and succeeded in doing what he talked about. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 13 19:03:17 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:13:01 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) In-Reply-To: <001101beb5ba$1bbbf580$0a000a0a@csg> References: <3762C848.688DABB0@w3.org> Message-ID: <3.0.5.32.19990613130536.00a20e80@nexus.polaris.net> At 11:30 AM 06/13/1999 -0500, WorldNet wrote: >> >http://www.w3.org/XSL/Transform/1.0 >> > >> > Is someone going to put something retrievable there? >> >> Why should something retrievable be put there? It functions just fine as >> a unique name without having to retrieve anything. > >If someone could explain, I don't understand yet why a reference to such a >'namespace' would be useful, particularly if there is nothing there to >access other than the seemingly ephemeral reference itself. The idea is that a namespace identifier just needs to be a unique differentiator among element and attribute names that otherwise might be identical across various XML applications. The URI scheme has been suggested as a familiar way to accomplish this. I still haven't made up my own mind about it, but (to me) its chief flaw is that it *suggests* to a namespace-unaware human reader that There Is a "There" There. Namespace-aware software, however, doesn't make that mistake, which (again, to me) probably renders the flaw moot. ========================================================== John E. Simpson | The secret of eternal youth simpson@polaris.net | is arrested development. http://www.flixml.org | -- Alice Roosevelt Longworth xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From csgallagher at worldnet.att.net Sun Jun 13 19:38:07 1999 From: csgallagher at worldnet.att.net (WorldNet) Date: Mon Jun 7 17:13:01 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) In-Reply-To: <3.0.5.32.19990613130536.00a20e80@nexus.polaris.net> Message-ID: <001501beb5c4$4919d600$0a000a0a@csg> > The idea is that a namespace identifier just needs to be a unique > differentiate among element and attribute names that otherwise might be > identical across various XML applications. Okay, two or more documents interacting with one another are determined to have exact element and or attribute names so the namespace identifier then acts as a differentiator. What next? Meaning, I thought namespaces were going to be like libraries of contextual data definitions? >The URI scheme has been > suggested as a familiar way to accomplish this. I still haven't made up my > own mind about it, but (to me) its chief flaw is that it *suggests* to a > namespace-unaware human reader that There Is a "There" There. And I've become such an 'Accidental Tourist'. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 13 20:21:55 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:13:01 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) In-Reply-To: <001501beb5c4$4919d600$0a000a0a@csg> References: <3.0.5.32.19990613130536.00a20e80@nexus.polaris.net> Message-ID: <3.0.5.32.19990613142412.00b6b2e0@nexus.polaris.net> At 12:43 PM 06/13/1999 -0500, WorldNet wrote: >Okay, two or more documents interacting with one another >are determined to have exact element and or attribute names so the >namespace identifier then acts as a differentiator. What next? >Meaning, I thought namespaces were going to be like libraries >of contextual data definitions? It's understandable why someone might think so. But all a namespace is, in my understanding, is an abstract bucket in which can be placed all the "nouns" pertaining to a single XML universe of discourse. So if your documents never stray from a single such universe, they don't need namespaces. I think XSL is an interesting application in this case because the "nouns" it's intended to process will almost never be from the XSL universe itself. Some of XSL's own "nouns" (like apply-templates) are so distinctive in their own right that the likelihood of name clashes with the processed vocabularies, whatever they might be, is fairly small. Nonetheless, in the XML spirit of no-such-thing-as-a-reserved-word, an XSL processor expects you to declare that "in the context of this document [which just happens to be an XSL stylesheet], all XSL-specific nouns will be expressly associated with the XSL namespace." There's nothing magical about this. You could if you wanted associate the "xsl:" prefix with some *other* namespace. That would have to be almost calculatedly misleading on your part, though. :) >>The URI scheme has been >> suggested as a familiar way to accomplish this. I still haven't made up my >> own mind about it, but (to me) its chief flaw is that it *suggests* to a >> namespace-unaware human reader that There Is a "There" There. > >And I've become such an 'Accidental Tourist'. Anne Tyler, well, I'm not so sure I can force-fit her into an XML namespace discussion myself. But to return to the Gertrude Stein, er, namespace of "there is no there there," for a given XML document instance, a rose is not a sun:rose is not a midler:rose. That's all that namespaces are meant to keep sorted out. ========================================================== John E. Simpson | The secret of eternal youth simpson@polaris.net | is arrested development. http://www.flixml.org | -- Alice Roosevelt Longworth xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrew at greenehouse.com Mon Jun 14 10:26:53 1999 From: andrew at greenehouse.com (andrew@greenehouse.com) Date: Mon Jun 7 17:13:01 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <375EF568.CB9DC3FF@citec.fi> (message from Michael Leventhal on Thu, 10 Jun 1999 02:14:48 +0300) References: <805C62F55FFAD1118D0800805FBB428D0106AE8D@cc20exch2.mobility.com> <375EF568.CB9DC3FF@citec.fi> Message-ID: <19990610030123.AAA23447@AGREENE-NB.bitstream.com> The ultimate irony in this whole debate is that I found Michael's latest email message well-nigh unreadable because of the way it was "X-MIME-Autoconverted: from 8bit to quoted-printable by towanda.citec.fi id CAA06003" -- characters converted to the =xx format, wide lines wrapped so that very long and very short lines were alternating within a paragraph, often with words broken arbitrarily at column 74. This is not a criticism of Michael -- I receive several email messages a day that suffer from this problem. Most of them I delete out of hand, but I would have liked to have been able to read Michael's message, and I may still run it through perl to unmimify it. My point is this: while we're "investing" all this time debating whether CSS+DOM+ECMAscript or XSL is a better tool (personally, I want both, each for its own problem domain), we can't even get universally readable plain-text email. Enough, already, let's get back to doing some real work! [Speaking for myself, and not for Bitstream, and Lord knows not for any committees, working groups, consortia, cabals, illuminati, or cohorts.] - Andrew Greene xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From a.mutjeanne at castsoftware.com Mon Jun 14 10:26:44 1999 From: a.mutjeanne at castsoftware.com (Aurore MUT-JEANNE) Date: Mon Jun 7 17:13:01 2004 Subject: XSL Processor Message-ID: Hello, In your archives, you talk about a preview of the Microsoft XSL Processor. Unfortunately, the page on which it is supposed to be present does not exist anymore. Do you know the new location of this tool? Thank you for your help, Aurore MUT-JEANNE. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990614/96a4af45/attachment.htm From reagle at w3.org Mon Jun 14 10:26:45 1999 From: reagle at w3.org (Joseph M. Reagle Jr.) Date: Mon Jun 7 17:13:01 2004 Subject: Prior-Art Related to SGML used for controlling communications structures Message-ID: <3.0.5.32.19990603131351.00d10af0@localhost> The W3C is surveying potential prior art to assess the claims of Patent Number: 5862325. At their Web site Intermind states: How do I know if I might infringe? Products that incorporate Intermind’s technology are fairly easy to recognize: among other features, they rely on the exchange between publishers and subscribers of a file containing metadata (such as an XML file) to set up an active communications link. We call this file the communications object. http://www.intermind.com/materials/patent_faq.html If you are familiar with any SGML applications that were used to control or structure the exchange of information over a network, please have a look at the brief description and let us know! [1] [1] http://www.w3.org/Consortium/Legal/intermind-p3p-patent-19990421.html _________________________________________________________ Joseph Reagle Jr. Policy Analyst mailto:reagle@w3.org XML-DSig Co-Chair http://w3.org/People/Reagle/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From terris at terris.org Mon Jun 14 10:26:38 1999 From: terris at terris.org (Terris Linenbach) Date: Mon Jun 7 17:13:01 2004 Subject: tech doc ML (TDML?) Message-ID: <000501beaccb$cf72d320$de44480c@compaq> The benefits of marking up documents in XML instead of HTML include a consistent look, although editing XML isn't exactly convenient (forget about WYSIWYG). I am trying to find documentation on mark-up for technical documents, like those you would see on http://www.w3.org or http://msdn.microsoft.com. Some w3 documents are available as XML although I can't find documentation on the DTD or the code that was used to convert them to HTML. Any pointers? Do you use your own XML format and code to convert this XML to HTML? If so I would be interested in using what you have. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From miles at mistral.co.uk Mon Jun 14 10:26:42 1999 From: miles at mistral.co.uk (Miles Sabin) Date: Mon Jun 7 17:13:01 2004 Subject: Confusion while implementing the DOM Message-ID: <000001bead3d$d818d930$2ae7b8c3@ontic> Don Park wrote, > Miles Sabin wrote, > > No mistake. A DocumentFragment *is* a Node. But if you > > try and insert it into the tree, you'll find that a > > conforming implementation will throw a > > HIERARCHY_REQUEST_ERR. > > Actually, inserting a DocumentFragment 'node' into a > tree should insert the child nodes of the > DocumentFragment (leaving it empty). Oops ... I *think* that what I was trying to say was ... exactly what you just said. Or maybe I temporarily took leave of my senses ;-) Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dietmar.loder at netway.at Mon Jun 14 10:26:55 1999 From: dietmar.loder at netway.at (dietmar.loder@netway.at) Date: Mon Jun 7 17:13:01 2004 Subject: XMl - DTD and Table Definition Message-ID: <199906110913.LAA10119@webmail.netway.at> Hi, I am in the area of XML! Now I have to export and import large databases via XML-format. This data are structured in typical master-detail relations (1 master have approximatly 15 to 25 details records, one exportfile have 30000 - 500000 master elements). If I write the details records like the standard XML format, shown in serveral books and samples via www, I waste a lot of space for Start-End- Tag's. To minimize the filesize, I decide to use the
syntax. Questions: Is this allowed in a "well-formed" XML document? Or is this only allowed in HTML? How looks like a corresponding DTD for a table definition? Have someone samples for this problem? Dietmar -------------------------------------------------------------------------- dietmar.loder@netway.at xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From aroldan at homeside.com Mon Jun 14 10:26:51 1999 From: aroldan at homeside.com (Roldan, Alex) Date: Mon Jun 7 17:13:01 2004 Subject: Server side DTD validation only ? Message-ID: <342957C6CEFFD211A63B0008C707C3C82337FC@hslnt98jax.homeloan.com> To me It seems that performing DTD validation on the client and server side is an unnecessary overhead. Currently, I am only performing validation against the DTD on the server side app. The request and the response are both validated by the server app by pre-pending the DTD to the XML document before it is validated. The text XML data created by the client does not contain the DTD or an external reference to the DTD. 1. Is this the right approach ? 2. What are the problems I can run into ? Thanks Alex xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Mon Jun 14 10:26:39 1999 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:13:01 2004 Subject: Just require URLs References: Message-ID: <3754B8C0.3389B5EC@isogen.com> Didier PH Martin wrote: > interpretable documents. > c) If we choose to use a URL for a name space identifier, we create location > dependency to our documents, If we choose URNs, the documents are then > location independent. Again, with some forward thinking, the name space I would like to remind everyone that URLs are no more or less fragile or "location dependent" than URNs are. Both can be equally indirect. This is same as the bogus PUBLIC/SYSTEM distinction SGML makes: a pointer to a thing is a pointer to a thing, and the degree of indirection you expect to have behind it is both unknowable and irrelevant to the use of the pointer. Adding indirection within the data representation mechanism (e.g., entity resolution in SGML, URN resolution on the Web) may be convenient, but it is not a necessary prerequisite for having managable or persistent names. Persistence accrues from having persistent name servers, which any HTTP server can be, given that there are any number of ways to do indirect URI resolution within a server. Therefore the use or non-use of URNs is a technology choice to be made by resource owners and should not be a policy requirement imposed by standards. [For this reason, XML is *wrong* to require that notations use public IDs and not use system IDs, for example.] The only thing you know about URNs is that they will always involve one more level of indirection than the most direct URL. But the reverse is not true. That is, any URL could be just as indirect as any URN, and therefore, just as robust. Arguing about which form of name to use is a waste of time, because what's important isn't the name but the thing at the other end of it. What *is* important is the infrastructure in place for managing the indirection you need to make the names you control managable. But this issue is orthoganal to the URL/URN issue. One of the things that the Topic Map discussion should have made clear is that the idea of an "abstract thing" is bogus--there are only things. You either have only the name for the thing, in which case the name *is* the thing (because it's the only physical thing you've got) or you have the thing itself (the physical storage object the URI resolves to). In other words, if you identify a namespace with a URI which cannot be resolved to a resource (because no-one has defined the mapping from the URI to some physical object), then the URI *is* the namespace. That is, the character string that constitutes the URI is the physical (and therefore identifiable) resource that constitutes the namespace. Fortunately, the physical manifestation of a namespace is undefined, so any physical object will do to establish its identity, including a URI. If the URI can be resolved to a resource, then that resource establishes the identity of the namespace. It doesn't matter what the spelling of the URI is, only that it exists. Note that because there is no normative definition of what the definition of a namespace is (in the way, for example, that a DTD is normatively defined by the declarations in the DOCTYPE declaration or an SGML architecture is defined by its documentation and meta-DTD), all we can hope to get from the namespace declaration is establishment of identity of name spaces. That is, given two documents that both declare the use of a namespace, do they use the same or different name spaces? Since the same object can be addressed by many pointers, I would normally expect to get an object from each pointer and then see if I've gotten the same object [Note that it is up to the storage managers for the objects to determine and report identity--but that's inherent in the way computers work--since we cannot physically see and touch storage objects in most forms of media, we are dependent on the storage managers to tell us what we need to know.] If I can't resolve the pointer, then all I have is the pointer itself. If the true intent of the namespace mechanism is that the URI *is* the namespace (in the sense defined above), then they have to *disallow* resolution of the URI, otherwise, you cannot reliably establish namespace identity because two different URIs could identify the same resource. If the only objects you have are the URIs, then you know that if two URIs are different that you have two different name spaces (because the namespace objects, the URIs, are different). If namespace URIs can be resolved, then if you have two URIs, one of which you can resolve to a resource and one of which you cannot, you cannot know whether the two namespaces are the same or different because identity of the one whose URI you couldn't resolve has yet to be established (URIs cannot by themselves establish the identity of the resources they address). If you want to have namespaces for which the *only* physical manifestation is the URI of the namespace, then there must be defined a URN domain in which the URNs are their own resources. It is not enough to simply say "namespace URNs are not to be resolved", because the namespace spec doesn't have the authority to disallow the resolution of URNs. Besides, it's bogus to have namespaces that are not documented in some way, even if the namespace spec doesn't require it. Without some authoritative definition of the namespace, how can I know whether or not I'm using it correctly. Therefore, there must *always* be some resource for the name space and it is the responsibility of the namespace owner to make that resource reliably addressible within its expected scope of use. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. eliot@isogen.com 2200 N. Lamar St, #230, Dallas, TX 75202 512.339.1400, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Steve.Ball at zveno.com Mon Jun 14 10:26:50 1999 From: Steve.Ball at zveno.com (Steve Ball) Date: Mon Jun 7 17:13:01 2004 Subject: XML Document to ascii text file References: <19990608153917.7335.rocketmail@attach1.rocketmail.com> Message-ID: <375E5B99.6AD80BFB@zveno.com> Mallikarjuna Sangappa wrote: > > This is very urgent. Is there any program or tool > which converts an XML document to ascii text file. I have a simple example, "dexml.tcl", on the TclXML Website: http://www.zveno.com/zm.cgi/in-tclxml/ It just outputs the character data to a file or standard output. With a little scripting, you could do something with the markup as well. HTHs, Steve Ball -- Steve Ball | Swish XML Editor | Training & Seminars Zveno Pty Ltd | Web Tcl Complete | XML XSL http://www.zveno.com/ | TclXML TclDOM | Tcl, Web Development Steve.Ball@zveno.com | Ph. +61 2 6242 4099 | Fax +61 2 6242 4099 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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.sergeant at ericsson.com Mon Jun 14 10:26:49 1999 From: matt.sergeant at ericsson.com (Matt Sergeant) Date: Mon Jun 7 17:13:01 2004 Subject: XML Document to ascii text file References: <19990608153917.7335.rocketmail@attach1.rocketmail.com> Message-ID: <375D44BE.45F3C287@ericsson.com> Mallikarjuna Sangappa wrote: > > Hi All, > > This is very urgent. Is there any program or tool > which converts an XML document to ascii text file. > Thanks in advance. Have you tried `cat` ? ;-) Your easiest option might be perl (for various values of "might"). Here's a one liner: perl -MXML::Parser -e "XML::Parser->new(Handlers=> {Char => sub {print $_[1]}})->parse(*STDIN)" < xmlfile Which simply strips all the tags away. That is what you want, right? Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Mon Jun 14 10:26:40 1999 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:13:01 2004 Subject: Namespace URI address resources References: Message-ID: <3754EE1F.8498F9D1@isogen.com> Didier PH Martin wrote: > Didier says: > Exactly. A URI represent something. It is a U_niform R_esource I_dentifier. > It provides identitity to a resource. No, a URI does *not* provide identity to a resource--it *identifies* a resource, but it does not provide identity for the resource. That is, given two different URIs, you cannot know, from the URIs alone, whether they identify the same resource or a different resource. This is because the same resource can be identified by many different URIs, just as a human can have many different names. Unless the URI *is* the resource, it does not establish identity of the resource it addresses. And note that identity can only be truly established at a specific point in time. The same URI resolved at two different points in time may resolve to provably different resources. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. eliot@isogen.com 2200 N. Lamar St, #230, Dallas, TX 75202 512.339.1400, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From re6 at mindspring.com Mon Jun 14 10:26:34 1999 From: re6 at mindspring.com (RE6 Computer Services) Date: Mon Jun 7 17:13:02 2004 Subject: Newbie comment on URNs and URLs- (RE: Paul has volunteered (was Re: Overloaded URIs must GO!)) Message-ID: <000001beabba$e2c6d1e0$7c1756d1@LocalHost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >-----Original Message----- *(edited) >Didier says: >Here we are. I remember a good discussion (within IETF groups) we got about >URIs and a lack of a RFC explaining the role of each. We didn't reached >consensus and the result today... we are right in the problem :-)) > >I remember that the main point is the name. Read attentively the following >name: U_niversal R_esource L_ocator > >The name itself self describe in the sense that it is used to express a >location, a "place". > >At contrario, a: U_niversal R_esource N_ame >Is a "name". > >The former explicitely contains the meaning of a location. The latter the >explicitely the meaning of a "name" and not of a location. For instance, I >may use the URN convention to express the inventory record identifiers or as >identifier for some collection organized in a typical name space. >But, if we want to express a location with a URL, its made for this. So, if >the name space reference uses a URL and that no document is at the other >end, it is like a 404 error (in the case of the HTTP protocol). Or like >having a rendez-vous but nobody came to it :-) > >regards >Didier PH Martin >mailto:martind@netfolder.com >http://www.netfolder.com - -----END ORIGINAL MESSAGE----- Pardon for the interruption, but I've been following this thread, and it seems to me that Didier has said it succinctly: Use the URLs to point to a URN. The question of how to identify a document uniquely is another matter, and one that is to be addressed by the URN, and not the URL, correct? Also, much ado has been made about the seeming requirement to have one and only one "object" on a network. In small to medium-sized networks, such as a local network or a corporate network, that makes sense. In larger networks it doesn't make sense. It is impractical to jump 73 times to retrieve a document 12 Meg in size at the same time 120,000 other people are trying to retrieve it. Nor does it make sense to make 73 jumps to retrieve an object that is only 18k in size. Notice the popularity of "mirrors". On a network the size of the Internet, one instance of an object is clearly not the best approach. The key, though, is that each instance has a unique identity combined with its URL. An analogy: URNs and URLs are related as telephone lines are related to entities: I can have several telephone numbers, each one pointing to a unique individual (me). I would be considered a URN, and each of the phone lines would be considered the URLs. However, because I am unique, that does not mean I have a unique name. It is only unique when it is combined with a unique identifier, such as a URL (phone number). Obviously, URLs can only point to one unique object, period. The only reason that it isn't a good unique identifier is if the object's *location* changes. If I move to Florida, USA, then my phone numbers change and I can no longer be uniquely identified by the old ones. Nor does it help anyone trying to contact the prior owners of the telephone numbers I inherit in Florida. In a DNS, the domain name is coupled with an IP address. HTTP utilizes the IP addresses to find its way on the network; which leads me to wonder if the DNS can also affiliate a domain name AND a URN to a location instead of having another dedicated server provide the same function? Therefore, I don't see a problem using HTTP to specify a URN to retrieve rather than the URL, which changes just as long as the DNS is updated with the new location. Sort of like using "call forwarding" on my old telephone lines to ensure that I continue to receive phone calls to my old numbers (URLs). After a specified period of time, that service is discontinued; anyone not getting the change information would have to relocate my telephone numbers which is usually accomplished by using my name and other personal information (URN). Of course, one of the great things about IP addresses and domain names is that it is much easier to change where a URL points, especially if the hyper link uses a domain name rather than specifying IP addresses. After all, wasn't that one of the intents behind creating domain name systems? In other words, although a URL is a unique identifier, it should not be used as part of the URN, a truly unique identification for that object. One last question: If an object is copied, is the URN supposed to change, or is it supposed to remain the same? My apologies if I have inadvertently offended someone's intellect, or if I have violated any rules of conduct, or performed any other type of rude error. Sincerely, Robert Reese~ RE6 Computer Services re6@mindspring.com "You can't strengthen the weak by weakening the strong." - Unknown -----BEGIN PGP SIGNATURE----- Version: PGP 6.0.2 Comment: Outrageous! iQA/AwUBN1MXCA1HXbubR+OwEQKvzgCgzzbz6Jcg6fK3voDFCCVI5tHoMcYAoOnS YZdeqWTgwhvxClo+5cBPdO3z =16tj -----END PGP SIGNATURE----- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SMUENCH at us.oracle.com Mon Jun 14 11:05:42 1999 From: SMUENCH at us.oracle.com (Steve Muench) Date: Mon Jun 7 17:13:02 2004 Subject: tech doc ML (TDML?) Message-ID: <199906140907.CAA09963@mailsun2.us.oracle.com> How about DocBook? Seems like just what you're looking for. I'm only familiar with the XML-flavor of DocBook, but it originates from its SGML ancestor. Norm Walsh has quite a bit of info on it (Both XML/SGML versions) at: http://nwalsh.com/sgml/index.html He's recently posted some XSL Stylesheets for DocBook there, too. _________________________________________________________ Steve Muench, Consulting Product Manager & XML Evangelist Business Components for Java Dev't Team http://www.oracle.com/xml -------------- next part -------------- An embedded message was scrubbed... From: "Terris Linenbach" Subject: tech doc ML (TDML?) Date: 02 Jun 99 00:44:54 Size: 2745 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990614/3da2a6a9/attachment.eml From rbourret at ito.tu-darmstadt.de Mon Jun 14 12:15:45 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:13:02 2004 Subject: tech doc ML (TDML?) Message-ID: <01BEB65F.9BD4B770@grappa.ito.tu-darmstadt.de> Terris Linenbach wrote: > I am trying to find documentation on mark-up for technical > documents, like those you would see on http://www.w3.org or > http://msdn.microsoft.com. Some w3 documents are available > as XML although I can't find documentation on the > DTD or the code that was used to convert them to HTML. You can find the DTD that the W3C uses to write specs at: http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm (I assume this is the current version, but don't actually know that for sure.) -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Mon Jun 14 13:19:43 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:13:02 2004 Subject: Newbie comment on URNs and URLs- (RE: Paul has volunteered (was Re: Overloaded URIs must GO!)) In-Reply-To: <000001beabba$e2c6d1e0$7c1756d1@LocalHost> Message-ID: Hi Robert, Robert said: In other words, although a URL is a unique identifier, it should not be used as part of the URN, a truly unique identification for that object. One last question: If an object is copied, is the URN supposed to change, or is it supposed to remain the same? Didier says: If the copy is exactly a mirror of the original, you can add it to the URL list associated to a particular URN. And about the resolver, yes, a HTTP server could be used to resolve URNs as long as you have the client part that knows where to connect to resolve the particular name space. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at isogen.com Mon Jun 14 13:28:55 1999 From: robin at isogen.com (Robin Cover) Date: Mon Jun 7 17:13:02 2004 Subject: Inline markup considered harmful? In-Reply-To: <3763DF2B.6071@hiwaay.net> Message-ID: On Sun, 13 Jun 1999, Len Bullard wrote: > Robin Cover wrote: > > > > For those not familiar with the utter brilliance of Ted > > Nelson (the world should have a few more like him!) see [...] > Perhaps he is, Robin. I've a hard time with this comment as an > expression of it. > > HTML, XML, SGML, etc. are all CS techniques to > get work done: tradeoffs. Hypermedia floundered for years on the > "brilliance" of such statements and only got working systems when > some accepted engineering tradeoffs. [...] How can I pick up a sword to defend Ted Nelson (as though he could benefit from that) when, on any given day, I'd just as quickly take delight in defending you? No, Len Bullard, I respect you too much to argue religion, philosophy, and politics in public space [offline if you want]. I even agree with you to a point, though my threshold is much lower than for many, I suspect, in identifying the point at which "worse is better" (lectio difficilior preferendum est) have been applied ad absurdum. More often I hear these tunes sung by poor souls seeking to console themselves, having capitulated in the abandonment of some high ideal. Contrariwise: at the level I experience the Web via HTTP/HTML, a heap of broken links, it's massively and profoundly broken by design. That "people use it" is quite unremarkable, in one respect, as another of the one-liners on Ted's page says: "Microsoft is not the problem; Microsoft is the symptom." Ted's judgment probably seems harsh because he measures a thing against its potential -- not just by "nothing is proven to work better than..." That he may himself be judged a failure as compared (e.g.,) to Bill Gates is no doubt the common verdict. In referencing his brilliance, I was speaking from a different reference point, and different set of values, where measurement by counting companies acquired, companies brought to IPO, and 'successful' software products delivered (etc.) has no currency. Among Ted's gifts, some would say, is an unusual ability to damn mediocrity by identifying it and labeling it so plainly that it hurts. -r xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 14 15:08:55 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:02 2004 Subject: Top-down or bottom-up? In-Reply-To: <37626FCB.457EF174@prescod.net> References: <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> Message-ID: <14180.64662.493404.927680@localhost.localdomain> Paul Prescod writes: > It is true that the W3C process encourages bottom up development > where a spec. is developed and then integrated with the rest > later. Of course the IETF and ISO have the same problem. The only > way to do better would be to SLOW DOWN and map out the data and > processing models before developing syntax. But who has time to > figure out where we are going before we start driving? In principle, I know that Paul is right; in practice, I've lost much of the faith that I once had in top-down approaches to anything, from system design to macroeconomics. More specifically, top-down can work only with very, very good models, and even I (who am known to shoot my mouth off) would not go so far as to claim that I can produce a sufficiently accurate and complete model of the Web over the next five years; in the absence of such a model, bottom-up development and the free market of ideas is the only reasonable choice, messy as it may be. Remember the big experiments in top-down, centralized economic planning in the 1960s, '70s, and '80s? Our grandchildren may still be paying off the debts from that one. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jun 14 15:19:56 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:02 2004 Subject: Overloaded URIs (was Re: XLink: behavior must go!) In-Reply-To: <001101beb5ba$1bbbf580$0a000a0a@csg> References: <3762C848.688DABB0@w3.org> <001101beb5ba$1bbbf580$0a000a0a@csg> Message-ID: <14181.330.386270.366799@localhost.localdomain> WorldNet writes: > If someone could explain, I don't understand yet why a reference to > such a 'namespace' would be useful, particularly if there is > nothing there to access other than the seemingly ephemeral > reference itself. You can uniquely identify names across document types; for example, a search engine could recognize an HTML element in many different document types, and a rendering engine could have a library of handlers for well-known element types. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Jun 14 15:43:36 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:13:02 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <000a01beb469$cde7aa30$1b19da18@ne.mediaone.net> References: <199906111851.OAA05005@hesketh.net> Message-ID: <4.0.1.19990613212137.00f50eb0@pop.hesketh.net> At 08:23 PM 6/11/99 -0400, Jonathan Borden wrote: > Mess? why? Aside from the fact that declarative 'programming' can be a >paradigm shift for those used to procedural programming. But that old >argument aside, isn't there room for both styles? We have ECMAScript, Java, >Python, PERL etc as common languages. Why not add XSLT? Diversity in >languages is a Good Thing. I have used most major computer languages over >the past 2 decades and support XSLT as a unique and useful addition to this >family. It's more than a paradigm shift affecting people, from what I've heard. XSL lets you do a lot, but finding organizing principles to do it with appears to be harder than perhaps it should be. Perhaps this is just a matter of time, or perhaps the problem is just that XSL is indeed ugly and verbose and provides few hooks for developers used to working with other Web technologies. > And the XSLT folks? What would you have them do? Do you believe: > >1) transformations are not important In some cases, like transforming XML tables to SVG, it's great. I'm not convinced that it's important in every case, nor am I convinced that XSLT is the 'right' way to handle transformations. >2) procedural languages (e.g. ECMAScript+DOM) can handle transformations >just fine. Yep. I got started in this area through Dynamic HTML, so I'm undoubtedly biased, but this supposedly incredible need for XSL escapes me. >3) DSSSL can be modified to better handle transformations I haven't said one thing about DSSSL one way or the other. If the SGML community wants to invest further in DSSSL, that's great. If not, it's not anywhere near my problem. >4) XSLT is just not a good way to transform (and if so please suggest >another) Ugly, verbose... perhaps useful in some situations, but hardly a crying need when other tools that have been widely implemented are capable of providing the same functionality. I think we've come back around to the root of the argument. If you want to continue, we can circle around a few more times. I'm off to JavaOne, so I'll only be able to circle sporadically for the next few days. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jgarrett at navix.net Mon Jun 14 16:02:33 1999 From: jgarrett at navix.net (Jim Garrett) Date: Mon Jun 7 17:13:02 2004 Subject: Attached msg of the Steve Muench post on RE: tech doc ML (TDML?) In-Reply-To: <199906140907.CAA09963@mailsun2.us.oracle.com> Message-ID: Is the Steve Muench attachment safe to open ? What is this "msg" format about ? Why post in "msg" format, why not HTML or just plain text ? Attached is a copy of the msg format from the Steve Muench post |-----Original Message----- |From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of |Steve Muench |Sent: Monday, June 14, 1999 4:07 AM |To: terris@terris.org |Cc: xml-dev@ic.ac.uk |Subject: Re: tech doc ML (TDML?) | | |How about DocBook? Seems like just what you're looking for. | |I'm only familiar with the XML-flavor of DocBook, but |it originates from its SGML ancestor. | |Norm Walsh has quite a bit of info on it (Both XML/SGML versions) at: | | http://nwalsh.com/sgml/index.html | |He's recently posted some XSL Stylesheets for DocBook |there, too. | |_________________________________________________________ |Steve Muench, Consulting Product Manager & XML Evangelist |Business Components for Java Dev't Team |http://www.oracle.com/xml | -------------- next part -------------- An embedded message was scrubbed... From: "Terris Linenbach" Subject: tech doc ML (TDML?) Date: Tue, 1 Jun 1999 19:44:54 -0500 Size: 1570 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990614/dc728e31/attachment.eml From simonstl at simonstl.com Mon Jun 14 16:10:07 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:13:02 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <37626DC5.CB1F94AB@prescod.net> References: <199906111851.OAA05005@hesketh.net> Message-ID: <199906141411.KAA11113@hesketh.net> At 09:25 AM 6/12/99 -0500, Paul Prescod wrote: >"Simon St.Laurent" wrote: >> I'm afraid that there _is_ widespread dissatisfaction with XSL in general. > >Note that there is also widespread dissatisfaction with namespaces, RDF, >XLink and XML itself. Apart from Ted Nelson's excellent "Embedded Markup Considered Harmful", I haven't seen much claiming that XML is a danger to the semantic Web the W3C seems interested in building. Dissatisfaction with particulars, of course, is rampant. That seemed to generate most of the violence over namespaces. Dissatisfaction with the project? I think XSL has a pretty good claim to most of that. >I thought that you liked XSLT. Did you change your mind? I don't think XSLT is necessary, though I certainly can see where people might want to use it for certain cases. As far as XSLT's structure is concerned, I can't say it thrills me. It does work, however. >I think that it would be more productive to separate concerns about XSLT >from concerns about FOs. If FOs didn't exist, I think we could do that. Unfortunately, because the original drive of XSL was transformation into FOs, and not into a modified tree annotated with formatting information, I don't think it's possible unless you change FOs. >Nobody solved the FOs considered harmful problems because they are >*insoluable*. You cannot force people to put semantic markup on the Web. >CSS can't force them to do so. CSS (by itself) doesn't even *allow* them >to. XSLT allows them to (just as the DOM does). In my mind that is a Good >Thing. CSS+XML doesn't allow them to post semantic markup? (CSS by itself doesn't let you post _anything_, so I don't know what you're talking about. HTML?) The question is not whether FO's harmfulness is solvable, it's whether it's an acceptable cost. I see it as a cost that wouldn't have been incurred had we stuck to annotation for formatting - while you could strip semantics to SPAN and DIV if you really wanted, the whole selector mechanism of Cascading Style Sheets discourages such practice. It would have taken an extra level of processing to do that stripping. Output to HTML from XSLT is ugly, but it's an ugly we're already used to and which XHTML is smoothing out to some extent anyway. >20/20 hindsight is great but don't we all as individuals have the >responsibility to move on to technical issues instead of talking about how >things should have been done three years ago? In this case, 20/20 hindsight for the XSL community is an "I told you so" for the CSS community. Take a look at the early battles on XSL-list and you'll see that I'm saying nothing original here - these arguments were on the list before I even subscribed. Doesn't it seem like our responsibility to learn from the lessons of _one_ year ago rather than racking up the same kinds of problems again and again? >Please, let's talk about technology! XSL FOs are very much based on CSS >properties. Where do you see the conflicts occurring? What exactly is your >complaint? If we changed the prefix from FO: to CSS: would that address >your concern? The problem, fundamentally, is that XSL FOs are an element vocabulary, while CSS properties lived inside attributes or style sheets, without disrupting the original element names. Make FOs properties rather than elements, and maybe we can talk. Of course, this would mean reexamining XSL FOs from a CSS perspective, and I'm not sure that's a technical proposition the XSL community would enjoy for political reasons. >> XSL could have looked very different had cooperation between XSL and CSS >> begun earlier, but the core functionality you keep demanding would probably >> have worked about the same. > >It would look very different *how*? What technical proposal are you >making? See above. Transformations to an endpoint that still had as much semantics as the original - formatting properties represented as attributes rather than elements - might have avoided lots of the 'considered harmful' issues that you want to ignore. I think inclusion and sequence are the only large problems such an approach presents, and I don't think they're insoluble. (Unlike FOs' harmfulness, for example.) Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 14 16:16:46 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:13:02 2004 Subject: Just require URLs References: <3754B8C0.3389B5EC@isogen.com> Message-ID: <37650F40.A1FBFCA3@locke.ccil.org> W. Eliot Kimber wrote: > [For this reason, XML is *wrong* to require that notations use public > IDs and not use system IDs, for example.] Say what? Notations *permit* the use of public ids without system ids, since system ids are always URIs (where ) in XML. It's entities that require URIs, and don't allow bare public ids. > You either have only the name for the thing, in which case the name *is* > the thing (because it's the only physical thing you've got) or you have > the thing itself (the physical storage object the URI resolves to). Wow. Nominalism redivivus: universals as flatus URis. :-) But really that won't do. One can live with only concrete things and classes, but classes are not eliminable in favor of concrete things only, nor are they just names: the number of classes, indeed, outruns the number of names. > If the true intent of the namespace mechanism is that the URI *is* the > namespace (in the sense defined above), then they have to *disallow* > resolution of the URI, otherwise, you cannot reliably establish > namespace identity because two different URIs could identify the same > resource. If the only objects you have are the URIs, then you know that > if two URIs are different that you have two different name spaces > (because the namespace objects, the URIs, are different). If namespace > URIs can be resolved, then if you have two URIs, one of which you can > resolve to a resource and one of which you cannot, you cannot know > whether the two namespaces are the same or different because identity of > the one whose URI you couldn't resolve has yet to be established (URIs > cannot by themselves establish the identity of the resources they > address). This confuses the *possibility* of resolving a namespace URI with the *non-necessity* of doing so. I take the position of the Namespace Rec to be that resolution is not useful for determining identity (namespace identity = URI identity) but resolution *may* provide properties of the namespace other than identity, because of the principle of the indiscernibility of identicals: if two namespace URIs are identical, the resources they mention are either non-existent or identical likewise. (The converse does not hold, of course.) The result is that two namespace URIs which resolve to the same resource define two namespaces which share some properties but are not identical. It is not necessarily the case that URNs are resolvable to URLs: the URN urn:isbn:0-671-79573-2 has a referent (_The Gripping Hand_, by Larry Niven and Jerry Pournelle, 1st edn hc) but 1) is not resolvable to an URL and 2) more strongly, there does not exist an URL which would be a correct resolution of 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Mon Jun 14 16:44:18 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:13:03 2004 Subject: XMl - DTD and Table Definition Message-ID: <93CB64052F94D211BC5D0010A800133170EEEA@wwmess3.bra01.icl.co.uk> > I am in the area of XML! Now I have to export and import > large databases via XML-format. This data are structured in typical > master-detail relations (1 master have approximatly 15 to 25 details records, one > exportfile have 30000 - 500000 master elements). > If I write the details records like the standard XML format, shown in > serveral books and samples via www, I waste a lot of space > for Start-End-Tag's. To minimize the filesize, I decide to use the
> syntax. The "standard" format you refer to (presumably something like ShakespeareHamlet) is not a standard at all, it is merely a convention that many people use. If space is a concern (and with big databases it certainly is) there are several other approaches possible: 1. Compress the file using a standard compression utility. 2. Use shorter tags ( e.g. for ) 3. Identify columns by position rather than by name, for example: ShakespeareHamlet This is similar to using TABLE & TD as you suggest (but shorter). You need to think about how to represent null values, though: and if there are very many nulls, you can end up using more space than with the named columns approach. 4. If space is really tight you could even shorten the above to: ShakespeareHamlet (where the empty tag acts as a separator); but you're starting to make it more difficult to parse, eliminating the benefits of using XML in the first place. > Questions: > > Is this allowed in a "well-formed" XML document? Yes, you can use tags to mean anything you like so long as they are properly nested. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Mon Jun 14 17:26:07 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:13:03 2004 Subject: Looking for a tool Message-ID: <3.0.1.32.19990614112829.006979b8@tiac.net> Hey all, I'm looking for a command-line XML validator. Something I can use in my development process the way you'd use lint: % checkvalid mydoc.xml mydoc.xml:89: you messed this one up mydoc.xml:101: and this one Perl, C source, or windows binary would be fine. Any recommendations? -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Jun 14 17:49:03 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:03 2004 Subject: Server side DTD validation only ? References: <342957C6CEFFD211A63B0008C707C3C82337FC@hslnt98jax.homeloan.com> Message-ID: <376524BF.1E88E743@pacbell.net> "Roldan, Alex" wrote: > > To me It seems that performing DTD validation on the client and server side > is an unnecessary overhead. Currently, I am only performing validation > against the DTD on the server side app. The request and the response are > both validated by the server app by pre-pending the DTD to the XML document > before it is validated. The text XML data created by the client does not > contain the DTD or an external reference to the DTD. > > 1. Is this the right approach ? If you control both the client and server, and can keep them always in sync (e.g. you're downloading the client from that server) so that you don't run into versioning problems. >From my perspective, both of those restrictions are atypical. Of course you also have to keep in mind that validation is only one level of error checking, and it's possible that the other levels will catch the problems that'd crop up. > 2. What are the problems I can run into ? If you write clients for network programs, you learn that you must not trust servers to perform according to their specifications ... e.g. a server operated by a business competitor might very well attempt to subvert clients that are trusting. It is routine to check the format of data as it's being imported. (And vice versa -- when clients send data to servers, the servers shouldn't trust it, for the same reasons.) Hence the clause above "if you control both the client and server" -- two different companies shouldn't take that approach in their client/server code. Systems are also not static. They evolve over time. The rules for what is correct/valid change over time. If your clients have every reason to trust the servers (and vice versa) you can _still_ run into problems if it's possible for the protocol versions to be mismatched. Hence the clause above "and can keep them in sync". - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Jun 14 18:15:17 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:03 2004 Subject: Namespace URI address resources References: <3754EE1F.8498F9D1@isogen.com> Message-ID: <37652B06.C2F6C463@pacbell.net> "W. Eliot Kimber" wrote: > > Didier PH Martin wrote: > > > Didier says: > > Exactly. A URI represent something. It is a U_niform R_esource I_dentifier. > > It provides identitity to a resource. > > No, a URI does *not* provide identity to a resource--it *identifies* a resource, > but it does not provide identity for the resource. That is, given two different > URIs, you cannot know, from the URIs alone, whether they identify the same > resource or a different resource. True enough ... > Unless the URI *is* the resource, it does not establish identity of the resource > it addresses. Which is the case in XML namespaces, by reading from me and others. There is explicit language in the specification saying that "It is not a goal that it be directly usable for retrieval of a schema (if any exists)." Any resource identified by the URI doesn't matter at all. The only characteristics required of that URI are "uniqueness and persistence" ... NOT ability to actually retrieve a resource it may identify (largely disclaimed by the non-goal quoted above) or to be equated with some other URI for comparison purposes (which may be a fine idea but isn't required by the spec). > And note that identity can only be truly established at a specific point in > time. The same URI resolved at two different points in time may resolve to > provably different resources. That'd be true if the URI in namespaces were used for any purpose other than being a unique identifier. But it isn't; there's no (!!!) requirement that the URI point to anything, and any code that tries to associate the namespace with the results of resolving that URI is going beyond what the XML Namespace spec allows. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Mon Jun 14 18:19:56 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:13:03 2004 Subject: Server side DTD validation only ? In-Reply-To: <376524BF.1E88E743@pacbell.net> References: <342957C6CEFFD211A63B0008C707C3C82337FC@hslnt98jax.homeloan.com> Message-ID: <3.0.1.32.19990614122209.006f8b7c@mail.muzmo.com> The moral that I take from this exchange is: DTD validation can be exclusively server-side if the client has sufficient trust in the server, otherwise client-side validation is recommended. Please note that certain applications will want to have servers on both sides of an exchange, with the client communicating with a local server that may or may not perform validation of its own. Thus, a client's trust in a server can be mitigated by the presence of an intermediary server that performs pre-validation as a trusted service for the client. For example, in a telephony application, any switch along the path of a document exchange, from sender to recipient, can be responsible for validating along the way. So, the sender's server (a phone) might validate the message that it sends out, or it may restrict its messages to a canned set of messages that conform to an industry standard. As the message is received into the telephone network, and at any switch along the way, a validation service is free to test any message -- rejecting/returning any message that is not valid. The client's telephone service might have its own message processing service that checks incoming messages and performs functions on behalf of the client, and it may choose to validate. Before transmitting a message to the client, the telco's messaging service checks with the client and asks whether it wants the server to validate on its behalf. And when the client gets the message, a local validation service might be available for messages that have not been pre-validated -- for whatever reason. At 08:50 AM 6/14/99 -0700, David Brownell wrote: >"Roldan, Alex" wrote: >> >> To me It seems that performing DTD validation on the client and server side >> is an unnecessary overhead. Currently, I am only performing validation >> against the DTD on the server side app. The request and the response are >> both validated by the server app by pre-pending the DTD to the XML document >> before it is validated. The text XML data created by the client does not >> contain the DTD or an external reference to the DTD. >> >> 1. Is this the right approach ? > >If you control both the client and server, and can keep them >always in sync (e.g. you're downloading the client from that >server) so that you don't run into versioning problems. > >From my perspective, both of those restrictions are atypical. > >Of course you also have to keep in mind that validation is >only one level of error checking, and it's possible that the >other levels will catch the problems that'd crop up. > > >> 2. What are the problems I can run into ? > >If you write clients for network programs, you learn that >you must not trust servers to perform according to their >specifications ... e.g. a server operated by a business >competitor might very well attempt to subvert clients that >are trusting. It is routine to check the format of data >as it's being imported. (And vice versa -- when clients >send data to servers, the servers shouldn't trust it, for >the same reasons.) Hence the clause above "if you control >both the client and server" -- two different companies >shouldn't take that approach in their client/server code. > >Systems are also not static. They evolve over time. The >rules for what is correct/valid change over time. If your >clients have every reason to trust the servers (and vice >versa) you can _still_ run into problems if it's possible >for the protocol versions to be mismatched. Hence the >clause above "and can keep them in sync". > >- Dave > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > ---------------------------------------------------------- Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Web: http://www.muzmo.com Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Mon Jun 14 18:34:02 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:13:03 2004 Subject: Looking for a tool In-Reply-To: <3.0.1.32.19990614112829.006979b8@tiac.net> References: <3.0.1.32.19990614112829.006979b8@tiac.net> Message-ID: * Joshua E. Smith | | Hey all, I'm looking for a command-line XML validator. Something I | can use in my development process the way you'd use lint: | | % checkvalid mydoc.xml | mydoc.xml:89: you messed this one up | mydoc.xml:101: and this one RXP has a command-line interface that can validate (and is available as C source), xmlproc does the same (available for Python) and most of the validating Java parsers probably have this as well. You may also want to look at IBM's xml4c, although that is C++. See for URLs and more alternatives. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Mon Jun 14 18:37:44 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:13:03 2004 Subject: Namespace URI address resources In-Reply-To: <37652B06.C2F6C463@pacbell.net> References: <3754EE1F.8498F9D1@isogen.com> Message-ID: <3.0.1.32.19990614124020.006e937c@mail.muzmo.com> At 09:17 AM 6/14/99 -0700, David Brownell wrote: >That'd be true if the URI in namespaces were used for any purpose >other than being a unique identifier. But it isn't; there's no (!!!) >requirement that the URI point to anything, and any code that tries >to associate the namespace with the results of resolving that URI is >going beyond what the XML Namespace spec allows. Beyond Namespaces. Catchy title. Good idea. The 'Namespaces in XML' quite rightly limited itself to identifiers. There is nothing preventing another spec -- say XML Schema -- from leveraging namespace identifiers and adding mechanisms to allow resolution of associated resources, is there?. ---------------------------------------------------------- Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Web: http://www.muzmo.com Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Jun 14 18:59:34 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:03 2004 Subject: Top-down or bottom-up? References: <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> <14180.64662.493404.927680@localhost.localdomain> Message-ID: <3765355F.A0BC7097@pacbell.net> David Megginson wrote: > > In principle, I know that Paul is right; in practice, I've lost much > of the faith that I once had in top-down approaches to anything, from > system design to macroeconomics. Stop being reasonable, David ... it really doesn't go with the political climate anywhere nowadays!! ;-) All the same, I agree. True innovation rarely comes from the top down. The history of technology shows it conclusively. It's the sociology of things -- the incentives need to go to the right people, and when innovation is the game, people at the "top" of the heap usually can't even see the problems that need those innovations (and often can't risk letting them get fixed, if they can see them). What's interesting is the cycles that show up. Bottom-up phases get followed by top-down ones, get followed by bottom-up ones again. IP networking grew bottom up, but nowadays there are lots of top-down network management tools that are essential (when they work :-) as well as small networks and ISPs. Personal computers are now driven by corporate buyers, not hackers. Operating systems for PCs started as bottom up, have had a detour through a top-down monopoly, and now there's again a growing interest in more grass-roots efforts such as Linux ... which curiously enough are now harnessing quite a lot of "top down" work done over the last few decades! Top-down approaches work when the problems are relatively stable; but things like the web are changing way too fast for that. Bottom-up ones work to harness innovation, in terms both of technologies (e.g. new web technologies) and business models (e.g. open source). - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Jun 14 19:30:27 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:03 2004 Subject: Namespace URI address resources References: <3754EE1F.8498F9D1@isogen.com> <3.0.1.32.19990614124020.006e937c@mail.muzmo.com> Message-ID: <37653CA6.E9913FF@pacbell.net> Murray Maloney wrote: > > At 09:17 AM 6/14/99 -0700, David Brownell wrote: > >That'd be true if the URI in namespaces were used for any purpose > >other than being a unique identifier. But it isn't; there's no (!!!) > >requirement that the URI point to anything, and any code that tries > >to associate the namespace with the results of resolving that URI is > >going beyond what the XML Namespace spec allows. > > Beyond Namespaces. Catchy title. Good idea. Necessary! The namespaces spec solves only one of the many problems that need solving ... ;-) > The 'Namespaces in XML' quite rightly limited itself to identifiers. > > There is nothing preventing another spec -- say XML Schema -- from > leveraging namespace identifiers and adding mechanisms to allow > resolution of associated resources, is there?. Subject to some constraints -- nothing prevents that. For example it'd be fine for one schema system to be able to to a say which namespace identifiers point to additional information ... but it'd be wrong (conflicting with the namespace spec!) to do so for any namespaces that's not explicitly declared to work that way. Example: ... ... The semantics of the "URI-2" namespace URI would define what that "schema" element, and its "fetch-from" attribute, means. It could declare that its "fetch-from" attribute value (URI-1 in this example) associates resources withsome namespace URI. But that wouldn't apply in the case of URI-3, unless the URI-1 schema declared that's how the URI-3 namespace worked. Yes, I'm assuming a multiplicity of schema systems ... and even that many schemas would allow for mixing content they don't control. I think both are inevitable/essential. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at w3.org Mon Jun 14 19:35:18 1999 From: chris at w3.org (Chris Lilley) Date: Mon Jun 7 17:13:03 2004 Subject: W3C (was Re: XSL Debate, Leventhal responds to Stephen Deach) References: <199906111603.MAA29611@hesketh.net> <199906111552.LAA28839@hesketh.net> <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111614.MAA30348@hesketh.net> Message-ID: <37653BA9.D10C0A6A@w3.org> "Simon St.Laurent" wrote: > No, I'm not asking to be made an expert, and no, I'm not interested in > joining a W3C member organization to get access. I'm hoping that someday > the W3C will find an endowment or some other means of supporting itself so > it can drop this $5000+/year charade that keeps the smoke-filled rooms > closed to small firms and individuals. Well, if someone has a whole heap of money going, that would be great. In the mean time, well, wages have to be paid somehow. > I'll remain an outsider until the > W3C gets rid of the rules that separate insiders and outsiders. Bear in mind that, even for members, not everyone gets to play. Working groups are serious things, with deadlines and dependencies on each other. So, to join a particular working group, a member has to officially allocate time for the designated participant - typically 20% of a full time equivalent each - and attendance at weekly hour-long telcons, and travel and time for quarterly or bimonthly face to face meetings somewhere on the planet. That cost would not go away, even if everyone could become a member. > In the meantime, I'll have to put up with the organization and hope that it > takes its mission as seriously as its membership. The seriousness of the mission determines the need to have paid staff who work full time on this; volunteer labour is all very well but has inherent limitations. Yes, I would like to be able to bring in more people and yes, I know that there are problems for very small companies, individual consultants, and so on. Currently I don't see a viable alternative economic setup, though. And I do see good work being done and a positive benefit being made to the Web. Otherwise, well, I would go work someplace else. -- Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Jun 14 19:39:53 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:13:03 2004 Subject: Namespace URI address resources Message-ID: <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> At 12:40 PM 6/14/99 -0400, Murray Maloney wrote: >There is nothing preventing another spec -- say XML Schema -- from >leveraging namespace identifiers and adding mechanisms to allow >resolution of associated resources, is there?. Yes. I think it would be completely inadmissable for XML schemas to try to claim ownership of the resource at the end of the namespace URI. (Note that RDF kind of does so, which is a grievous error). Here's why. A schema is an interesting external resource that you often need to aid in processing an XML resource. But it's just one of them. You also sometimes need - a stylesheet - more stylesheets (because of cascading, or because you only believe in one of the stylesheet religions) - some related java classes - some related COM objects - a DTD - a set of documents involved in an extended hyperlink group - a topic map - some graphics - some other multimedia resources - etc etc etc etc None of these are more important than all the rest, and none of them has the right to pirate the namespace URI. It is becoming painfully obvious that we need a general-purpose packaging mechanism to deliver an arbitrary number of related whatevers along with a piece of XML payload. There has been a lot of discussion about this around the W3C. It may be the case that multipart-mime provides a general solution for this problem (don't understand it well enough myself to have an opinion), or perhaps we need an XML Packaging Language to use for this purpose. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Mon Jun 14 19:44:57 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:13:03 2004 Subject: W3C (was Re: XSL Debate, Leventhal responds to Stephen Deach) In-Reply-To: <37653BA9.D10C0A6A@w3.org> References: <199906111603.MAA29611@hesketh.net> <199906111552.LAA28839@hesketh.net> <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111614.MAA30348@hesketh.net> Message-ID: At 07:28 PM 6/14/99 +0200, Chris Lilley wrote: >So, to join a particular working group, a member has to >officially allocate time for the designated participant - typically 20% >of a full time equivalent each - and attendance at weekly hour-long >telcons, and travel and time for quarterly or bimonthly face to face >meetings somewhere on the planet. That cost would not go away, even if >everyone could become a member. And that's a good point to remember. The annual membership fees are just a small portion of the cost to HWG (and other member companies) of participating in W3C activities. For less costly involvement, there are a variety of interest groups which individuals can participate in only via email and/or at other limited cost. Best... Ann --- Author of Effective Web Design: Master the Essentials Buy it Online - http://www.webgeek.com/about.html Coming this summer! --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 14 20:19:55 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:03 2004 Subject: Packaging and hub documents In-Reply-To: <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> References: <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> Message-ID: <14181.18060.445731.712967@localhost.localdomain> Tim Bray writes: > It is becoming painfully obvious that we need a general-purpose > packaging mechanism to deliver an arbitrary number of related > whatevers along with a piece of XML payload. There has been a lot > of discussion about this around the W3C. It may be the case that > multipart-mime provides a general solution for this problem (don't > understand it well enough myself to have an opinion), or perhaps > we need an XML Packaging Language to use for this purpose. -Tim To start with, we need a hub document -- RDF would do: A client could download the hub first, then decide what else it needs. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken_north at csi.com Mon Jun 14 20:22:41 1999 From: ken_north at csi.com (Ken North) Date: Mon Jun 7 17:13:04 2004 Subject: Prior art: using metadata over a communications link Message-ID: <008001beb692$bdf23480$0500a8c0@platinum> << The W3C is surveying potential prior art to assess the claims of Patent Number: 5862325. << they rely on the exchange between publishers and subscribers of a file containing metadata (such as an XML file) to set up an active communications link. In PRACTICAL SGML (Kluwer Academic Publishers, 1990), Eric van Herwijnen discusses SGML for Electronic Data Interchange (EDI). In Chapter 13, he discusses EDIFACT and includes a DTD for a standard commercial invoice. The chapter 13 bibliography includes the following paper: B. Robinson, G. Wu, and K. Jeffery. Using SGML for the exchange of the RG2 grant application form. SERC, 1989. ================== Ken North ============================= http://ourworld.compuserve.com/homepages/Ken_North ken_north@csi.com 71301.1306@compuserve.com KenNorth@msn.com Ken North Computing 2604B El Camino Real, #351 Carlsbad, CA 92008 =========================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Mon Jun 14 20:24:18 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:13:04 2004 Subject: Namespace URI address resources In-Reply-To: <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990614142500.01859260@mail.muzmo.com> At 10:42 AM 6/14/99 -0700, Tim Bray wrote: >At 12:40 PM 6/14/99 -0400, Murray Maloney wrote: >>There is nothing preventing another spec -- say XML Schema -- from >>leveraging namespace identifiers and adding mechanisms to allow >>resolution of associated resources, is there?. > >Yes. I think it would be completely inadmissable for XML schemas to >try to claim ownership of the resource at the end of the namespace URI. >(Note that RDF kind of does so, which is a grievous error). I think that you may have misunderstood me, so let me try again. I am not suggesting that XML Schema *claim* ownership. I am suggesting that a schema-aware processor is allowed to resolve the URI to an XML Schema, if possible, and use that schema to inform its processing. ... If there is an XML Schema at www.muzmo.com and there isn;t one at w3c, then a namespace-aware processor will work just fine on this document. An XML Schema-aware processor could, additionally, use the schema to validate the document, notwithstanding that is not known to the schema at www.muzmo.com, or even that there is no schema available by resolving the w3.org URI. >Here's why. A schema is an interesting external resource that you >often need to aid in processing an XML resource. But it's just one >of them. You also sometimes need > - a DTD > - stylesheet(s) > - some related java classes or COM objects > - a set of documents involved in an extended hyperlink group > - a topic map > - some graphics > - some other multimedia resources >None of these are more important than all the rest, and none of them >has the right to pirate the namespace URI. Again, I am not talking about claiming ownership. But if I choose to use URIs that resolve to an XML Schema, then a schema-aware processor cannot be forbidden from taking advantage of that. I guess that that would make it fair game for any processor to resolve the URI and test whether or not it returns a document that is interesting to it. It is interesting that some, but not all, of the external resources that you listed share the characteristic of defining 'names' and thus 'namespaces'. The DTD can, of course, be included in the internal or external subset. Other resource types listed above seem unlikely candidates for namespace URIs. For example, while it is certainly legal, it would probably be a bad idea to use the URL that actually resolves to a GIF file. > >It is becoming painfully obvious that we need a general-purpose >packaging mechanism to deliver an arbitrary number of related >whatevers along with a piece of XML payload. There has been a lot >of discussion about this around the W3C. It may be the case that >multipart-mime provides a general solution for this problem (don't >understand it well enough myself to have an opinion), or perhaps >we need an XML Packaging Language to use for this purpose. -Tim > Yes, that is almost certainly true. And, perhaps XML Schemas can leverage the namespaces spec. ---------------------------------------------------------- Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Web: http://www.muzmo.com Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jonsmirl at mediaone.net Mon Jun 14 20:25:54 1999 From: jonsmirl at mediaone.net (Jon Smirl) Date: Mon Jun 7 17:13:04 2004 Subject: W3C (was Re: XSL Debate, Leventhal responds to Stephen Deach) References: <199906111603.MAA29611@hesketh.net> <199906111552.LAA28839@hesketh.net> <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111614.MAA30348@hesketh.net> <37653BA9.D10C0A6A@w3.org> Message-ID: <006401beb693$94939420$0201a8c0@ne.mediaone.net> From: Chris Lilley > > Yes, I would like to be able to bring in more people and yes, I know > that there are problems for very small companies, individual > consultants, and so on. Currently I don't see a viable alternative > economic setup, though. > I'm not interested in joining a working group, but I would like to follow the design discussions of the working groups. For example Netscape is doing this via their public newsgroups. Right now I am working on an XML based query language. I'm doing this work in the dark because the last feedback out of the W3C was this page from Nov 15. http://www.w3.org/TandS/QL/QL98/ Why can't we have read-only access to the discussion group archive at http://lists.w3.org/Archives/Member/w3c-ql/? This would allow me to keep my code somewhat in alignment with the thoughts of the W3C. Without this access my code is likely to be completely different that the first W3C draft. And when the draft arrives I may choose to ignore it because it will be too much work to bring my code into alignment. Is this really what the W3C is trying to achieve? Jon Smirl jonsmirl@mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Mon Jun 14 20:42:47 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:13:04 2004 Subject: Namespace URI address resources Message-ID: <3.0.32.19990614144429.0080b9f0@polaris.net> At 10:42 AM 6/14/1999 -0700, Tim Bray wrote: >It is becoming painfully obvious that we need a general-purpose >packaging mechanism to deliver an arbitrary number of related >whatevers along with a piece of XML payload. There has been a lot >of discussion about this around the W3C. It may be the case that >multipart-mime provides a general solution for this problem (don't >understand it well enough myself to have an opinion), or perhaps >we need an XML Packaging Language to use for this purpose. -Tim I've been wondering about this. Granted the XLink spec still hasn't calmed down, but this kind of problem seems (to me) to be a good fit for an extended link group solution. And (not that you suggested this) it doesn't seem to be something that requires the mandate of a WG, but rather can be a de-facto informal solution a la SAX(2). Would that work, you think? ============================================================= John E. Simpson | It's no disgrace t'be poor, simpson@polaris.net | but it might as well be. | -- "Kin" Hubbard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Mon Jun 14 20:42:10 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:13:04 2004 Subject: Packaging and hub documents Message-ID: <01BEB6A6.6AC58AF0@grappa.ito.tu-darmstadt.de> David Megginson writes: > Tim Bray writes: > > > It is becoming painfully obvious that we need a general-purpose > > packaging mechanism to deliver an arbitrary number of related > > whatevers along with a piece of XML payload. There has been a lot > > of discussion about this around the W3C. It may be the case that > > multipart-mime provides a general solution for this problem (don't > > understand it well enough myself to have an opinion), or perhaps > > we need an XML Packaging Language to use for this purpose. -Tim > > To start with, we need a hub document -- RDF would do: > > [example snipped] > > A client could download the hub first, then decide what else it needs. You might also look at Simon St. Laurent's XML Processing Description Language (XPDL): http://www.simonstl.com/projects/xpdl/wd052599.html It doesn't do everything Tim mentions, but it's a start. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Mon Jun 14 20:45:05 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:13:04 2004 Subject: W3C (was Re: XSL Debate, Leventhal responds to Stephen Deach) In-Reply-To: <006401beb693$94939420$0201a8c0@ne.mediaone.net> Message-ID: On Mon, 14 Jun 1999, Jon Smirl wrote: > Right now I am working on an XML based query language. I'm doing this work > in the dark because the last feedback out of the W3C was this page from Nov > 15. http://www.w3.org/TandS/QL/QL98/ > > Why can't we have read-only access to the discussion group archive at > http://lists.w3.org/Archives/Member/w3c-ql/? This would allow me to keep my > code somewhat in alignment with the thoughts of the W3C. > > Without this access my code is likely to be completely different that the > first W3C draft. And when the draft arrives I may choose to ignore it > because it will be too much work to bring my code into alignment. Is this > really what the W3C is trying to achieve? Here's a leak from behind the iron curtain: don't imagine that everything of interest is happening there. The w3c-ql list, for example, had a flurry of interest after the QL'98 meeting then pretty much dried up since february/march. You're not missing much there... XML-DEV has been far more interesting on the query front in last few months. And rdf-mozilla... (again, public). A lot of the XML folks with W3C-access, for example, make a habit of talking on XML-DEV instead of the Member-only lists. Of course plenty goes on behind /Member/ but (when you don't have access!) it's easy to convince yourself you're missing more than you actually are. Dan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Jun 14 20:53:58 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:13:04 2004 Subject: Namespace URI address resources Message-ID: <3.0.32.19990614115508.0233f190@pop.intergate.bc.ca> At 02:25 PM 6/14/99 -0400, Murray Maloney wrote: >I think that you may have misunderstood me, so let me try again. >I am not suggesting that XML Schema *claim* ownership. > >I am suggesting that a schema-aware processor is allowed to resolve >the URI to an XML Schema, if possible, and use that schema to >inform its processing. I think I understand. And I still think that's a really bad idea, since there are so many other kinds of facilities that might plausibly want to resolve that URL to get something, and I don't think it's useful to create an environment where different types of things are competing for the use of that resource. In an ideal world, one might imagine that content-negotiation could be helpful here - i.e. do a get on the URI and say that you only accept text/xml-sox or some such... but I'm not convinced that media-types are up to handling this job. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Jun 14 20:53:59 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:13:04 2004 Subject: Packaging and hub documents Message-ID: <3.0.32.19990614115134.0233f940@pop.intergate.bc.ca> At 02:21 PM 6/14/99 -0400, David Megginson wrote: >To start with, we need a hub document -- RDF would do: ... >A client could download the hub first, then decide what else it needs. Or it might be nice to be able to get to the hub from the document. Also, in some cases you might want to inline some of the resources into the hub doc so it all arrives as one package. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmcdonou at library.berkeley.edu Mon Jun 14 21:00:28 1999 From: jmcdonou at library.berkeley.edu (Jerome McDonough) Date: Mon Jun 7 17:13:04 2004 Subject: Packaging and hub documents In-Reply-To: <14181.18060.445731.712967@localhost.localdomain> References: <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> Message-ID: <3.0.5.32.19990614120102.01428720@library.berkeley.edu> At 02:21 PM 6/14/1999 -0400, David Megginson wrote: >Tim Bray writes: > > > It is becoming painfully obvious that we need a general-purpose > > packaging mechanism to deliver an arbitrary number of related > > whatevers along with a piece of XML payload. There has been a lot > > of discussion about this around the W3C. It may be the case that > > multipart-mime provides a general solution for this problem (don't > > understand it well enough myself to have an opinion), or perhaps > > we need an XML Packaging Language to use for this purpose. -Tim > >To start with, we need a hub document -- RDF would do: > We are developing something quite like this for a research project at Berkeley (including using a XML hub document), and have been considering whether it's something that we should start trying to get more feedback on and move towards some kind of standards track. The hub describes a hierarchical structure for a document object, and then allows you to associate different digital manifestations (e.g., page images, locations in an SGML transcription file) with nodes in the structural description, and also associate administrative metadata (IP rights, source/provenance, etc.) with the individual manifestations. As the work is mainly oriented towards supporting the library/archival worlds' needs to disseminate digitized primary resources, it may not exactly fit the bill for what you're describing, but you can feel free to have a look and make suggestions. Information on the full project is available at: http://sunsite.berkeley.edu/moa2/ Look in particular at the information in the MOA2 Document Type Definition section, including the brief tutorial and DTD. (The DTD on the web site is not the most recent version, but it's not all that different from the current one). Jerome McDonough -- jmcdonou@library.Berkeley.EDU | (......) Library Systems Office, 386 Doe, U.C. Berkeley | \ * * / Berkeley, CA 94720-6000 (510) 642-5168 | \ <> / "Well, it looks easy enough...." | \ -- / SGNORMPF!!! -- From the Famous Last Words file | |||| xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Mon Jun 14 21:08:47 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:13:04 2004 Subject: Namespace URI address resources In-Reply-To: <3.0.32.19990614115508.0233f190@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990614150507.00701cb4@mail.muzmo.com> At 11:55 AM 6/14/99 -0700, Tim Bray wrote: >At 02:25 PM 6/14/99 -0400, Murray Maloney wrote: >>I think that you may have misunderstood me, so let me try again. >>I am not suggesting that XML Schema *claim* ownership. >> >>I am suggesting that a schema-aware processor is allowed to resolve >>the URI to an XML Schema, if possible, and use that schema to >>inform its processing. > >I think I understand. And I still think that's a really bad idea, >... OK, so we disagree. ---------------------------------------------------------- Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Web: http://www.muzmo.com Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Mon Jun 14 21:31:58 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:13:04 2004 Subject: Namespace URI address resources Message-ID: <01BEB6AD.60A24FC0@grappa.ito.tu-darmstadt.de> Murray Maloney wrote: > OK, so we disagree. Actually, quite a few people disagree with using the namespace URI to retrieve the schema, as recent discussions have shown. Unfortunately, although we've assembled a mass of discomfort, none of us has come up with what I would consider an absolute killer technical argument -- that is, one that proves beyond a shadow of a doubt that it won't work. Perhaps we could turn the tables :) and ask, why is it so important to use the namespace URI to retrieve the schema instead of something else, such as a PI, a special attribute, or the aforementioned hub document? -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From chris at webcriteria.com Mon Jun 14 21:34:27 1999 From: chris at webcriteria.com (Chris Tilt) Date: Mon Jun 7 17:13:05 2004 Subject: Namespace URI address resources References: <3.0.32.19990614115508.0233f190@pop.intergate.bc.ca> Message-ID: <3765585E.63F83713@webcriteria.com> We built a resolver that worked exactly like this, which returned a manifested resource based on the accept field from the client. It worked pretty well by placing the mime types in order of most to least desired. The client got back a URL, or a URL list (depending on the request) and could select one of them to fetch. This was built for a content management system that handled many kinds of media including broadcast video, audio, and multiple document types. It worked quite well; the hardest problem was getting the java classes to allow setting of the "accept" field! Cheers, Chris Tim Bray wrote: > > At 02:25 PM 6/14/99 -0400, Murray Maloney wrote: >[deleted] > >I am suggesting that a schema-aware processor is allowed to resolve > >the URI to an XML Schema, if possible, and use that schema to > >inform its processing. > [deleted] > In an ideal world, one might imagine that content-negotiation could > be helpful here - i.e. do a get on the URI and say that you only > accept text/xml-sox or some such... but I'm not convinced that media-types > are up to handling this job. -Tim > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dent at oofile.com.au Mon Jun 14 22:39:55 1999 From: dent at oofile.com.au (Andy Dent) Date: Mon Jun 7 17:13:05 2004 Subject: Packaging and hub documents In-Reply-To: <14181.18060.445731.712967@localhost.localdomain> References: <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> <14181.18060.445731.712967@localhost.localdomain> Message-ID: At 14:21 -0400 14/6/99, David Megginson wrote: >Tim Bray writes: > > > It is becoming painfully obvious that we need a general-purpose > > packaging mechanism to deliver an arbitrary number of related > > whatevers along with a piece of XML payload. I just want to contribute a non-web example that's a real-world example about to be used by thousands of teachers in the next year. It's an extension of our report-writer technology being shipped in a client application. The OOFILE report writer now has the ability to save a report to a single desktop document and retrieve it for later viewing, printing and (about to be released) editing of content. A report document includes the report layout description as well as all the data included in the report. Issues included: - packaging multiple reports - multiple stylesheets - multiple locally scoped database schema (like many others our RW allows you to combine many reports into one master report, viewable and printable as a single report but with unique page streams) - embedding stylesheets (we handle style and layout in separate areas) - embedding schema (mild extension of the current WG being used) - embedding graphics (not actually shipping yet as the immediate client didn't need it but we will use base64 encoding of blob field types) Wrapping this in multi-part MIME would have complicated the parsing considerably. Using expatpp and the sub-parser model in particular made it fairly straightforward to parse. http://www.highway1.com.au/adsoftware/expatpp.html for the expatpp parser (c++ extension of expat) Samples of report output available at Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows PP2MFC - PowerPlant->MFC portability http://www.oofile.com.au/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jun 14 23:00:56 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:05 2004 Subject: Namespace URI address resources In-Reply-To: <01BEB6AD.60A24FC0@grappa.ito.tu-darmstadt.de> References: <01BEB6AD.60A24FC0@grappa.ito.tu-darmstadt.de> Message-ID: <14181.27655.665422.837540@localhost.localdomain> Ronald Bourret writes: > Actually, quite a few people disagree with using the namespace URI > to retrieve the schema, as recent discussions have > shown. Unfortunately, although we've assembled a mass of > discomfort, none of us has come up with what I would consider an > absolute killer technical argument -- that is, one that proves > beyond a shadow of a doubt that it won't work. Tim Bray has already posted the killer argument -- if we accept that there's a n:n relationship among namespaces and schemas (etc.) that you might want to apply to things from those namespaces, then you cannot model that as a 1:1 association. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jonsmirl at mediaone.net Tue Jun 15 00:07:18 1999 From: jonsmirl at mediaone.net (Jon Smirl) Date: Mon Jun 7 17:13:05 2004 Subject: Packaging and hub documents References: <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> <14181.18060.445731.712967@localhost.localdomain> Message-ID: <018901beb6b2$925795c0$0201a8c0@ne.mediaone.net> Why not start with the HTML enabled email RFC? It already specifies how to encode the message with MIME so that binary data can be attached. It also specifies how to do relative URLs into the MIME package. MIME brings along a lot of good things like encryption and compression. The HTML email group originally had a hub/catalog document and decided it wasn't really needed. Plus it was hard to generate in some cases. Jon Smirl jonsmirl@mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Tue Jun 15 01:25:32 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:05 2004 Subject: Namespace URI address resources References: <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> Message-ID: <37658FEC.DA13BB55@pacbell.net> Tim Bray wrote: > > - a stylesheet > - more stylesheets (because of cascading, or because you only > believe in one of the stylesheet religions) > - some related java classes > - some related COM objects > - a DTD > - a set of documents involved in an extended hyperlink group > - a topic map > - some graphics > - some other multimedia resources > - etc etc etc etc Me, I go for the "etc"! Most of those should be overridable ... in an E-Commerce system, there may be a default stylesheet for a purchase order issued by someone else, but my company may prefer to present it differently. And similarly the default classes may be oriented towards purchasers, rather than suppliers -- and if I work for a supplier, the default classes would do the wrong thing. (Touches on the workflow issues someone brought up a while back. Everyone in a workflow system may work with the same data differently.) > It is becoming painfully obvious that we need a general-purpose > packaging mechanism to deliver an arbitrary number of related > whatevers along with a piece of XML payload. There are plenty of such mechanisms around. But tools using any of them seem lacking. > There has been a lot > of discussion about this around the W3C. It may be the case that > multipart-mime provides a general solution for this problem (don't > understand it well enough myself to have an opinion), or perhaps > we need an XML Packaging Language to use for this purpose. -Tim The multipart-related MIME type (RFC 2387) sure seems like it ought to work, at least for cases where one can rely on a single MIME object to do the job, like HTTP or E-Mail. ftp://ftp.isi.edu/in-notes/rfc2387.txt Multipart-related documents basically let you send a bunch of data as parts of a MIME object and refer to them internally; you might have the first part ... and the second part would be "foo.dtd". Similarly for other resources identified by URI. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Tue Jun 15 01:36:58 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:05 2004 Subject: Namespace URI address resources References: <01BEB6AD.60A24FC0@grappa.ito.tu-darmstadt.de> Message-ID: <3765929D.4392C4D2@pacbell.net> Ronald Bourret wrote: > > Murray Maloney wrote: > > > OK, so we disagree. > > Actually, quite a few people disagree with using the namespace URI to > retrieve the schema, as recent discussions have shown. Unfortunately, > although we've assembled a mass of discomfort, none of us has come up with > what I would consider an absolute killer technical argument -- that is, one > that proves beyond a shadow of a doubt that it won't work. I think Tim came closest ... but I think that there can be no such "killer" argument, unless it's against the strawman argument that the namespace URI suffices for everything (except poverty, war...). Why? Because that there are simple conventions one can adopt to address such issues. For example, the "Z" schema system could by default resolve a specified URI (defaulting to the relative "z-schema.xml") against the namespace URI. Similarly for any other data that may be desired. Given such an approach, which provides a structure for defaults yet allows them to be overridden, there's no reason the namespace URI can't be one factor used to retrieve schemas and other data. > Perhaps we could > turn the tables :) and ask, why is it so important to use the namespace URI > to retrieve the schema instead of something else, such as a PI, a special > attribute, or the aforementioned hub document? It's a good question. My suspicion is since that it's a lot less error prone to have _one_ place with the default definitions which tie a complex set of interrelated policies together, people think that's naturally the role the _one_ URI for a namespace should take. But again, that one place doesn't need to be the namespace URI; it's just that it is already defined, seems handy, hasn't clearly been placed off-limits ... and no other such place has been defined. I'd probably build on some other sort of integration solution which took advantage of namespaces (like XSL stylesheets -- CSS doesn't!) but used namespace URIs as seemingly designed: for unique tokens. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Tue Jun 15 01:56:11 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:13:05 2004 Subject: Namespace URI address resources Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF724@RED-MSG-08> Indeed, namespaces and schemas are distinct concepts. For example, RDF defines a namespace containing among other things all the natural numbers (1, 2, 3 etc.). This is clearly not a schema. However, that does not preclude having certain namespaces that are identified by a schema, meaning that every item in the namespace is in the schema and that the schema exactly declares the list of items in the 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jun 15 06:16:26 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:13:05 2004 Subject: Packaging and hub documents Message-ID: <004501beb6de$3a5d2390$4ff96d8c@NT.JELLIFFE.COM.AU> From: David Megginson >To start with, we need a hub document -- RDF would do: I floated a proposal for this a month ago: see http://www.ascc.net/~ricko/drlove.htm "DrLove: Document Resource Locations (On Valid Elements)". A general purpose mechanism would be so useful for many kinds of bundling: it would allow a Macitosh like resource fork (Mac files are divided into two parts: data and resource forks). This would allow bundling of icons and many other neat things. There are many things that belong to processing documents, but perhaps not the document itself: hyphenation dictionaries, etc. It would be best to be able to download these on demand, not all at once. (RDF or XLink could be used. DrLove uses RDF like Dave's suggestion.) There are a couple of internationalization issues that are not really solvable without such a mechanism (in particular, representation of non-standard or newly-standardized characters). Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jun 15 06:34:15 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:05 2004 Subject: Top-down or bottom-up? References: <199906111513.LAA27001@hesketh.net> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> <14180.64662.493404.927680@localhost.localdomain> Message-ID: <3765B35D.EF0886F9@prescod.net> David Megginson wrote: > > More specifically, top-down can work only with very, very good models, > and even I (who am known to shoot my mouth off) would not go so far as > to claim that I can produce a sufficiently accurate and complete model > of the Web over the next five years; in the absence of such a model, > bottom-up development and the free market of ideas is the only > reasonable choice, messy as it may be. I don't think I can produce *the* data model that will be used over the Web for the next five years. I think that I can produce *a* data model that would be demonstrably better than the complete lack of such. The existence of the quasi-standardized "ESIS" model did not interfere with the later creation of the much more powerful "grove" model any more than the existence of HTML somehow prevented the later invention of XML. You can change your mind in data models just as you can in language syntaxes. There is no threshhold you cross and can never cross back. In fact, I have long believed that data models and syntaxes work beautifully together because a standardized syntax allows you to shift around your data model without breaking some things (i.e. communication lines) and a standardized data model allows you to shift around your syntax without breaking other things (i.e back-end processing). standardized-data-models-are-about-the-freedom-to-change-your-mind 'ly yrs, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jun 15 06:43:56 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:13:05 2004 Subject: Namespace URI address resources Message-ID: <007301beb6e2$00f939f0$4ff96d8c@NT.JELLIFFE.COM.AU> From: Ronald Bourret >Murray Maloney wrote: > >> OK, so we disagree. > >Actually, quite a few people disagree with using the namespace URI to >retrieve the schema, as recent discussions have shown. Unfortunately, >although we've assembled a mass of discomfort, none of us has come up with >what I would consider an absolute killer technical argument -- that is, one >that proves beyond a shadow of a doubt that it won't work. I don't think "it won't work" is a good enough criterion. There are many things that work that have undesirable ramifications: works. Of course namespace URLs can point to anything: namespaces do not use the resource. But forcing the namespace URL point to a schema has bad side effects. This is what my online article "How to Promote Organic Plurality on the WWW" is about. See http://www.ascc.net/xml/en/utf-8/monolith.html My argument is that the WWW has succeeded because it (networking, TCP/IP, HTTP/MIME) is based on allowing plurality and organic development (i.e., market forces in a non-monetary market). It is not enough to have layers, there also needs to be a mechanism preceding each layer to allow alternatives. This view is supports Tim's argument. It is OK if some namespace URLs point to schemas. But it is not OK for any system to take over the namespace declaration and make it serve as a schema declaration. The namespace declarations should mean what the spec says and nothing more. Dave Brownell's post was good on this. Murray is not saying "Why can't the URL resource be a schema?" but "Why cannot we overload the namespace declaration to be the XML schema declaration?". * The first reason is because we need to support plurality, so any overloading should allow a multuplicity of content-negotiated schemas not just XML Schemas; * the second reason is because such overloading should be at best considered a defaulting mechanism in the absense of a specific schema declaration, and there is as yet no specific declaration mechanism for schemas; * the third reason is because it you then need markup to say "the namespace mechanism is overloaded" which then in effect makes namespaces not universal names but names-in-a-particular-schema-in-a-particular-schema-language; * the fourth reason is given in the note mentioned: it goes against the way other parts of the WWW have been designed and works against the public interest: it allows "data kidnap" and "workflow kidnap". Rick Jelliffe Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gkholman at CraneSoftwrights.com Tue Jun 15 09:14:56 1999 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Mon Jun 7 17:13:05 2004 Subject: XML Document to ascii text file In-Reply-To: References: <01BEB1AC.718315A0@cc398234-a.etntwn1.nj.home.com> Message-ID: At 99/06/08 14:17 -0400, Didier PH Martin wrote: >Can you explain how with just a simple example. Let's say the XML document >is: > > > > This is the title > > >One upon a time... > > >How would you transform this XML document above into a plain asci text? Can >you show it with a XSL script? A set of "plain ASCII text" semantics has been implemented in XT under the namespace URI "java:com.jclark.xsl.sax.NXMLOutputHandler". Using this set of semantics I have created XSL scripts that generate MSDOS batch files and other text files. These semantics provide for emitting characters such as "&" and "<" in a clear form (very helpful when writing batch files with input redirection). It also gives control over the emitted character encoding so that single-character accented letters can be output without having them be two-character UTF-8 encodings. For these reasons, I feel James' NXML meets a need not met just by using a text subset of an output XML file. For example, using your document above I have a session below that attempts to illustrate what can be done. James has some documentation in his http://www.jclark.com/xml/xt.html file. It happens this is also covered briefly with another example in a chapter of my XSL training material included in my free preview excerpt (the first three chapters) available from our web site ... it is a free excerpt of: Introduction to XSLT (XSL Transformations) Third Edition - 1999-06-08 - ISBN 1-894049-00-4 Copyright (C) 1999 Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ 205 Pages / $40.00 US dollars / Includes free updates I have received requests to add more detail to the documentation for this non-XML (NXML) environment, so that will be made available in a future edition (all future editions are available at no charge to all existing customers). I hope this helps. .............. Ken T:\didier>type test.xml This is the title One upon a time... T:\didier>type test.xsl TITLE T:\didier>call xsl test.xml test.xsl test.txt T:\didier>type test.txt <<>> This is the title One upon a time... T:\didier> -- G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995) Website: XSL/XML/DSSSL/SGML services outline, XSL/DSSSL shareware, stylesheet resource library, conference training schedule, commercial stylesheet training materials, on-line XSL CBT. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Tue Jun 15 10:38:13 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:13:05 2004 Subject: ANN: SAXON 4.3 (XSL interpreter and compiler) Message-ID: <93CB64052F94D211BC5D0010A800133170EEF3@wwmess3.bra01.icl.co.uk> SAXON 4.3 is available for download on http://home.iclweb.com/icl2/mhkay/saxon.html The new version has been upgraded so both the XSL interpreter and compiler now conform (very nearly) to the April 21 W3C XSLT specification. I tried this time to concentrate on conforming to the spec and avoiding the temptation to innovate, but in the end I couldn't resist adding an assignment statement for variables and a while loop. To the functional programming enthusiasts, I apologise (you don't have to use them); to everyone else, I hope it will make your life a little easier. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Tue Jun 15 13:53:12 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:05 2004 Subject: Top-down or bottom-up? References: <199906111513.LAA27001@hesketh.net> <E10sSdc-0001iC-00@romeo.ic.ac.uk> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> <14180.64662.493404.927680@localhost.localdomain> Message-ID: <3765C618.B2C79D23@prescod.net> David Megginson wrote: > > Remember the big experiments in top-down, centralized economic > planning in the 1960s, '70s, and '80s? Our grandchildren may still be > paying off the debts from that one. Before I am further labelled a communist or Reaganomicist I want to point out that I didn't mean to imply that the rule of thumb for all development should always be "design everything first and then implement everything when every detail has been figured out." You have to bring design in at some point and Simon and I have both (separately) pointed out that the W3C tends much more often to bring it in much later than it should. I'm not confident about his complaint about formatting models because I seem to remember a "joint commission" on the W3C formatting model being developed a long time ago. The problem in that case may be more W3C secrecy instead of W3C disorganization. I do know what my own complaint is though: Various Web specifications allow you to talk to "things" and to associate properties with "things." None of them define "thing." Therefore it is completely unclear what things we are talking about and associating properties with. It is impossible to know all of the properties associated with a thing or whether two properties talk about the same thing. Now if there was a good reason for the definition of "thing" to be widly varying (and not, say, based on twenty years of object oriented programming, 10 years of HyTime practice, 30 years of file system research and many years of distributed systems research) then I would accept that we should arrive at bottom-up solutions to this tricky problem before attempting a top-down one. Put it this way: governments must manage economies whether they want to or not. They control the cash. Similarly, the W3C controls the definitions of what things mean on the Web. They cannot both make specifications and also choose to leave their interpretation up to readers. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Silence," wrote Melville, "is the only Voice of God." The assertion, like its subject, cuts both ways, negating and affirming, implying both absence and presence, offering us a choice; it's a line that the Society of American Atheists could put on its letterhead and the Society of Friends could silently endorse while waiting to be moved by the spirit to speak. - Listening for Silence by Mark Slouka, Apr. 1999, Harper's xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 15 15:54:05 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:05 2004 Subject: Top-down or bottom-up? In-Reply-To: <3765B35D.EF0886F9@prescod.net> References: <199906111513.LAA27001@hesketh.net> <E10sSdc-0001iC-00@romeo.ic.ac.uk> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> <14180.64662.493404.927680@localhost.localdomain> <3765B35D.EF0886F9@prescod.net> Message-ID: <14182.23225.319557.152831@localhost.localdomain> Paul Prescod writes: > > More specifically, top-down can work only with very, very good models, > > and even I (who am known to shoot my mouth off) would not go so far as > > to claim that I can produce a sufficiently accurate and complete model > > of the Web over the next five years; in the absence of such a model, > > bottom-up development and the free market of ideas is the only > > reasonable choice, messy as it may be. > > I don't think I can produce *the* data model that will be used over the > Web for the next five years. I think that I can produce *a* data model > that would be demonstrably better than the complete lack of such. That's not what I mean -- creating a data model is tractable, but a data model is of questionable value if it's not based on a fairly accurate business model, use cases, etc. I don't think that any of us can reasonably draw up a reliable business model that will cover the Web for the next five years, and even the use cases will be pretty shakey. Without good models, bottom-up is our best bet. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pgrosso at arbortext.com Tue Jun 15 16:42:11 1999 From: pgrosso at arbortext.com (Paul Grosso) Date: Mon Jun 7 17:13:05 2004 Subject: tech doc ML (TDML?) Message-ID: <3.0.32.19990615095209.00fa165c@pophost.arbortext.com> At 12:15 1999 06 14 +0200, Ronald Bourret wrote: >You can find the DTD that the W3C uses to write specs at: > >http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm > >(I assume this is the current version, but don't actually know that for sure.) > The following is the latest public version: DTD: http://www.w3.org/XML/1998/06/xmlspec-19990205.dtd Documentation: http://www.w3.org/XML/1998/06/xmlspec-report-19990205.htm There is likely to be a newer version within the next couple weeks. Note that the XML 1.0 spec was written to a much older version and may not necessarily parse against this DTD. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Tue Jun 15 19:23:39 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:13:05 2004 Subject: Namespace URI address resources Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF732@RED-MSG-08> Recent mail has suggested that a namespace URI could be used to attempt a retrieval of a schema, either using the URI directly or in some modified form or via content negotiation. Other recent mail has objected, saying that there may be a miriad of things one wants to associate in some way with a namespace, for example a suggested (or mandatory?) style sheet to process all elements and attributes defined in that namespace. I suggest that there is a vast difference between something such as a schema, which creates identifiers and gives them a definition, and other resources such as style sheets that may be permanently or ephemerally associated with those identifiers. One defines the data; the other indicates processing. If we follow the principle of cleanly separating data from its processing, we want firm ties to the definition of data, and loose ties to its processing. This argues that the first position is correct, namely that using a namespace URI to retrieve a schema is reasonable and is different in kind from retrieval of other possibly-related resources. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 15 20:02:24 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:06 2004 Subject: Namespace URI address resources In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAF732@RED-MSG-08> References: <5BF896CAFE8DD111812400805F1991F708AAF732@RED-MSG-08> Message-ID: <14182.37936.938967.550979@localhost.localdomain> Andrew Layman writes: > I suggest that there is a vast difference between something such as > a schema, which creates identifiers and gives them a definition, > and other resources such as style sheets that may be permanently or > ephemerally associated with those identifiers. One defines the > data; the other indicates processing. I find the distinction much less clear -- a pure schema is a specification for producing a truth value; a schema that adds information (such as default attribute values in a DTD) is a specification for producing a transformation and a truth value; a stylesheet is a specification for producing visual or aural (or perhaps, tactile) output. They certainly seem like the same general kind of thing, at least to my eyes. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Tue Jun 15 20:05:35 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:13:06 2004 Subject: Just require URLs Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF734@RED-MSG-08> I would like to add my endorsement to W. Eliot Kimber's mail of 1999-06-01T021:53 titled "Re: Just require URLs" and which is apparently not in the archives. I'd like to add a parenthetical comment that I believe supports the thrust of his argument: Eliot wrote "If the true intent of the namespace mechanism is that the URI *is* the namespace (in the sense defined above), then they have to *disallow* resolution of the URI..." Of course, specifications are not people, so do not have intent literally, but as one of the two editors of the specification I can speak for my intent in the wording of the specification: The URI identifies the namespace. That is, the specification very clearly does not require that a URI be resolvable, but neither does it forbid resolution. The URI is an identifier; what other characteristics it may have are not part of the namespaces specification, including whether it is resolvable directly or can be used as part of process that ultimately resolves to a resource. Best wishes, Andrew Layman xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 15 20:54:39 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:13:06 2004 Subject: Namespace URI address resources Message-ID: <01a201beb75f$89dbeba0$0b2e249b@fileroom.Synapse> Andrew Layman wrote: >Recent mail has suggested that a namespace URI could be used to attempt a >retrieval of a schema, either using the URI directly or in some modified >form or via content negotiation. Other recent mail has objected, saying ... > >This argues that the first position is correct, namely that using a >namespace URI to retrieve a schema is reasonable and is different in kind >from retrieval of other possibly-related resources. > It is true that schema definition being akin to class definition has a unique position in the document grove. Yet so does a namespace and overloading the mechanism by which a schema is attached to a document onto the mechanism by which a namespace is attached to an element yields difficult problems. The essential difference is that the namespace is defined by the URI whereas the schema is not defined by the URI rather the contents of the resolved URI. How might this create a problem? Suppose I have a document with a schema at a particular URI resolved by the "http" protocol e.g. http://www.microsoft.com/schemas/x.scm now suppose I wish to e-mail this document behind a firewall, or place the document into a database... behind the firewall, the "http://" protocol is blocked due to corporate policy. Similarly if decades or centuries pass, the data within the database remains valid but the http://www.microsoft.com address has become inactive. The namespace remains the same. The schema is unavailable. Suppose I solve this problem by encapsulating the XML document in a multipart/related MIME message, placing the schema at a location labeled "Content-ID: schema". Now the schema is accessed via the URL "cid:schema", all is good, we can resolve the URL ... but the namespace changes! This problem could be solved by use of a PI to declare the schema <?xml-schema href="URL" ?>. Gateway software would thus be able to encapsulate and transmit XML documents by different network protocols, keeping such protocols independent of the document namespace. All that need change in the document is a PI. Jonathan Borden http://jabr.ne.mediaone.net (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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 15 21:01:01 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:13:06 2004 Subject: Namespace URI address resources Message-ID: <3.0.32.19990615120100.01196c70@pop.intergate.bc.ca> At 10:24 AM 6/15/99 -0700, Andrew Layman wrote: >I suggest that there is a vast difference between something such as a >schema, which creates identifiers and gives them a definition, and other >resources such as style sheets that may be permanently or ephemerally >associated with those identifiers. One defines the data; the other >indicates processing. ... >This argues that the first position is correct, namely that using a >namespace URI to retrieve a schema is reasonable and is different in kind >from retrieval of other possibly-related resources. We disagree, but that's not very helpful because it seems mostly to be a matter of of opinion/religion. I suspect that in the future data-driven Web, the *first* thing I'm going to want when I get a chunk of XML is the java classes or COM objects to do something useful with it, the second thing is a stylesheet, the third thing is a different stylesheet, and the schema is way down the list somewhere. Because I think schemas are mostly useful in the context of data *creation*, and in many apps we want data to be consumed many more times than it is produced. But that's just me. What I am reasonably sure of, though, that for any one of these things (stylesheets, schemas, code, etc), there is going to be some user community for whom that item is the single thing they need, and will want to use the namespace URI to get it, and they will have trouble seeing why the schema should be primus inter pares. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 15 21:32:52 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:13:06 2004 Subject: [Fwd: Just require URLs] Message-ID: <3766AAD4.CFBC7797@locke.ccil.org> -- 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) -------------- next part -------------- An embedded message was scrubbed... From: Andrew Layman <andrewl@microsoft.com> Subject: RE: Just require URLs Date: Tue, 15 Jun 1999 11:30:53 -0700 Size: 2770 Url: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990615/9edd2c67/attachment.eml From andrewl at microsoft.com Tue Jun 15 22:14:54 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:13:06 2004 Subject: Namespace URI address resources Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF73F@RED-MSG-08> Jonathan Borden's recent mail correctly points out that use of a URL as a URI identifying a schema has some potential problems arising from the fact that the "http:" scheme identifies a protocol, one that may not always work. I agree. However, this is distinct from the issue of whether a URI identifying a namespace may properly be used in retrieval of a schema. It simply means that the URL form of URI has some known difficulties. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Tue Jun 15 22:39:05 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:13:06 2004 Subject: X-Schema Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF745@RED-MSG-08> Re Steven Livingstone's question on XML DR: XML Data Reduced Schemas are supported in Internet Explorer 5.0. I know of only two currently-shipping parsers that support it: Microsoft's and Data Channels. The W3C XML Activity has a working group looking into the design of a new schema language. XML-Data was one of several submissions that may influence the deliberations. It is too early to predict details. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From s.livingstone at btinternet.com Wed Jun 16 00:24:30 1999 From: s.livingstone at btinternet.com (Steven Livingstone) Date: Mon Jun 7 17:13:06 2004 Subject: X-Schema In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAF745@RED-MSG-08> Message-ID: <NDBBLGFONPGHMKMHFALIAEHHCAAA.s.livingstone@btinternet.com> I for one hope that the final version is close to the XML DR as they are a lot more intuitive and easier to use than DTD's and it makes a lot more sense to validate XML using an XML-based schema... I guess I shall stick to DTD's for the time-being. Another Question - Is it true that MS shall release an XML add-on to IE4 to allow further features ?? [see this months MIND article]??? What shall this provide... steven -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Andrew Layman Sent: 15 June 1999 21:40 To: xml-dev@ic.ac.uk Subject: RE: X-Schema Re Steven Livingstone's question on XML DR: XML Data Reduced Schemas are supported in Internet Explorer 5.0. I know of only two currently-shipping parsers that support it: Microsoft's and Data Channels. The W3C XML Activity has a working group looking into the design of a new schema language. XML-Data was one of several submissions that may influence the deliberations. It is too early to predict details. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jun 16 01:34:32 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:13:06 2004 Subject: X-Schema Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF74D@RED-MSG-08> I don't know anything about an add-in for IE4. I'll forward the question to the MSXML team. -----Original Message----- From: Steven Livingstone [mailto:s.livingstone@btinternet.com] Sent: Tuesday, June 15, 1999 3:27 PM To: xml-dev@ic.ac.uk Subject: RE: X-Schema I for one hope that the final version is close to the XML DR as they are a lot more intuitive and easier to use than DTD's and it makes a lot more sense to validate XML using an XML-based schema... I guess I shall stick to DTD's for the time-being. Another Question - Is it true that MS shall release an XML add-on to IE4 to allow further features ?? [see this months MIND article]??? What shall this provide... steven -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Andrew Layman Sent: 15 June 1999 21:40 To: xml-dev@ic.ac.uk Subject: RE: X-Schema Re Steven Livingstone's question on XML DR: XML Data Reduced Schemas are supported in Internet Explorer 5.0. I know of only two currently-shipping parsers that support it: Microsoft's and Data Channels. The W3C XML Activity has a working group looking into the design of a new schema language. XML-Data was one of several submissions that may influence the deliberations. It is too early to predict details. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clovett at microsoft.com Wed Jun 16 01:45:10 1999 From: clovett at microsoft.com (Chris Lovett) Date: Mon Jun 7 17:13:06 2004 Subject: X-Schema Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0F362E1B@RED-MSG-56> we do have a version of MSXML.DLL with XML-Data Schema support available for IE4. See http://msdn.microsoft.com/downloads/tools/xmlparser/xmlparser.asp This is the IE5 XML DLL -- but a few browser specific things do not work in IE4 - like the XML Viewer. The above pages list the details. -----Original Message----- From: Andrew Layman Sent: Tuesday, June 15, 1999 4:36 PM To: 'Steven Livingstone'; xml-dev@ic.ac.uk Subject: RE: X-Schema I don't know anything about an add-in for IE4. I'll forward the question to the MSXML team. -----Original Message----- From: Steven Livingstone [mailto:s.livingstone@btinternet.com] Sent: Tuesday, June 15, 1999 3:27 PM To: xml-dev@ic.ac.uk Subject: RE: X-Schema I for one hope that the final version is close to the XML DR as they are a lot more intuitive and easier to use than DTD's and it makes a lot more sense to validate XML using an XML-based schema... I guess I shall stick to DTD's for the time-being. Another Question - Is it true that MS shall release an XML add-on to IE4 to allow further features ?? [see this months MIND article]??? What shall this provide... steven -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Andrew Layman Sent: 15 June 1999 21:40 To: xml-dev@ic.ac.uk Subject: RE: X-Schema Re Steven Livingstone's question on XML DR: XML Data Reduced Schemas are supported in Internet Explorer 5.0. I know of only two currently-shipping parsers that support it: Microsoft's and Data Channels. The W3C XML Activity has a working group looking into the design of a new schema language. XML-Data was one of several submissions that may influence the deliberations. It is too early to predict details. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elham at cs.stanford.edu Wed Jun 16 03:17:24 1999 From: elham at cs.stanford.edu (Elham Ghassemzadeh) Date: Mon Jun 7 17:13:07 2004 Subject: CSS and XML attributes Message-ID: <v04011701b38cabf65d82@[171.66.194.178]> Is there a way to display the value attributes using style sheets? For example what do I write in my style sheet to display product id in the following example? <PRODUCT ID="C07981"> .... </PRODUCT> Thanks for your help Elham -- Elham Ghassemzadeh Stanford University elham@cs.stanford.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Jun 16 03:39:37 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:13:07 2004 Subject: Namespace URI address resources Message-ID: <002101beb791$5f7cade0$0cf96d8c@NT.JELLIFFE.COM.AU> From: Andrew Layman <andrewl@microsoft.com> >If we follow the principle of cleanly separating data from its processing, >we want firm ties to the definition of data, and loose ties to its >processing. A schema is "processing" not "data": it is tied to whatever applications understand the schema format. Editing, creating and validating against a schema are all applications. There is no schema language yet that can express all useful constraints. To propose a mechanism that does not allow a plurality of schemas is, in fact, to say that the schema language should defines the (bounds of the) possible schemas: if XML-Data does not support a constraint, it cannot be part of schemas. This is putting the cart before the horse. It is not that the namespace URI identifies a schema that it is the problem, it is : * the notion that a document has only *one* schema and * there is no mechanism yet to allow alternative schemas to be assigned. If W3C made a mechanism to allow alternative schemas (like Jonathon Bordon's recent post), then the namespace URI could be overloaded to provide a schema, as a defaulting behaviour in the absense of a PI. But it is bad for the WWW if there is no mechanism to allow alternatives; without such a mechanism, requiring overloaded use of the namespace URL is bad. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Wed Jun 16 05:45:26 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:13:07 2004 Subject: Namespace URI address resources In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAF73F@RED-MSG-08> Message-ID: <3.0.1.32.19990615233550.00750b18@mail.muzmo.com> At 01:15 PM 6/15/99 -0700, Andrew Layman wrote: >Jonathan Borden's recent mail correctly points out that use of a URL as a >URI identifying a schema has some potential problems arising from the fact >that the "http:" scheme identifies a protocol, one that may not always work. >I agree. However, this is distinct from the issue of whether a URI >identifying a namespace may properly be used in retrieval of a schema. It >simply means that the URL form of URI has some known difficulties. Which is a good reason to use URNs or some other form of persistent identifier. ---------------------------------------------------------- Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Web: http://www.muzmo.com Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Wed Jun 16 05:45:37 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:13:07 2004 Subject: Namespace URI address resources In-Reply-To: <002101beb791$5f7cade0$0cf96d8c@NT.JELLIFFE.COM.AU> Message-ID: <3.0.1.32.19990615234807.00fd1828@mail.muzmo.com> At 10:44 AM 6/16/99 +1000, Rick Jelliffe wrote: >A schema is "processing" not "data": it is tied to whatever applications >understand the schema format. Editing, creating and validating against a >schema are all applications. Well. Maybe meta-data, but a schema is simply declarative. It does not perform any processing. Editing, creating and validating are all applications. So what? The point is that a schema actually defines some aspect of the meaning of 'names' in a 'namespace'. That seems useful. >There is no schema language yet that can express all useful constraints. >To propose a mechanism that does not allow a plurality of schemas is, in >fact, to say that the schema language should defines the (bounds of the) >possible schemas: if XML-Data does not support a constraint, it cannot >be part of schemas. This is putting the cart before the horse. Using the namespace URI to be locate a schema does not preclude the possibility of there being any number of schemas associated with that URI. > >It is not that the namespace URI identifies a schema that it is the >problem, it is : > >* the notion that a document has only *one* schema and >* there is no mechanism yet to allow alternative schemas to be assigned. Nobody is proposing that a document has only *one* schema. The mechanism is known in the biz as 'content negotiation'. This is known to work for multiple languages and devices. > >If W3C made a mechanism to allow alternative schemas (like Jonathon >Bordon's recent post), then the namespace URI could be overloaded to >provide a schema, as a defaulting behaviour in the absense of a PI. But >it is bad for the WWW if there is no mechanism to allow alternatives; >without such a mechanism, requiring overloaded use of the namespace URL >is bad. As I said, there is such a mechanism. Regards, Murray ---------------------------------------------------------- Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Web: http://www.muzmo.com Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Wed Jun 16 05:45:16 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:13:07 2004 Subject: Just require URLs In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAF734@RED-MSG-08> Message-ID: <3.0.1.32.19990615233133.00f4137c@mail.muzmo.com> This is certainly how I feel about it. Dave Hollander seems to agree -- we are at the XML Schema meeting in Ann Arbor. At 11:06 AM 6/15/99 -0700, Andrew Layman wrote: >I would like to add my endorsement to W. Eliot Kimber's mail of >1999-06-01T021:53 titled "Re: Just require URLs" and which is apparently not >in the archives. > >I'd like to add a parenthetical comment that I believe supports the thrust >of his argument: Eliot wrote "If the true intent of the namespace mechanism >is that the URI *is* the namespace (in the sense defined above), then they >have to *disallow* resolution of the URI..." Of course, specifications are >not people, so do not have intent literally, but as one of the two editors >of the specification I can speak for my intent in the wording of the >specification: The URI identifies the namespace. That is, the specification >very clearly does not require that a URI be resolvable, but neither does it >forbid resolution. The URI is an identifier; what other characteristics it >may have are not part of the namespaces specification, including whether it >is resolvable directly or can be used as part of process that ultimately >resolves to a resource. > >Best wishes, >Andrew Layman > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > ---------------------------------------------------------- Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Web: http://www.muzmo.com Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From heikki at citec.fi Wed Jun 16 10:43:55 1999 From: heikki at citec.fi (Heikki Toivonen) Date: Mon Jun 7 17:13:07 2004 Subject: CSS and XML attributes In-Reply-To: <v04011701b38cabf65d82@[171.66.194.178]> Message-ID: <002201beb7d4$64199320$2500a8c0@hto.citec.fi> > Is there a way to display the value attributes using style sheets? Yes. For > example what do I write in my style sheet to display product id in the > following example? > > <PRODUCT ID="C07981"> .... </PRODUCT> With CSS you can use the :before and :after rules, and specify in the content property that it should display the attribute value of an attribute named ID (my terminology may not be per the spec but hope you understand). Here is a sample: PRODUCT:before { content: attr(ID); } Note that not all products support CSS well enough to understand this. -- Heikki Toivonen http://www.doczilla.com http://www.citec.fi xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:35:12 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:07 2004 Subject: X-Schema References: <NDBBLGFONPGHMKMHFALIAEHHCAAA.s.livingstone@btinternet.com> Message-ID: <37678E25.22F131D8@prescod.net> Steven Livingstone wrote: > > I for one hope that the final version is close to the XML DR as they are a > lot more intuitive and easier to use than DTD's I would be curious to hear your opinion on why XML-syntax schemas are so much easier. My observation is that XML Data Reduce Schemas are only easier than DTDs for the first week at which point they become harder to read, to understand and to maintain. They are, however, easier to parse. My inclination is to write off the claims that XML-syntax schemas are so much easier as merely bias against the syntactically unfamiliar, similar to parentheses and whitespace paranoia. At the end of a day of training (brainwashing) my students usually say: "Why would I spend twenty lines of XML syntax saying what a DTD can say in one line?" I am genuinely interested in improving XML usability, however, so I would like to hear counter-arguments. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:35:08 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:07 2004 Subject: [Fwd: Just require URLs] References: <3766AAD4.CFBC7797@locke.ccil.org> Message-ID: <37680879.6353DCD2@prescod.net> Eliot Kimber says: > > If the true intent of the namespace mechanism is that the URI *is* the > namespace (in the sense defined above), then they have to *disallow* > resolution of the URI, otherwise, you cannot reliably establish > namespace identity because two different URIs could identify the same > resource. AND Andrew Layman wrote: > > The point of the wording was to respect that multiple URIs may reference the > same resource, Do either of you have evidence that the Web addressing model supports this assertion? As near as I can tell the Web has no concept of resource identity except that every URI identifies a unique object. An HTTP server could serve up the same byte stream at two different addresses but as far as the Web is concerned those are two different objects. This defies intuition but seems to be the "web model." -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:44:06 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:07 2004 Subject: Top-down or bottom-up? References: <199906111513.LAA27001@hesketh.net> <E10sSdc-0001iC-00@romeo.ic.ac.uk> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> <14180.64662.493404.927680@localhost.localdomain> <3765B35D.EF0886F9@prescod.net> <14182.23225.319557.152831@localhost.localdomain> Message-ID: <376792AE.2C82DE20@prescod.net> David Megginson wrote: > > That's not what I mean -- creating a data model is tractable, but a > data model is of questionable value if it's not based on a fairly > accurate business model, use cases, etc. I do not see why a data model has any higher requirement for business models, use cases and so forth than a language like HTML, XLink or XML namespaces. In fact, I would argue that those languages always have an implicit data model reflecting implicit use cases and business models. We can make the data model explicit without making the use models explicit. Isn't that essentially what the information set is doing? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:44:04 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:07 2004 Subject: [Fwd: Just require URLs] References: <3766AAD4.CFBC7797@locke.ccil.org> Message-ID: <376808C8.C38003D2@prescod.net> Andrew Layman wrote: > > Two distiinct URIs might in fact identify the same namespace, Tim Bray has been quite clear that it is his opinion that namespace URIs *do not identify namespaces* in the sense of "identify" used in the URI specification. According to him they are just strings that happen conveniently to be unique and globally managed. This difference between you on this issue is alarming. > but within the facilities of the namespaces specification they would not be > known to do so. The namespaces specification defines the *concept* of XML namespaces. Therefore if it does not have a provision for two URIs pointing to the same "namespace" then there can be no such provision without an amendment or superceding specification -- unless we accept that general Web concepts of "equality" and "URI" apply -- In which case "http://" URIs are self-evidently bogus AND illegal because the namespace that they point to is "missing." -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:45:12 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:07 2004 Subject: Just require URLs References: <5BF896CAFE8DD111812400805F1991F708AAF734@RED-MSG-08> Message-ID: <37680936.E37FAD8@prescod.net> Andrew Layman wrote: > >.... > I can speak for my intent in the wording of the > specification: The URI identifies the namespace. That is, the specification > very clearly does not require that a URI be resolvable, but neither does it > forbid resolution. I want to be clear on this. Given the following definitions: * namespace processor: a tool that has no other purpose than to present the data model implicit in the namespace specification to applications in a legal manner * URI resource equality: a concept endorsed by the IETF in the future that allows to URIs to point to the same logical object * URI equivalence: multiple URIs pointing to the same resource Would it be legal, in your opinion, for a namespace processor to substitute an equivalent URI for the supplied one in presenting the namespace information to the application, just as it might substitute an equivalent prefix? In my opinion the answer to this question should be the same as the answer to the "relative URI" question. I haven't heard a clear answer to that one yet. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:51:11 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:07 2004 Subject: [Fwd: Just require URLs] References: <3766AAD4.CFBC7797@locke.ccil.org> Message-ID: <37677C5D.82CB7C79@prescod.net> Eliot Kimber says: > > If the true intent of the namespace mechanism is that the URI *is* the > namespace (in the sense defined above), then they have to *disallow* > resolution of the URI, otherwise, you cannot reliably establish > namespace identity because two different URIs could identify the same > resource. AND Andrew Layman wrote: > > The point of the wording was to respect that multiple URIs may reference the > same resource, Do either of you have evidence that the Web addressing model supports this assertion? As near as I can tell the Web has no concept of resource identity except that every URI identifies a unique object. An HTTP server could serve up the same byte stream at two different addresses but as far as the Web is concerned those are two different objects. This defies intuition but seems to be the "web model." -- Paul Prescod [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:51:43 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:07 2004 Subject: X-Schema References: <NDBBLGFONPGHMKMHFALIAEHHCAAA.s.livingstone@btinternet.com> Message-ID: <37678E25.22F131D8@prescod.net> Steven Livingstone wrote: > > I for one hope that the final version is close to the XML DR as they are a > lot more intuitive and easier to use than DTD's I would be curious to hear your opinion on why XML-syntax schemas are so much easier. My observation is that XML Data Reduce Schemas are only easier than DTDs for the first week at which point they become harder to read, to understand and to maintain. They are, however, easier to parse. My inclination is to write off the claims that XML-syntax schemas are so much easier as merely bias against the syntactically unfamiliar, similar to parentheses and whitespace paranoia. At the end of a day of training (brainwashing) my students usually say: "Why would I spend twenty lines of XML syntax saying what a DTD can say in one line?" I am genuinely interested in improving XML usability, however, so I would like to hear counter-arguments. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because X-Mozilla-Status: 0009 garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:55:44 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:07 2004 Subject: XSL and the semantic web References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> Message-ID: <37677C57.315E5210@prescod.net> "Simon St.Laurent" wrote: > > >Note that there is also widespread dissatisfaction with namespaces, RDF, > >XLink and XML itself. > > Apart from Ted Nelson's excellent "Embedded Markup Considered Harmful", I > haven't seen much claiming that XML is a danger to the semantic Web the W3C > seems interested in building. I think that most people agree that being able to hide intellectual property behind a semantic firewall is a Good Thing. We are, after all, mostly capitalists and tend to think that short of ethics concerns, independent actors should be able to control how their intellectual property is distributed. If they want to dumb down their data then they should have that right, right? Why should the W3C get in their way? I want to address your concern that this goes against the grain of the "semantic Web". There is only a conflict if you think that the semantic web is about all information being freely available in its most semantic form. My interpretation was always that the semantic web was about some information being richly semantic and free ("yellow pages online"), some being richly semantic and expensive (e.g. the company database behind the yellow pages), some being presentational and free ("Joe's Web Pag") and some being presentational and expensive ("Paul Abdul's latest video"). In other words I always interpreted it as being about choice. You complain that XSL allows this choice. Even if it were the case that XSL uniquely allowed data dumbing (which it is not), I could not see how its allowance of this choice would constitute a problem or flaw. Data dumbing is part of the economy and ecology of the Web. As Guy Murphy has described, the Web is richer for it. Do we want Lexis-Nexis to take their thousands of databases back to their private network where they controlled the level of semantics tightly? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:56:06 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:08 2004 Subject: Transformation versus annotation References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> Message-ID: <37677C4E.930AE7AC@prescod.net> "Simon St.Laurent" wrote: > > The problem, fundamentally, is that XSL FOs are an element vocabulary, > while CSS properties lived inside attributes or style sheets, without > disrupting the original element names. XSL FOs do not disrupt the "original" element type names. They still exist in the original document that was the source of the transformation. > See above. Transformations to an endpoint that still had as much semantics > as the original - formatting properties represented as attributes rather > than elements - might have avoided lots of the 'considered harmful' issues > that you want to ignore. I think inclusion and sequence are the only large > problems such an approach presents, and I don't think they're insoluble. They are insoluable. The whole point of transformations: whether XSLT or DOM is that they are *arbitrarily sophisticated*. That means that I can have a very loose binding between markup and presentation. That means that I can invest in my expensive information assets without worrying about the presentational technologies of the day. I have DTDs with elements that are processed with rules like: "go to the REF sub-element's HREF attribute, dereference it and check whether the target is a class-name or an instructor-name. If the former, extract the ISO 8869 DATE attribute and format it according to this format rule: '%month% %day%, %year%'. If it is the latter, then dereference each of the "TEACHES" anchors and fetch the ISO 8869 DATE attribute from the element targets. Concatenate them with spaces and output them." Do you propose that after 15 years of failure we now have the ability to make style languages in the annotation model that can solve the many common (common!) problems of this sort? If you can write such a language, please do so and let me invest in your company. Something with the simplicity of CSS and the power of XSL is the holy grail of stylesheet inventors. You could build a killer XML editor around it. Adobe would pay millions for it. I, personally, think that is impossible not just practically but even in theory. --- Unworkable solution 1: "Do it server side." * But I want to ship rich semantic data to the client! That's the point of the semantic web! Unworkable solution 2: "Use the DOM" * The DOM could accomplish this task but in doing so it would be essentially a transformation language and thus exhibit all of the flaws that you complain about (generating a second tree with less semantic information). Unworkable solution 3: "Don't do it." * But my clients have terabytes of complex, intricate semantic information that they WANT to make available over the Web (usually for a price). Don't we need that data to build the semantic web? Given that client-side transformations are the least of all possible evils in this case, the question boils down to whether to use the DOM or XSL. We've had that debate already. It boils down to a question of style. (sorry!) -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:57:30 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:08 2004 Subject: Packaging and hub documents References: <3.0.32.19990614104158.02340a30@pop.intergate.bc.ca> <14181.18060.445731.712967@localhost.localdomain> <v04205105b38b17337ea2@[192.168.0.1]> Message-ID: <37677C47.BE001CD1@prescod.net> Andy Dent wrote: > > Wrapping this in multi-part MIME would have complicated the parsing > considerably. Why couldn't you have just used a generic MIME parser to parse at one level and pipe discovered entities to Expat? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:57:34 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:08 2004 Subject: [Fwd: Just require URLs] References: <3766AAD4.CFBC7797@locke.ccil.org> Message-ID: <37677C50.2119E279@prescod.net> Andrew Layman wrote: > > Two distiinct URIs might in fact identify the same namespace, Tim Bray has been quite clear that it is his opinion that namespace URIs *do not identify namespaces* in the sense of "identify" used in the URI specification. According to him they are just strings that happen conveniently to be unique and globally managed. This difference between you on this issue is alarming. > but within the facilities of the namespaces specification they would not be > known to do so. The namespaces specification defines the *concept* of XML namespaces. Therefore if it does not have a provision for two URIs pointing to the same "namespace" then there can be no such provision without an amendment or superceding specification -- unless we accept that general Web concepts of "equality" and "URI" apply -- In which case "http://" URIs are self-evidently bogus AND illegal because the namespace that they point to is "missing." -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:57:39 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:08 2004 Subject: Top-down or bottom-up? References: <199906111513.LAA27001@hesketh.net> <E10sSdc-0001iC-00@romeo.ic.ac.uk> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> <14180.64662.493404.927680@localhost.localdomain> <3765B35D.EF0886F9@prescod.net> <14182.23225.319557.152831@localhost.localdomain> Message-ID: <376792AE.2C82DE20@prescod.net> David Megginson wrote: > > That's not what I mean -- creating a data model is tractable, but a > data model is of questionable value if it's not based on a fairly > accurate business model, use cases, etc. I do not see why a data model has any higher requirement for business models, use cases and so forth than a language like HTML, XLink or XML namespaces. In fact, I would argue that those languages always have an implicit data model reflecting implicit use cases and business models. We can make the data model explicit without making the use models explicit. Isn't that essentially what the information set is doing? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself htX-Mozilla-Status: 0009/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:57:43 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:08 2004 Subject: Namespace URI address resources References: <5BF896CAFE8DD111812400805F1991F708AAF732@RED-MSG-08> Message-ID: <37677C4F.A3FBB0E3@prescod.net> Andrew Layman wrote: > > I suggest that there is a vast difference between something such as a > schema, which creates identifiers and gives them a definition, and other > resources such as style sheets that may be permanently or ephemerally > associated with those identifiers. One defines the data; the other > indicates processing. It seems to me to be entirely debatable whether a schema defines element and attribute types or whether it just constrains their use. My personal take is that the schema merely contrains use. Consider that I have a document that is an HTML document. Is the most important feature of the P elements in the document that they are globally known as "HTML paragraphs" (their semantics) or the details of the element type declaration in the DTD? If I swap in another variant of the HTML DTD with another set of element type declarations have I completely changed the nature of those element types? If I have a CDF document without a DTD or schema would it be accurate to say that those element types are "undefined"? Or merely not defined in a manner that would allow a computer to check validity using a standardized schema language? If I have two schemas for a document, in two different schema languages, must one be the "definitive" schema and the other non-definitive? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:57:49 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:08 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> Message-ID: <37677C4D.EE569E1E@prescod.net> "Simon St.Laurent" wrote: > > CSS+XML doesn't allow them to post semantic markup? (CSS by itself doesn't > let you post _anything_, so I don't know what you're talking about. HTML?) When you sit down to implement an XML system the last thing you think about is CSS, XSL, or the DOM. The first thing you think about is the needs of the data. If you have any volume of textual data, you will probably not get another opportunity to re-encode all of it until CSS and XSL are historical artifacts, Microsoft is a division of Red Hat, and the Web has more users than the telephone. So you *must* concentrate on the needs of the data. You must make richly semantic markup that captures the structure of the data. And you must have human authors start to add this semantic markup to the data as soon as possible. You must minimize the cost of this markup effort. Having done this process right, for a sophisticated document type, it is highly unlikely that you will be able to display your documents directly using CSS. Graphics will cause a problem. Cross references will cause a severe problem. Navigational mechanisms will be lacking...and so forth. Therefore you cannot just stick the XML file and a CSS stylesheet on your website. You must dumb down the XML somehow -- to HTML or to some weakly semantic variant that has redundant cross reference text, redundant navigational mechanisms, HTML-compatible IMG tags and so forth. Without some client-side transformational mechanism (either XSL or the DOM), CSS *discourages* the distribution of rich semantic information because it requires you to dumb down your data. > The question is not whether FO's harmfulness is solvable, it's whether it's > an acceptable cost. I see it as a cost that wouldn't have been incurred > had we stuck to annotation for formatting - while you could strip semantics > to SPAN and DIV if you really wanted, the whole selector mechanism of > Cascading Style Sheets discourages such practice. It would have taken an > extra level of processing to do that stripping. As I described above, CSS requires the "extra level of processing" anyhow. The difference is that XSL and the DOM allow that extra level of processing to be *client side*, which means that the client is working with rich data. Without transformation languages, CSS requires the dumbing down to be *server side*. This isn't an argument against CSS. It's an argument FOR transformation languages (used, sometimes, in concert with CSS). > In this case, 20/20 hindsight for the XSL community is an "I told you so" > for the CSS community. Take a look at the early battles on XSL-list and > you'll see that I'm saying nothing original here - these arguments were on > the list before I even subscribed. Doesn't it seem like our responsibility > to learn from the lessons of _one_ year ago rather than racking up the same > kinds of problems again and again? A year ago the XSL specification was explicit in its goal of achieving compatibility with CSS. It referred explicitly and directly to CSS properties. There was a separate working group formed to develop a cross-language formatting model. As far as I can see, the FO model and the CSS model are very close. I certainly hope so: I will soon be teaching FOs by teaching CSS first! -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Jun 16 12:57:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:13:08 2004 Subject: Just require URLs References: <5BF896CAFE8DD111812400805F1991F708AAF734@RED-MSG-08> Message-ID: <37677C5E.849F1A41@prescod.net> Andrew Layman wrote: > >.... > I can speak for my intent in the wording of the > specification: The URI identifies the namespace. That is, the specification > very clearly does not require that a URI be resolvable, but neither does it > forbid resolution. I want to be clear on this. Given the following definitions: * namespace processor: a tool that has no other purpose than to present the data model implicit in the namespace specification to applications in a legal manner * URI resource equality: a concept endorsed by the IETF in the future that allows to URIs to point to the same logical object * URI equivalence: multiple URIs pointing to the same resource Would it be legal, in your opinion, for a namespace processor to substitute an equivalent URI for the supplied one in presenting the namespace information to the application, just as it might substitute an equivalent prefix? In my opinion the answer to this question should be the same as the answer to the "relative URI" question. I haven't heard a clear answer to that one yet. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco [Woody Allen on Hollywood in "Annie Hall"] Annie: "It's so clean down here." Woody: "That's because they don't throw their garbage away. They make it into television shows." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From steven.livingstone at scotent.co.uk Wed Jun 16 13:17:07 1999 From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM) Date: Mon Jun 7 17:13:08 2004 Subject: X-Schema Message-ID: <8DCB90532FF7D211B34400805FD488531AEA99@SENMAIL3> I am relatively new to using the data schema's, but I immediately found them much more aligned to the XML documents I was creating. Don't get me wrong, neither are particulary difficult to use, but I like the idea of describing all XML using an XML-based language. For example, the chances are you shall write a lot more XML documents than you will DTD/Schema for validation. I find it a lot easier to read Schema validation than DTD. Of course there is also the lack of typed attributes etc.. in DTD's. Further down the line (and please correct me if I wrong)... ...would having an XML-based schema not give you the potential to create schema from schema ?? So if you had something which require specific validation using subsets of other validation schema, you could produce it by combining parts from the two (dare I say using some equivalent to XSL) ?? Could you do this with DTD's ? Rgds, Steven Join Association of Internet Professionals - http://www.citix.com/aip Steven Livingstone President, AIP Scotland. ceo@citix.com http://www.citix.com > -----Original Message----- > From: Paul Prescod [SMTP:paul@prescod.net] > Sent: 16 June 1999 12:45 > To: xml-dev@ic.ac.uk > Subject: Re: X-Schema > > Steven Livingstone wrote: > > > > I for one hope that the final version is close to the XML DR as they are > a > > lot more intuitive and easier to use than DTD's > > I would be curious to hear your opinion on why XML-syntax schemas are so > much easier. > > My observation is that XML Data Reduce Schemas are only easier than DTDs > for the first week at which point they become harder to read, to > understand and to maintain. They are, however, easier to parse. My > inclination is to write off the claims that XML-syntax schemas are so much > easier as merely bias against the syntactically unfamiliar, similar to > parentheses and whitespace paranoia. At the end of a day of training > (brainwashing) my students usually say: "Why would I spend twenty lines of > XML syntax saying what a DTD can say in one line?" > > I am genuinely interested in improving XML usability, however, so I would > like to hear counter-arguments. > > -- > Paul Prescod - ISOGEN Consulting Engineer speaking for only himself > http://itrc.uwaterloo.ca/~papresco > > [Woody Allen on Hollywood in "Annie Hall"] > Annie: "It's so clean down here." > Woody: "That's because they don't throw their garbage away. They make > it into television shows." > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From steven.livingstone at scotent.co.uk Wed Jun 16 13:23:20 1999 From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM) Date: Mon Jun 7 17:13:08 2004 Subject: CSS and XML attributes Message-ID: <8DCB90532FF7D211B34400805FD488531AEA9C@SENMAIL3> You could use something like this ... <xsl:for-each select="PRODUCT [@ID]"> <B><xsl:value-of /></B><BR/> </xsl:for-each> steven Join Association of Internet Professionals - http://www.citix.com/aip Steven Livingstone President, AIP Scotland. ceo@citix.com http://www.citix.com > -----Original Message----- > From: Elham Ghassemzadeh [SMTP:elham@cs.stanford.edu] > Sent: 16 June 1999 02:20 > To: xml-dev@ic.ac.uk > Subject: CSS and XML attributes > > Is there a way to display the value attributes using style sheets? For > example what do I write in my style sheet to display product id in the > following example? > > <PRODUCT ID="C07981"> .... </PRODUCT> > > Thanks for your help > Elham > -- > Elham Ghassemzadeh > Stanford University > elham@cs.stanford.edu > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Wed Jun 16 13:23:10 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:13:08 2004 Subject: Namespace URI address resources Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054C28@sohos002.ied-support.net> Rick Jelliffe wrote: > A schema is "processing" not "data": it is tied to whatever > applications > understand the schema format. Editing, creating and > validating against a > schema are all applications. I can't understand how the idea that schemas operate at the same level as Java classes and stylesheets has been introduced into this discussion. As far as I can see, one point of the schema proposal is to be functionally equivalent to a DTD with a few obvious advantages, one of these being that if we get the definition right, each node can specify its own schema. This makes the dynamic creation of documents that are made up of other documents a much more straightforward task (for example, as occurs in fragment interchange and transclusion), and, IMO, impossible without it. However, the fact that the schema can at its simplest play the role of the DTD means that it is used by the parser, not just the application. I use the terms here in the logical sense implied by XML 1.0; the parser will check the document for well-formedness and possibly validate it, the application will then make use of the document. So "editing, creating and validating against a schema" are NOT all applications - validating happens at a lower level. To look at it a different way, DTDs can also be used to write tools that edit and create documents but that does not detract from their fundamental role in the validation of documents. In other words, they are most definitely NOT on the same level as stylesheets, Java classes, or whatever. I think the problem we have is that validation is a special case of the use of namespaces. In normal circumstances you would validate the document and then pass it on for processing, and the processing application would make use of any namespaces present, as it wants. In other words there is a clear separation as to exactly where namespaces play a role. However, to allow documents to have a mixture of schemas (in the sense of DTD substitutes) we need to use namespaces to indicate which schema should be used. In other words, there needs to be some way of saying which namespace corresponds to which schema. Namespaces are therefore already playing a role at the level of parsing. This is incidentally why I don't PIs could be used for this, as some have suggested, since according to XML 1.0, PIs are passed through the parser to applications. But by then it's too late - we need the schema for validation. [IMHO I would even suggest it is more 'intuitive' anyway, to use the namespace attribute. Remember the original namespace debate that raged on this list? Everyone thought that namespaces WERE validation! It just seemed so ... well ... intuitive.] Regards, Mark Birbeck Mark.Birbeck@iedigital.net http://www.iedigital.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 16 14:25:12 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:08 2004 Subject: X-Schema In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAF745@RED-MSG-08> References: <5BF896CAFE8DD111812400805F1991F708AAF745@RED-MSG-08> Message-ID: <14183.38747.468980.993580@localhost.localdomain> Andrew Layman writes: > The W3C XML Activity has a working group looking into the design of > a new schema language. XML-Data was one of several submissions > that may influence the deliberations. It is too early to predict > details. It's probably too early to predict what the final form of XML Schemas will look like, but there is already a public working draft available (the first covers structure, and the second covers data typing): http://www.w3.org/TR/xmlschema-1/ http://www.w3.org/TR/xmlschema-2/ All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From steven.livingstone at scotent.co.uk Wed Jun 16 14:26:35 1999 From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM) Date: Mon Jun 7 17:13:08 2004 Subject: Practical XML Message-ID: <8DCB90532FF7D211B34400805FD488531AEAA6@SENMAIL3> I am developing a XML Web project based on cinemas thoughout Glasgow, Scotland. Now, I am going to use XML client-side (maybe server-side) to mark up the info (so we can compare prices/film types etc..). What is the better way to store the data : 1. All cinema's in one XML file 2. An XML file per cinema 3. Store cinema details as text in DB and mark them up and they are retrieved 4. Store marked-up data in DB Also, say I have 1000 cinemas stored in seperate XML files (because I asked each conema to enter their detalis and send the file to me) and someone wanted to do a search on these - how should this be done? I am using SQL Server 7, ASP,VB 6 and IIS4 (maybe 5)., but I would be interested in *all* ideas. thanks steven Join Association of Internet Professionals - http://www.citix.com/aip Steven Livingstone President, AIP Scotland. ceo@citix.com http://www.citix.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Wed Jun 16 14:29:39 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:13:08 2004 Subject: X-Schema Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054C29@sohos002.ied-support.net> Paul Prescod wrote: > At the end of a day of training (brainwashing) my students > usually say: "Why would I spend twenty lines of XML syntax > saying what a DTD can say in one line?" > > I am genuinely interested in improving XML usability, > however, so I would like to hear counter-arguments. I think ultimately it is because it is XML. You now have a document that can be parsed and processed with the same tools that you use for all your other documents. This makes a number of things a lot easier. For example, it is surely theoretically possible to create an XSLT document from two schema, that converts a document of type A to one of type B. This could be done with a series of XSLT files. Also, as other XML techniques become standardised, XML-based schema automatically 'inherit' them. For example, when we have got a working approach to transclusion with XLinks, I could include your schema inside my schema. With XPointer I might even just include a small part of your schema. Of course some of these things could be carried out with DTDs - the transformation and including other DTDs - but they are done with techniques that only exist for DTDs, and no other realm of XML. For me, though, the main problem with DTDs is not their syntax, but the difficulty in validating a document that is based on two or more DTDs. With the mechanism as it stands you need to create a third schema which is the amalgam of both schemas, but this is impractical for most real world uses. Imagine that I include a link in a document to my profile, which is an XLink and is to be transcluded. This means that the parser needs to know the type of my profile after including it, so that it can validate it. But what if I change my profile from a boring load of text to a video, but the XLink remains the same? The DTD containing the link to the profile would need to have the video and text DTDs already there, which is impractical if new schemas for profiles are continually added. With the current XML-Data approach, I can define the schema to be used on a per-node basis, so including a node also includes the information needed to validate it. Anyway, if I may give my humble pointer to the future, manual generation of this stuff is not going to be around for long. As I have mentioned in previous discussions, I have devised a simple system whereby a hierarchical database functions as a massive XML document, and nodes and their children can be extracted as needed. I'm sure many others have done this, so this is not a great claim, however, this has now been extended so that the schemas that define this document and all its sub-documents can also be extracted at any level. This means that you only actually extract the amount of schema you need for the document being exported, and it makes schema very easy to maintain (you just have to maintain the database). So, to illustrate the point, I have 'objects' of type article which can contain objects of type paragraph. When I export an article I place on the article node a pointer to the article schema. All the latter does is pull out schema information for the article and all its children. However, if asked to export just a paragraph of text from an article, I attach to that node a pointer to the paragraph schema. Why pass any more? The validater doesn't need it. Regards, Mark Birbeck Mark.Birbeck@iedigital.net http://www.iedigital.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 16 14:30:26 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:08 2004 Subject: Namespace URI address resources In-Reply-To: <3.0.1.32.19990615234807.00fd1828@mail.muzmo.com> References: <002101beb791$5f7cade0$0cf96d8c@NT.JELLIFFE.COM.AU> <3.0.1.32.19990615234807.00fd1828@mail.muzmo.com> Message-ID: <14183.39133.879693.727504@localhost.localdomain> Murray Maloney writes: > Well. Maybe meta-data, but a schema is simply declarative. > It does not perform any processing. Editing, creating and > validating are all applications. So what? Schemas and stylesheets are both declarative, and both include information that can be acted on by processors. In the case of a schema, the result is a truth value (valid/not valid) and, optionally, a transformation (supplying default values, etc.); in the case of a stylesheet, the result is a transformation or rendition. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 16 14:32:40 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:08 2004 Subject: X-Schema In-Reply-To: <37678E25.22F131D8@prescod.net> References: <NDBBLGFONPGHMKMHFALIAEHHCAAA.s.livingstone@btinternet.com> <37678E25.22F131D8@prescod.net> Message-ID: <14183.39278.309361.452638@localhost.localdomain> Paul Prescod writes: > I am genuinely interested in improving XML usability, however, so I > would like to hear counter-arguments. In my opinion, the best counter argument is that you can include structured documentation as part of the schema itself. In a DTD, an awful lot of useful information is stashed away in comments, and has to be copied into documentation using cut-and-paste. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 16 14:36:21 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:09 2004 Subject: Top-down or bottom-up? In-Reply-To: <376792AE.2C82DE20@prescod.net> References: <199906111513.LAA27001@hesketh.net> <E10sSdc-0001iC-00@romeo.ic.ac.uk> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> <14180.64662.493404.927680@localhost.localdomain> <3765B35D.EF0886F9@prescod.net> <14182.23225.319557.152831@localhost.localdomain> <376792AE.2C82DE20@prescod.net> Message-ID: <14183.39487.992533.773762@localhost.localdomain> Paul Prescod writes: > I do not see why a data model has any higher requirement for > business models, use cases and so forth than a language like HTML, > XLink or XML namespaces. In fact, I would argue that those > languages always have an implicit data model reflecting implicit > use cases and business models. We can make the data model explicit > without making the use models explicit. Isn't that essentially > what the information set is doing? I am quite comfortable helping to design a data model for XML, because XML *as a language* is a closed system; I am not (yet) comfortable helping to design a data model for the Web in general. Perhaps we have been misunderstanding each-other. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Wed Jun 16 14:46:31 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:13:09 2004 Subject: Namespace URI address resources Message-ID: <01BEB807.0420E8A0@grappa.ito.tu-darmstadt.de> The nice thing about using the URI to find (as opposed to to point to) the schema is that it's an easily defended argument. "Oh, yes," you say. "We don't really prohibit you from doing other things with the namespace URI. We don't even violate its sanctity. We just use it as a unique identifier in the identification process." But if it doesn't point to the schema directly, how is any generic piece of software ever going to use it in the identification process? A Universal URI-To-Schema Resolver strikes me as rather less likely than a universal public identifier resolver. I mean, how many parsers today can resolve public identifiers to DTDs? Can you imagine how far XML would have gotten if the only way to associate a DTD with a document was through a public identifier? My apologies for the sarcasm, but although I find the use of namespace URIs to find schemas a wonderful theoretical idea, I'm having more than a little trouble seeing how it could possibly work in practice. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jun 16 15:45:28 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:09 2004 Subject: Announcement: SAX2 1999-06-01 alpha release for Java In-Reply-To: <3761821C.4446F61B@pacbell.net> References: <14163.61975.304542.267110@localhost.localdomain> <3761821C.4446F61B@pacbell.net> Message-ID: <14183.43186.446308.624682@localhost.localdomain> David Brownell writes: > - I think the "validation" property should be immutable during > parses; nonvalidating parses will generally discard data > that a validating parse requires. Agreed. > - Why shouldn't declaration and lexical handlers be set "at any > time" during a parse, like the SAX1 handlers? Is this the case with SAX1, or is it simply underspecified? > - When I implemented reporting of entity expansion for Sun last > fall, I ran into a problem case that hasn't been addressed in > the SAX2 draft. Namely, entities in attributes ... consider > > <element attr="&entity;"/> > > will generally get reported as > > startEntity ("entity"); > endEntity ("entity"); > startElement ("element", {"attr", value-of-entity, ...} ...); > endElement ("element"); > > which doesn't really make sense. Sun's parser deals with this > issue by not reporting such entity expansions. It's not clear > to me how SAX2 will deal with the issue. I'm either to live with the status quo or to back out and scrap reporting of entity boundaries altogether -- this is getting far too complicated for far too little real reward. > - There's a similar issue with expanding parameter entities: > > <!ATTLIST element > %common-attrs; > %i18n-attrs; > %optional-attrs; > attr NOTATION ( %notation-set-1; ) "fubar" > > > > And so on with conditional sections and other declarations; Sun's > parser deals with that issue by not reporting parameter entity > expansions through those reporting callbacks. Ditto. > Issues with what's NOT in the draft API, and where the lack is IMHO a > notable API completeness issue for a "core" in SAX2: > > - Information re NOTATION attributes is discarded. In the example > above, the attributeDecl() callback discards the list of which > notations are permitted. Suggested fix: update the API. Sun's > API doesn't discard this info, others are also possible. Agreed -- this needs to be fixed somehow. > - The internal DTD subset isn't available. This means one can't > reproduce the <!DOCTYPE...> declaration; some applications have > convinnced me that they absolutely require that capability. > Suggested fix: as above, update the API (look at Sun's for one > solution known to work). The internal subset is available, indirectly -- it consists of everything between the start/endDTD events outside of any start/endEntity events. > - The SAX1 handlers aren't "gettable" in the way the SAX2 ones are. > Suggested fix: just define handler IDs for them. That's a good idea. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Wed Jun 16 16:13:32 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:13:09 2004 Subject: CSS and XML attributes Message-ID: <93CB64052F94D211BC5D0010A800133170EF07@wwmess3.bra01.icl.co.uk> > From: Elham Ghassemzadeh [mailto:elham@cs.stanford.edu] > what do I write in my style sheet to display product id in the > following example? > > <PRODUCT ID="C07981"> .... </PRODUCT> <xsl:value-of select="@ID"/> But please read the spec before trying 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Wed Jun 16 16:25:10 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:13:09 2004 Subject: [Fwd: Just require URLs] Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054C2B@sohos002.ied-support.net> Paul - interesting as your comments are, why are you sending them all twice? Is it just me seeing double? Is the list server up the spout and everyone is seeing double, or is there an echo somewhere? Best regards, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From akwheel at talos.org Wed Jun 16 16:24:58 1999 From: akwheel at talos.org (Andrew Wheeler) Date: Mon Jun 7 17:13:09 2004 Subject: Advice on DTD's Message-ID: <11AF09C0F118D311B6F200805F71B1BEBA7F@tardis> Hello, I am currently working for client that has developed a data model and is using an XML DTD to describe it. We are using Near and Far to develop the DTD, but require textual definitions for each of the elements and attributes. These textual definitons, a Data Element Dictionary, is required to help developers understand the model (as well as us!). In Near and Far, and other tools I have seen, you only have the option to insert a comment, at the element level, not really to describe in great detail attributes, and their potential values, etc. We would like to produce the DTD without comments for applications, and some other output that would document the hierarchical structure of the DTD but with added bonus of clicking on a element and getting a description for it (We do not really want to spend time writing bespoke code, which we have to maintain). Could somebody please indicate what tools they use to do this job, other than Near and Far. I am looking for a tool that is fully supported, and is not somebodies backyard hack (no offence to all that fit into that category, but my cleint will only buy tools that they feel comfortable with). I have looked on Robin Cover's site, as well as XMLSOFTWARE, but the same tools just seem to crop up all the time. Somebody out there must be having the same problem, or is everybody using this small set of tools? Or am I asking too much? Sorry if many people have asked this question a hundred times before but this is my last resort. Regards Andrew xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From swamis at wipsys.stph.net Wed Jun 16 16:29:55 1999 From: swamis at wipsys.stph.net (Puppala Satyanarayana S) Date: Mon Jun 7 17:13:09 2004 Subject: No subject Message-ID: <3.0.1.32.19990616200312.007a9430@192.168.150.100> This might be a basic question to you. But its really a big problem for me. I just started learning xml. I wrote a xml document which is valid(I mean i have a DTD for it). I wrote a XSL file for this xml document.Now i tried to view the xml file in IE5 browser. But , only the source code of the document was displayed, even the tags were displayed. Whether there is any problem with IE5. The IE5 i downloaded was a Beta version. Is there any other in which i can view my xml document? Can anyone help me? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From north at Synopsys.COM Wed Jun 16 16:39:05 1999 From: north at Synopsys.COM (Simon North) Date: Mon Jun 7 17:13:09 2004 Subject: Advice on DTD's In-Reply-To: <11AF09C0F118D311B6F200805F71B1BEBA7F@tardis> Message-ID: <199906161440.QAA02766@goofy.gr05.synopsys.com> Andrew Wheeler asked about tools for adding textual definitions to a DTD ... Andrew, I use Earl Hood's DTD2HTML Perl package. It allows you to create a navigable set of HTML pages from the DTD. Each element and each attribute gets its own page, and they can all be cross-linked to a semi-graphical tree. The nicest thing about this 'tool' is that the 'documentation' is contained in a separate file that is read in when you create the HTML code. This keeps the DTD 'clean' (avoiding adding comments) and allows you to incrementally improve the documentation without starting from scratch every time. Perl of course has been around for years, DTD2HTML has been stable for about 4 years, it's all public domain but certainly not a "backyard hack". I hope it's what you're looking for, it's certainly been more than useful to me. Simon North Simon J North BA(Hons) Eng Tech(CEI) FISTC ARAeS TMIEIE MIPRE Senior Staff Technical Writer, Synopsys GmbH, Herzogenrath, Germany xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Wed Jun 16 17:05:40 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:13:09 2004 Subject: CSS and XML attributes Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A19A9@eukbant101.ericsson.se> > -----Original Message----- > From: Kay Michael [SMTP:Michael.Kay@icl.com] > > > From: Elham Ghassemzadeh [mailto:elham@cs.stanford.edu] > > what do I write in my style sheet to display product id in the > > following example? > > > > <PRODUCT ID="C07981"> .... </PRODUCT> > > <xsl:value-of select="@ID"/> > > But please read the spec before trying it. > Please read the subject line before replying with an XSL solution. :) Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jgardner at blue.weeg.uiowa.edu Wed Jun 16 17:05:07 1999 From: jgardner at blue.weeg.uiowa.edu (JR Gardner) Date: Mon Jun 7 17:13:09 2004 Subject: Advice on DTD's In-Reply-To: <199906161440.QAA02766@goofy.gr05.synopsys.com> Message-ID: <Pine.A41.3.95.990616100545.23320C-100000@black.weeg.uiowa.edu> On Wed, 16 Jun 1999, Simon North wrote: > Andrew Wheeler asked about tools for adding textual definitions to > a DTD ... > > Andrew, I use Earl Hood's DTD2HTML Perl package. It allows you > to create a navigable set of HTML pages from the DTD. Each > element and each attribute gets its own page, and they can all be Another option is EZDTD, anther shareware which gives the option of XML, SGML, or HTML (with comments) output of the DTD. It's nice, slim in size, and does the job also. J.R. Gardner, Ph.D. Obermann Center for Advanced Studies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Wed Jun 16 17:02:39 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:13:09 2004 Subject: X-Schema Message-ID: <805C62F55FFAD1118D0800805FBB428D0106AF3F@cc20exch2.mobility.com> David Megginson [mailto:david@megginson.com] writes: > Paul Prescod writes: > > > I am genuinely interested in improving XML usability, however, so I > > would like to hear counter-arguments. > > In my opinion, the best counter argument is that you can include > structured documentation as part of the schema itself. In a DTD, an > awful lot of useful information is stashed away in comments, and has > to be copied into documentation using cut-and-paste. > > > All the best, > > > David If I could throw in a point which is scarily reminiscent of the DOM+CSS vs. XSLT and XSL-FO debate, I'm a little worried that we're inventing two languages which do exactly the same thing. Or rather, we've <em>got</em> one language, and we're inventing <em>another one</em> to do the same thing. Now in most cases, having multiple languages is a Very Good Thing. (e.g. I happen to love C++, but use Visual Basic almost exclusively for what I do. And I'm itching to use more Java, so I will when I get the chance.) However, in this case, when Schemas become a recommendation are all XML parsers going to have to know how to validate against DTDs as well as Schemas? Are we going to have some parsers that only understand DTDs and some that only understand Schemas? Are DTDs going to become obsoleted, if Schemas can do everything they can do and more? If so, what happens to all of the existing XML documents with DTDs? Do we re-write them? Don't get me wrong, I happen to like Schemas much better than DTDs, and the data typing alone makes them a better choice for many things. I'm just wondering if we wouldn't be better off adding the extra functionality to DTDs, instead of creating a new language. Are there technical reasons why we can't? (Does it have something to do with SGML compatibility? If so I'd be willing to shut up right now. :-) David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jun 16 17:20:34 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:13:10 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <37677C4D.EE569E1E@prescod.net> References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> Message-ID: <199906161522.LAA22347@hesketh.net> At 06:28 AM 6/16/99 -0400, Paul Prescod wrote: >Having done this process right, for a sophisticated document type, it is >highly unlikely that you will be able to display your documents directly >using CSS. Graphics will cause a problem. Cross references will cause a >severe problem. Navigational mechanisms will be lacking...and so forth. > >Therefore you cannot just stick the XML file and a CSS stylesheet on your >website. You must dumb down the XML somehow -- to HTML or to some weakly >semantic variant that has redundant cross reference text, redundant >navigational mechanisms, HTML-compatible IMG tags and so forth. > >Without some client-side transformational mechanism (either XSL or the >DOM), CSS *discourages* the distribution of rich semantic information >because it requires you to dumb down your data. I'm afraid - in my opinion at least - that this is a gross underestimation of the capabilities of CSS. While CSS does not at present provide an easy way to display graphics, this is: a) easy to add b) dependent on XLink, which is thus far a no-show. Navigational mechanisms and cross references have similar dependencies on XLink, but I see no reason why they should cause 'severe problems'. It's not there yet, mostly because XLink isn't there yet, but these are hardly significant barriers. If you want, we can put this part of the discussion back on www-style, and see what people come up with. Unlike formatting objects, I think this is quite solvable. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jun 16 17:24:13 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:13:10 2004 Subject: XSL and the semantic web In-Reply-To: <37677C57.315E5210@prescod.net> References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> Message-ID: <199906161526.LAA22488@hesketh.net> At 06:28 AM 6/16/99 -0400, Paul Prescod wrote: >In other words I always interpreted it as being about choice. You complain >that XSL allows this choice. Even if it were the case that XSL uniquely >allowed data dumbing (which it is not), I could not see how its allowance >of this choice would constitute a problem or flaw. Data dumbing is part of >the economy and ecology of the Web. As Guy Murphy has described, the Web >is richer for it. Do we want Lexis-Nexis to take their thousands of >databases back to their private network where they controlled the level of >semantics tightly? I'm afraid we'll have to accept the value of this 'choice' as a fundamental disagreement. I feel strongly that by encouraging this choice, and by providing a vocabulary that is even more formatting-oriented than HTML, XSL encourages a greater level of server-side dumbing down than was available before, and makes it easier. I can't see this as a positive move in any light, and no, I don't see the 'semantic firewall' as a positive thing for the Web. But then, I do see the Web from a rather different perspective than Lexis-Nexis. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Wed Jun 16 17:33:17 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:13:10 2004 Subject: X-Schema Message-ID: <01BEB81E.5619E5A0@grappa.ito.tu-darmstadt.de> David Hunter wrote: > I'm just > wondering if we wouldn't be better off adding the extra functionality to > DTDs, instead of creating a new language. Are there technical reasons why > we can't? (Does it have something to do with SGML compatibility? If so I'd > be willing to shut up right now. :-) There are certainly no technical barriers to enhancing DTDs. As you point out, though, SGML compatibility is a barrier. Mostly it's always struck me as a matter of practicality: there are very few DTD writers and readers compared to the number of document writers and readers. Hence, the market is most likely to lean towards documents, not DTDs. If we redefine/extend DTDs as documents (i.e. schemas), we get to use all the document technology and tools for free. If we work solely on DTDs, we have to reinvent everything ourselves: SAX for DTDs, DOM for DTDs, XSLT for DTDs, editors for DTDs, etc. As to DTDs becoming obsolete, I view this as very unlikely to occur any time soon. More likely are two things: 1) Parsers that can translate between DTDs and schemas on the fly so that it becomes unimportant whether a document has one or the other, and 2) Separate modules that can validate documents against a schema for use in environments where the parser either can't validate or can't validate against a DTD. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Jun 16 17:32:19 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:10 2004 Subject: CSS and XML attributes References: <002201beb7d4$64199320$2500a8c0@hto.citec.fi> Message-ID: <3767C407.1E7E6291@pacbell.net> Heikki Toivonen wrote: > > > what do I write in my style sheet to display product id in the > > following example? > > > > <PRODUCT ID="C07981"> .... </PRODUCT> > > With CSS you can use the :before and :after rules, and specify in the > content property that it should display the attribute value of an attribute > named ID (my terminology may not be per the spec but hope you understand). > > Here is a sample: > > PRODUCT:before { > content: attr(ID); > } > > Note that not all products support CSS well enough to understand this. FYI those transformations are from CSS2, not CSS1 ... CSS2 is less well supported, and basically should be until vendors first handle all of CSS1. http://www.w3.org/TR/REC-CSS2/generate.html Followup puzzler: Suppose I want the output of this to embed attribute values in some particular location, rather than put it before (or after) the other content associated with that particular element. Can that be done with CSS1 or CSS2 ? (I know it can be done with XSL-T!) - Dae xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jun 16 17:44:40 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:13:10 2004 Subject: Transformation versus annotation In-Reply-To: <37677C4E.930AE7AC@prescod.net> References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> Message-ID: <199906161546.LAA23440@hesketh.net> At 06:28 AM 6/16/99 -0400, Paul Prescod wrote: >XSL FOs do not disrupt the "original" element type names. They still exist >in the original document that was the source of the transformation. The result, however, looks nothing like the original. >> See above. Transformations to an endpoint that still had as much semantics >> as the original - formatting properties represented as attributes rather >> than elements - might have avoided lots of the 'considered harmful' issues >> that you want to ignore. I think inclusion and sequence are the only large >> problems such an approach presents, and I don't think they're insoluble. > >They are insoluable. The whole point of transformations: whether XSLT or >DOM is that they are *arbitrarily sophisticated*. That means that I can >have a very loose binding between markup and presentation. That means that >I can invest in my expensive information assets without worrying about the >presentational technologies of the day. I'm not convinced that arbitrarily sophisticated is required by the vast majority of cases - and I'm definitely not convinced that inclusion and sequence in particular are insoluble. We already have a tool - DOM+Scripting - that is capable of providing arbitrarily sophisticated transformations, and document composition (rather than transformation per se) addresses many needs that are remarkably complex while allowing developers to use the frameworks of their choice. >Do you propose that after 15 years of failure we now have the ability to >make style languages in the annotation model that can solve the many >common (common!) problems of this sort? What follows is a remarkably negative message. Your underestimation of the capabilities of CSS (expressed in a previous message) is severe, your willingness to declare problems insoluble is remarkable. Perhaps it's just that you've admitted that: >Nobody solved the FOs considered harmful problems because they are >*insoluable*. and you now have to declare a wide variety of alternatives insoluble. Annotation by itself may not be up to every task, but annotation with a minimal level of transformation (starting even with :before and :after, which we already have) seems capable of addressing the vast majority of tasks. It's not a matter of reinventing everything; it's more a matter of finding solvable issues and fixing them. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Jun 16 17:57:07 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:10 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> <199906161522.LAA22347@hesketh.net> Message-ID: <3767C9B0.B37D5E56@pacbell.net> "Simon St.Laurent" wrote: > > At 06:28 AM 6/16/99 -0400, Paul Prescod wrote: > > > >Without some client-side transformational mechanism (either XSL or the > >DOM), CSS *discourages* the distribution of rich semantic information > >because it requires you to dumb down your data. > > I'm afraid - in my opinion at least - that this is a gross underestimation > of the capabilities of CSS. While CSS does not at present provide an easy > way to display graphics, ... Graphics weren't even a point I heard there. Here are two concrete examples: - Just seen on this list ... data found in attribute values must often be displayed. If you stick to CSS1, you must often dumb down the data so that it can be displayed. CSS2 gives you an option to dumb down the display to present such values before or after the element to which they're attached; but there's no way to access "inherited" attributes, to embed them in more semantically appropriate places. - Using either version of CSS, all the context-based linking needs to be dumbed down by making it all be explicit, since CSS only deals with explicit content. One of the basic roles of transformation is to make the implicit become explicit: links that are created by the structure of the data. or groupings of similar data. Headings join a TOC, index entries are indexed, figures and tables are listed, and so on. Yes, it's true that CSS alone doesn't let you handle what the HTML "<img src='...'/>" and "<a href='...'>...</a>" elements do ... or "<table>" (till CSS2 happens) and others. But even for content that doesn't require those sorts of presentation, you can see the "dumbing down" effect when you transform the content from "semantic markup" to "XML that CSS can render". - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Jun 16 18:20:14 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:10 2004 Subject: XSL and the semantic web References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> <199906161526.LAA22488@hesketh.net> Message-ID: <3767CF1C.503A6E9A@pacbell.net> "Simon St.Laurent" wrote: > > At 06:28 AM 6/16/99 -0400, Paul Prescod wrote: > >In other words I always interpreted it as being about choice. You complain > >that XSL allows this choice. Even if it were the case that XSL uniquely > >allowed data dumbing (which it is not), I could not see how its allowance > >of this choice would constitute a problem or flaw. Data dumbing is part of > >the economy and ecology of the Web. As Guy Murphy has described, the Web > >is richer for it. Do we want Lexis-Nexis to take their thousands of > >databases back to their private network where they controlled the level of > >semantics tightly? > > I'm afraid we'll have to accept the value of this 'choice' as a fundamental > disagreement. I feel strongly that by encouraging this choice, and by > providing a vocabulary that is even more formatting-oriented than HTML, XSL > encourages a greater level of server-side dumbing down than was available > before, and makes it easier. I can't see this as a positive move in any > light, I can, quite easily. I give examples below. And one more: you appear to be assuming that the client actually has enough horsepower and information to do the transformation (or for the FO side of the argument, formatting) ... those are known to be false assumptions in many cases. A PDA with a typical speed IR link (not measured in megabits), slow CPU, and small fixed size storage just doesn't have that kind of resources. For many set-top boxes, ditto. > and no, I don't see the 'semantic firewall' as a positive thing for > the Web. Hmm ... do you see them as issues in other contexts? Information is transformed routinely, every day. Frankly, I don't want to to be getting a complete history of everyone's life every time I deal with them; I'm happier to work with the current context (far smaller!). That sort of time/history based "semantic firewall" is very useful, for all that it's subject to abuse by all parties. There are others; if I browse a product description, rarely will I want complete technical specs, and if I do then I'll ask for them. I may want my technical books at a different level than someone else. Those are examples of transformations reducing the information that's presented. There are other transformations that can increase it; perhaps I want to look at a particular seller's history on an auction system before I buy from them, and not otherwise. If the semantic content is a "web" then anything short of looking at the whole web at once (yeah, right!) is looking through a "firewall". - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ejfreed at infocanvas.com Wed Jun 16 18:18:30 1999 From: ejfreed at infocanvas.com (Erik Freed) Date: Mon Jun 7 17:13:10 2004 Subject: X-Schema concerns In-Reply-To: <01BEB81E.5619E5A0@grappa.ito.tu-darmstadt.de> Message-ID: <006201beb814$5502dbe0$f5f6b5cf@evans.dnai.com> The latest arguments regarding the usefulness of XML schema languages versus DTDs are the most interesting. I have long used what are sometimes called 'reflective' object models, where the 'meta-data' can be thought of as a specialization of 'data'. This unified approach in my experience is more than a conceptual nicety, it provides long term implementation advantages. A single model for creation, storage, queries, fetches, modification, browsing, editing, translating, etc means that your large scale mature system is simpler to understand and has much less implementation code in it. For instance, the reflective system I have most recently constructed, has a browsing tool, where with only one tree view model, can browse through meta-data and data 'boundaries'. This unified approach, I find, pays off immediately in very practical terms. So while programming languages have long had a 'programming' language to handle meta-data constructs and a 'run-time' environment to handle data constructs, this separation is in fact an implementation choice, to support higher performance static executables. XML is not currently, and may never be, a high performance static approach, so why not enjoy the benefits? I heartily vote for moving quickly on getting meta-data into normal XML format and moving away from DTD's. On the other hand, I have major concerns regarding the current the XML-SCHEMA efforts. It reminds me a little of SQL3, where the spec has the 'kitchen sink' feel to it. This is for understandable and hard to resist reasons, but none the less a little scary. XML is or soon will be, the synthesis of the document and data modeling worlds. However the current efforts seem to me at least to be highly skewed towards document expertise, and the data modeling expertise is not as evident. I believe that the data modeling world, having to live in the rough and tumble of high performance large scale reliable delivered systems (object and relational environments/servers), has schema that are much less ambitious than the document world. I personally would start with a much simpler XML schema, implement carefully, live with the constraints, and slowly learn what is *required*, as opposed to what is conceptually interesting or complete. I have never seen a system that is that complex start serving a useful purpose quickly. cheers, erik xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jun 16 18:22:34 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:13:10 2004 Subject: XSL Debate, Leventhal responds to Stephen Deach In-Reply-To: <3767C9B0.B37D5E56@pacbell.net> References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> <199906161522.LAA22347@hesketh.net> Message-ID: <199906161624.MAA25061@hesketh.net> At 08:58 AM 6/16/99 -0700, David Brownell wrote: >Yes, it's true that CSS alone doesn't let you handle what >the HTML "<img src='...'/>" and "<a href='...'>...</a>" elements >do ... or "<table>" (till CSS2 happens) and others. But even >for content that doesn't require those sorts of presentation, >you can see the "dumbing down" effect when you transform the >content from "semantic markup" to "XML that CSS can render". To some extent, you're right, and I've acknowledged that CSS could use some _simple_ transformative mechanisms (plus support from XLink) to accomplish some of these tasks, or you could just use the DOM+Scripting, which I think is a reasonable approach to these kinds of problems. However, I think a fundamental point that both you and Paul are missing here is that even _if_ you have to reorganize your document so that CSS can display it easily, the impact of that 'dumbing down' is much less dramatic than the impact of transformation to formatting objects or XSL. It's a smaller project that creates less dramatic problems. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Jun 16 18:29:56 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:13:10 2004 Subject: XSL and the semantic web In-Reply-To: <3767CF1C.503A6E9A@pacbell.net> References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> <199906161526.LAA22488@hesketh.net> Message-ID: <199906161631.MAA25356@hesketh.net> At 09:21 AM 6/16/99 -0700, David Brownell wrote: >And one more: you appear to be assuming that the client actually >has enough horsepower and information to do the transformation (or >for the FO side of the argument, formatting) ... those are known >to be false assumptions in many cases. A PDA with a typical speed >IR link (not measured in megabits), slow CPU, and small fixed size >storage just doesn't have that kind of resources. For many set-top >boxes, ditto. Maybe it's just that I'm at JavaOne, where Sun and 3Com keep talking about what you can do with Java on a Pilot, but I see the bandwidth as more of a problem than the processing power. It might well make sense to create some kind of PDA middleware that slims down content before shipping it to the PDA, but that seems more a matter of consumer-oriented content-negotiation than producer-determined semantic firewalling. >Hmm ... do you see them as issues in other contexts? Information >is transformed routinely, every day. Frankly, I don't want to to be >getting a complete history of everyone's life every time I deal with >them; I'm happier to work with the current context (far smaller!). >That sort of time/history based "semantic firewall" is very useful, >for all that it's subject to abuse by all parties. > >There are others; if I browse a product description, rarely will I >want complete technical specs, and if I do then I'll ask for them. >I may want my technical books at a different level than someone else. > >Those are examples of transformations reducing the information >that's presented. There are other transformations that can increase >it; perhaps I want to look at a particular seller's history on an >auction system before I buy from them, and not otherwise. > >If the semantic content is a "web" then anything short of looking at >the whole web at once (yeah, right!) is looking through a "firewall". In all of these cases, I have a very simple question: do you want to be able to choose the level of semantic information you receive, or do you want that to be determined by your provider? I have no object to intelligent content-negotiation. I do have a problem with handing content producers new tools for creating dumbed-down content with XML, the very language that was supposed to improve the level of information quality on the Web. Simon St.Laurent XML: A Primer / Building XML Applications Inside XML DTDs: Scientific and Technical (July) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 16 18:38:11 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:13:10 2004 Subject: XSL and the semantic web References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> <199906161526.LAA22488@hesketh.net> <3767CF1C.503A6E9A@pacbell.net> Message-ID: <3767D367.3652F792@locke.ccil.org> David Brownell wrote: > Hmm ... do you see them as issues in other contexts? Information > is transformed routinely, every day. Frankly, I don't want to to be > getting a complete history of everyone's life every time I deal with > them; I'm happier to work with the current context (far smaller!). > That sort of time/history based "semantic firewall" is very useful, > for all that it's subject to abuse by all parties. [other examples snipped] > If the semantic content is a "web" then anything short of looking at > the whole web at once (yeah, right!) is looking through a "firewall". There is a fundamental difference between providing a multiplicity of views and creating a semantic firewall. Providing source and binary is a multiplicity of views. Providing binary only is a firewall. Providing source only is not a firewall, because compilers are freely available (free speech, not free beer). Providing hard copy and soft copy is a multiplicity. Providing hard copy only is a firewall. Providing HTML rather than XML, or PDF rather than HTML, are firewalls. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Wed Jun 16 18:49:33 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:13:10 2004 Subject: XSL and the semantic web Message-ID: <c=US%a=_%p=Cromwell_Media%l=ODIN-990616164745Z-83211@odin.cromwellmedia.co.uk> John Cowan wrote, > Providing source and binary is a multiplicity of > views. Providing binary only is a firewall. > Providing source only is not a firewall, because > compilers are freely available (free speech, not free > beer). > > Providing hard copy and soft copy is a multiplicity. > Providing hard copy only is a firewall. > > Providing HTML rather than XML, or PDF rather than > HTML, are firewalls. This analogy is actually quite dangerous to your position. Typists are freely available (free speech, not free beer). As long as the semantic info is available (hardcopy or HTML crud) it can be transcribed. Copyright/IP problems? Presumably ditto for unauthorized use of information presented in a machine accessible way. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 16 19:03:12 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:13:11 2004 Subject: XSL and the semantic web References: <c=US%a=_%p=Cromwell_Media%l=ODIN-990616164745Z-83211@odin.cromwellmedia.co.uk> Message-ID: <3767D93E.8D2AA607@locke.ccil.org> Miles Sabin wrote: > This analogy is actually quite dangerous to your > position. Typists are freely available (free speech, > not free beer). As long as the semantic info is > available (hardcopy or HTML crud) it can be > transcribed. Typists can regenerate the surface form, but not the lost semantic markup. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Wed Jun 16 19:20:02 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:13:11 2004 Subject: XSL and the semantic web Message-ID: <c=US%a=_%p=Cromwell_Media%l=ODIN-990616171749Z-83228@odin.cromwellmedia.co.uk> John Cowan wrote, > Miles Sabin wrote: > > This analogy is actually quite dangerous to your > > position. Typists are freely available (free speech, > > not free beer). As long as the semantic info is > > available (hardcopy or HTML crud) it can be > > transcribed. > > Typists can regenerate the surface form, but not the > lost semantic markup. Are you sure about that? Granted they _might_ not be able to restore the semantic markup that was placed there by the originator (tho' I think they might well be able to infer a lot of it in many cases: remember they're people not machines). But in any case, do we necessarily _care_ about the originators markup? Yes, if their idea of what's significant matches ours, but not necessarily otherwise. So our typists, or maybe 'knowledge engineers', add the markup _we_ want. A dreadful prospect, I agree, and clearly contrary to the spirit of the semantic web, but, I'm afraid it looks to be pretty much consistent with your open/closed source analogy (which was the only thing I was quibbling about BTW). Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Wed Jun 16 19:30:57 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:13:11 2004 Subject: CSS and XML attributes Message-ID: <93CB64052F94D211BC5D0010A800133170EF0B@wwmess3.bra01.icl.co.uk> > Please read the subject line before replying with an XSL solution. I grovel abjectly. I read the subject line three microseconds after pressing SEND. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jun 16 19:44:35 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:13:11 2004 Subject: Message-ID: <5BF896CAFE8DD111812400805F1991F708AAF755@RED-MSG-08> You need to put a certain processing instruction in your XML document. See http://msdn.microsoft.com/xml/xslguide/browsing-sspi.asp -----Original Message----- From: Puppala Satyanarayana S [mailto:swamis@wipsys.stph.net] Sent: Wednesday, June 16, 1999 8:03 AM To: xml-dev@ic.ac.uk Subject: This might be a basic question to you. But its really a big problem for me. I just started learning xml. I wrote a xml document which is valid(I mean i have a DTD for it). I wrote a XSL file for this xml document.Now i tried to view the xml file in IE5 browser. But , only the source code of the document was displayed, even the tags were displayed. Whether there is any problem with IE5. The IE5 i downloaded was a Beta version. Is there any other in which i can view my xml document? Can anyone help me? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Jun 16 19:50:43 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:11 2004 Subject: XSL and the semantic web References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> <199906161526.LAA22488@hesketh.net> <199906161631.MAA25356@hesketh.net> Message-ID: <3767E453.BCF73AF0@pacbell.net> "Simon St.Laurent" wrote: > > At 09:21 AM 6/16/99 -0700, David Brownell wrote: > >And one more: you appear to be assuming that the client actually > >has enough horsepower and information to do the transformation (or > >for the FO side of the argument, formatting) ... those are known > >to be false assumptions in many cases. A PDA with a typical speed > >IR link (not measured in megabits), slow CPU, and small fixed size > >storage just doesn't have that kind of resources. For many set-top > >boxes, ditto. > > Maybe it's just that I'm at JavaOne, where Sun and 3Com keep talking about > what you can do with Java on a Pilot, but I see the bandwidth as more of a > problem than the processing power. It might well make sense to create some > kind of PDA middleware that slims down content before shipping it to the > PDA, but that seems more a matter of consumer-oriented content-negotiation > than producer-determined semantic firewalling. Well, I was one of the first folk to publicly articulate that particular strategy on JavaSoft's behalf (almost two years ago now!) so I'm well familiar with the notion. But I don't see ANY difference betwen that and semantic firewalling. After all, isn't "content negotiation" just saying "firewall me away from these sorts of semantic I can't deal with"? And isn't the firewalling you object to just the provider's constraints showing up in the negotiation? > >If the semantic content is a "web" then anything short of looking at > >the whole web at once (yeah, right!) is looking through a "firewall". > > In all of these cases, I have a very simple question: do you want to be > able to choose the level of semantic information you receive, or do you > want that to be determined by your provider? Yes. The provider must of necessity choose how to respond to my particular choice. If I don't like that response, I can choose to request a different "level" (or probably "type") of information. This isn't an either/or question, and there are a variety of reasons providers may not be permitted to share certain data. Privacy guarantees are one example (financial, medical, etc), but aren't the only one by far! If the original content has data that isn't allowed to be shared except in "aggregate", then there may well be legal firewalls in place. There's a huge web ... and nobody has more than one little window onto it. > I have no object to > intelligent content-negotiation. I do have a problem with handing content > producers new tools for creating dumbed-down content with XML, the very > language that was supposed to improve the level of information quality on > the Web. "Improve" is a standard that different folk apply differently. For example, if I manage an account database, it's an "improvement" to me if I can use the "Extensible" Markup Language to share parts of it, for use in particular workflow processes. If I understand things, you're saying at one extreme that providing preformatted data (e.g. FOs to render a report) is a Bad Thing. And at the other extreme, maybe, that sharing anything less than the whole content of an account record is also a Bad Thing. In both cases the "client" should make those choices. I guess it just comes from my perspective in systems design, but I just can't accept that clients "should" be that smart. If I provide a report on a delinquent account, I don't want anyone else to be able to hide important bits so they can claim in court that they didn't get notice. If I share data with a partner, I may want to limit the amount of analysis they can perform on that (to protect my business). How much work to put on a client and a server is always a tricky issue, but it's safe to say that for every task that _could_ be offloaded from the server onto a client, there will in some cases be nontechnical policies (legal, business strategy, etc) forcing them to stay on the server. Ditto technical ones, as in the example I gave of clients that are too low-powered to do the work. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Jun 16 20:01:57 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:11 2004 Subject: XSL and the semantic web References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> <199906161526.LAA22488@hesketh.net> <3767CF1C.503A6E9A@pacbell.net> <3767D367.3652F792@locke.ccil.org> Message-ID: <3767E6FD.1F832312@pacbell.net> John Cowan wrote: > > David Brownell wrote: > > > If the semantic content is a "web" then anything short of looking at > > the whole web at once (yeah, right!) is looking through a "firewall". > > There is a fundamental difference between providing a multiplicity > of views and creating a semantic firewall. I think you're agreeing with me, then, when you say that providing only one "view" is a firewall. The example you give of "source only" (v. "binary only") not being a firewall supports what I said too -- since that's an example of looking at the "whole web", for an extremely restrictive view of "web". If I were to attach some source code to this message, it wouldn't really be sufficient _in itself_ to present a web. You'd need to know something about its platform environment to compile or execute it -- more of its web. You'd need to know something about its intent to choose whether to try -- more of its web. Perhaps you'd need to understand the language(s) it used -- more of its web. And so on. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 16 20:49:28 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:13:11 2004 Subject: XSL and the semantic web References: <c=US%a=_%p=Cromwell_Media%l=ODIN-990616171749Z-83228@odin.cromwellmedia.co.uk> Message-ID: <3767F22A.D5699192@locke.ccil.org> Miles Sabin wrote: > > Typists can regenerate the surface form, but not the > > lost semantic markup. > > Are you sure about that? Granted they _might_ not be > able to restore the semantic markup that was placed > there by the originator [...] That's a quibble. The *original* semantic markup is lost, even if someone can supply *new* semantic markup that just-so-happens to be the same. Note: supplying one form is not a firewall if it is not a dumbed-down form. Source code is not a firewall, obfuscated source code is a firewall. See http://www.opensource.org/osd.html . -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From daved at aeroinfo.com Wed Jun 16 21:13:48 1999 From: daved at aeroinfo.com (Dave Dieno) Date: Mon Jun 7 17:13:11 2004 Subject: ISO SGML character mapping entities sets Message-ID: <3712D74A03A7D011BD120060973262512578E0@aeroinfo.com> Does anyone know if the ISO SGML character mapping entities sets such as: <!ENTITY % ISOnum PUBLIC "ISO 8879-1986//ENTITIES Numeric and Special Graphic//EN"> have been ported to XML to remove the SDATA entities and updated with Unicode characters? For example from the ISOnum SGML entity set: <!ENTITY ldquo SDATA "[ldquo ]"--=double quotation mark, left--> Is converted to the XML equivalent: <!ENTITY ldquo "“"> Thanks, Dave Dieno Aeroinfo Systems Inc. http://www.aeroinfo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From l-arcini at uniandes.edu.co Wed Jun 16 21:22:24 1999 From: l-arcini at uniandes.edu.co (F.A.A.) Date: Mon Jun 7 17:13:11 2004 Subject: Corba and XML Message-ID: <000201beb82e$00ca0ac0$3705fd9d@preferred-user> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 5665 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990616/f67cf77e/attachment.gif From cowan at locke.ccil.org Wed Jun 16 21:31:45 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:13:11 2004 Subject: ISO SGML character mapping entities sets References: <3712D74A03A7D011BD120060973262512578E0@aeroinfo.com> Message-ID: <3767FC14.8516F599@locke.ccil.org> Dave Dieno wrote: > Does anyone know if the ISO SGML character mapping entities sets such as: > > <!ENTITY % ISOnum PUBLIC "ISO 8879-1986//ENTITIES Numeric and Special > Graphic//EN"> The table at ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MISC/SGML.TXT , composed by yours truly, contains essentially all the information you'd need to make XML versions of various ISO entity sets, including ISOnum. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Wed Jun 16 22:24:20 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:13:11 2004 Subject: Corba and XML In-Reply-To: <000201beb82e$00ca0ac0$3705fd9d@preferred-user> References: <000201beb82e$00ca0ac0$3705fd9d@preferred-user> Message-ID: <wkemjb7uzs.fsf@ifi.uio.no> * F. A. A. | | could you please help me out with some useful pointers to some kind | of marriage between corba and XML? maybe some sort of xml2idl, maybe | marshalling using xml? The XML-RPC people already do marshalling with XML, although not in a CORBA context. (This makes sense, since if you have CORBA IIOP is much more attractive for various reasons, one of which is speed.) <URL: http://frontier.userland.com/tree$2.8.2.1> Also, the OMG has recently issued a specification they call XMI, which provides a mapping from an OMG information model to an XML DTD. You can find the specification on the OMG site. (My copy is still in the to-be-read heap, unfortunately.) Personally, I'm currently doing an MSc thesis on what CORBA and SGML/XML may have to contribute to one another in the context of building publishing systems. I hope to complete that thesis in the very near future. If you're interested you can come to Metastructures '99 to hear me talk about it. :) | ------=_NextPart_000_0013_01BEB322.E7F362E0 | Content-Type: image/gif | Content-Transfer-Encoding: base64 | Content-ID: <000b01beb34c$d019f100$0100007f@preferred-user> | | R0lGODlh/wNdAPf/AP///4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v | 7/f3987GxtbOzt7W1r21ta2lpbWtrca9vZyUlKWcnMa9td7WztbOxr21rc7Gvefezt7Wxt7Wve/v | 5/f37///987OxtbWzt7e1ufn3r29ta2tpbW1rcbGvZSUjJyclKWlnIyMhN7ezufn1u/v3tbWxr29 What's this? --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ejfreed at infocanvas.com Wed Jun 16 22:48:50 1999 From: ejfreed at infocanvas.com (Erik Freed) Date: Mon Jun 7 17:13:11 2004 Subject: X-Schema concerns In-Reply-To: <199906162016.NAA24425@netcom17.netcom.com> Message-ID: <009001beb83a$2d94c110$f5f6b5cf@evans.dnai.com> Hi Dave, The exact terms are ones that reasonable people can (and do) disagree on. So these terms are not advertised as authoritative, but to me one perspective is as follows: Level 0 the data environment has no idea what its own meta-data is Level 1 the data environment can somehow get meta-data information Level 2 The meta-data for a system is modeled in its own data (ie a class is an object) Level 3 The meta-data for a system is dynamically modeled in its own data (it can change at run-time) For instance you could add a completely different type of semantic property to a type, and have meta-data be based on it. Level 4 The meta-data for a system is dynamically modeled in its own data and boots from this definition. Various systems over the years have achieved various levels in various ways. There are other possible levels for other combinations of capabilities. Java for instance could be claimed to be level 2 (except no-one writes java code programmatically) and perhaps level 3 if you allow the system to compile and load new classes. (that would be pushing it) Level 3 and 4 require interesting chicken and egg boot procedures. I really do not know where this sort of thing is discussed except implicitly and explicitly in the proceedings of special interest groups such as ACM and IEEE. There are probably books out there but I cannot recommend any specifically. XML is interesting in that since it is very dynamic in both its meta-data and data dimensions, it has the possibility of supporting higher level more open and extendable systems. The XML system I am writing will be level 4. It will boot its first class object definitions, from an XML-SCHEMA definition, with the schema reader being essentially a bootstrap program. At run-time however the model can be changed and extended. good luck! erik -----Original Message----- From: G. David Kuhlman [mailto:dkuhlman@netcom.com] Sent: Wednesday, June 16, 1999 1:17 PM To: ejfreed@infocanvas.com Subject: Re: X-Schema concerns > > > The latest arguments regarding the usefulness of XML schema languages versus > DTDs are the most interesting. I have long used what are sometimes called > 'reflective' object models, where the 'meta-data' can be thought of as a > specialization of 'data'. This unified approach in my experience is more > than a conceptual nicety, it provides long term implementation advantages. A > single model for creation, storage, queries, fetches, modification, > browsing, editing, translating, etc means that your large scale mature > system is simpler to understand and has much less implementation code in it. > For instance, the reflective system I have most recently constructed, has a > browsing tool, where with only one tree view model, can browse through > meta-data and data 'boundaries'. This unified approach, I find, pays off > immediately in very practical terms. I'm interested in understanding what you call the "'reflective' object models". Can you suggest a resource or reference where I could learn more about it? Even hints and suggestions would be helpful. The application I work on edits objects that have an XML representation (along with others). I'm guessing that our application would benefit from the ability to deal with objects that are self describing and that help tell the object editor how to display and modify them. Am I a little bit on track here? In the future, when more and more of the objects in our applications have an XML representation, then the ability of objects to describe themselves and the ability to annotate an XSchema with information that helps an editor (and possibly other tools as well) will become more helpful and useful. Thanks for any pointers and help. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Wed Jun 16 23:41:17 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:13:11 2004 Subject: More CDATA questions Message-ID: <87256792.00775487.00@d53mta03h.boulder.ibm.com> This has probably been dealt with somewhere else, but I don't remember it right off hand so I'll ask at the possibility of being redundant... Glenn brought this up and we didn't have any really feeling for the answer (other than what we guesstimated.) Is CDATA effectively the same as an entity reference except that its in place? I.e. is it basically just a blob of text which, once seen will have the bracketting gorp removed and the characters will be taken as character data of the enclosing element? Part of the reason for this question is to straighten out a possible ambiguity in our parsers. We have an ignorable whitespace callback and a characters callback on the document handler. Each of them has an 'isCDATA' parameter that indicates whether the chars/ws being passed out in the event came from a CDATA section or not. So, if I see this: <foo> <![CDATA[ ]]> </foo> should the spaces inside the CDATA be treated as either ignorable whitespace or characters according to the normal processing rules for a CHILDREN element? Or is there any way in which the content of the CDATA section would be treated differently? Would, for instance, it always be considered characters because its not just 'accidental whitespace'? Its obviously not just whitespace that happens to be in the content of the element, it was purposefully put into the element content to be treated 'as is'. OTOH, this would be technically illegal if it were treated as anything besides ignorable whitespace because the content model is CHILDREN. I guess part of the question is that are the contents of CDATA sections REALLY not passed judgement on, as you would think from the spec, or are they just KIND OF NOT REALLY passed judgement on? If you really just take the CDATA content as is, then you really shouldn't have to find out if they are all whitespace and deal with the validity issues of the content model. But, if you don't, then they could put non-ws characters in the content model of something that had CHILDREN or MIXED models. Am I making any sense 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From marcelo at mds.rmit.edu.au Thu Jun 17 02:14:06 1999 From: marcelo at mds.rmit.edu.au (Marcelo Cantos) Date: Mon Jun 7 17:13:12 2004 Subject: XSL and the semantic web In-Reply-To: <3767CF1C.503A6E9A@pacbell.net>; from David Brownell on Wed, Jun 16, 1999 at 09:21:48AM -0700 References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> <199906161526.LAA22488@hesketh.net> <3767CF1C.503A6E9A@pacbell.net> Message-ID: <19990617101522.A3103@io.mds.rmit.edu.au> On Wed, Jun 16, 1999 at 09:21:48AM -0700, David Brownell wrote: > "Simon St.Laurent" wrote: > > > > At 06:28 AM 6/16/99 -0400, Paul Prescod wrote: > > >In other words I always interpreted it as being about choice. You complain > > >that XSL allows this choice. Even if it were the case that XSL uniquely > > >allowed data dumbing (which it is not), I could not see how its allowance > > >of this choice would constitute a problem or flaw. Data dumbing is part of > > >the economy and ecology of the Web. As Guy Murphy has described, the Web > > >is richer for it. Do we want Lexis-Nexis to take their thousands of > > >databases back to their private network where they controlled the level of > > >semantics tightly? > > > > I'm afraid we'll have to accept the value of this 'choice' as a fundamental > > disagreement. I feel strongly that by encouraging this choice, and by > > providing a vocabulary that is even more formatting-oriented than HTML, XSL > > encourages a greater level of server-side dumbing down than was available > > before, and makes it easier. I can't see this as a positive move in any > > light, > > I can, quite easily. I give examples below. > > And one more: you appear to be assuming that the client actually > has enough horsepower and information to do the transformation (or > for the FO side of the argument, formatting) ... those are known > to be false assumptions in many cases. A PDA with a typical speed > IR link (not measured in megabits), slow CPU, and small fixed size > storage just doesn't have that kind of resources. For many set-top > boxes, ditto. > > > > and no, I don't see the 'semantic firewall' as a positive thing for > > the Web. > > Hmm ... do you see them as issues in other contexts? Information > is transformed routinely, every day. Frankly, I don't want to to be > getting a complete history of everyone's life every time I deal with > them; I'm happier to work with the current context (far smaller!). > That sort of time/history based "semantic firewall" is very useful, > for all that it's subject to abuse by all parties. > > There are others; if I browse a product description, rarely will I > want complete technical specs, and if I do then I'll ask for them. > I may want my technical books at a different level than someone else. > > Those are examples of transformations reducing the information > that's presented. There are other transformations that can increase > it; perhaps I want to look at a particular seller's history on an > auction system before I buy from them, and not otherwise. > > If the semantic content is a "web" then anything short of looking at > the whole web at once (yeah, right!) is looking through a "firewall". I'm a little confused, and I think it relates to a degree of confusion between formatting and transformation (XSL/XTL?). My understanding is that Simon et al object to the use of server XSL to provide formatted output to the client. Paul suggests that this is a good thing because it gives the owner of the data choice in what to make available to the user. David then provides some examples to back up this argument. My problem with all this is that the cases-in-point that David supplies (embedded systems notwithstanding, though they really are a separate issue in my opinion) are all more appropriately dealt with by transforming the data rather than formatting it (in fact, David even refers to it as such). But this is not, as far as I understand it, what Simon is objecting to. There is no-one, as far as I can tell, arguing that there is anything wrong with pruning the tree. The issue centers on whether it is appropriate to present only the formatted output to the client. I have no strong views on whether this is a good or a bad thing (having no experience at all with using XML/SGML browsers in a production environment), but it does seem to me that the participants are arguing across each other and not really getting to this central point of contention. This whole issue seems to me to provide a post hoc rationale for splitting XSL in two: XTL at the server and XSL at the client. Finally, I offer my most humble apologies to anyone whom I have misrepresented (and to everyone if I have misunderstood the debate). My sole intention is to offer what meagre help I can in keeping this most interesting discussion flowing. Cheers, Marcelo -- http://www.simdb.com/~marcelo/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Jun 17 05:00:06 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:13:12 2004 Subject: Inline markup considered harmful? References: <Pine.GSO.3.96.990613150422.18839B-100000@grind> Message-ID: <3768645B.1D5D@hiwaay.net> Robin Cover wrote: > > at the > level I experience the Web via HTTP/HTML, a heap of broken > links, it's massively and profoundly broken by design. That > "people use it" is quite unremarkable, Is it? I think it remarkable that we have these debates yet have never met. I find the fact that I can sit at home changing mandolin strings rather than attending a meeting in San Jose to move a spec five paragraphs further and still be reading the New York Times remarkable. However we consider the design of HTTP/HTML or any simpler email system, that fact that they work is a testimony to engineering practice. If they fall short of theoretical elegance, it's OK by me as long as I can still change these strings. :-) > Ted's judgment probably seems harsh because he measures a thing > against its potential -- not just by "nothing is proven to work > better than..." It works and it works for lots of people. Quod Erat Something. At the end of the working day, that is an accomplishment. As for inline markup being harmful, it certainly can be just as inline RTF is a PIA. OTOH, it can also work marvelously well and in a simple way. The fact is, the means and skills to parse an undifferentiated blob of text, find the whitespace, find the linefeeds and embedded carriage returns, build a thesaurus, code the logic for finding the exceptions for disambiguating semantic meaning, and so on is waaaay beyond far too many people who are responsible for gathering, classifying, and assigning linking information to text. For these folks, there are tools such as markup. It is a tool; not a cancer. > That he may himself be judged a failure as > compared (e.g.,) to Bill Gates is no doubt the common verdict. He goes beyond facts into beliefs about what is best for everyone's information resources. Many of us have statements like that somewhere in the archives. All I am saying is that calling markup a cancer is hyperbole. It is a less than ideal but better than UTF-8 way of getting certain jobs done that Ted did not do. Those that did do it did a good job. No Latin; just, thanks for the relief so I don't have to do it. Can the web work better? Sure. But we don't get to find out without applying our experience and trying out our ideas. Whatever else we do, we get to do that here. How many folks get to work on Xanadu? > In referencing his brilliance, I was speaking from a different > reference point, and different set of values, where > measurement by counting companies acquired, companies brought > to IPO, and 'successful' software products delivered (etc.) has > no currency. MS didn't invent this. They took advantage of it just like everyone, and I do mean everyone, else. So? Let 'em. Working software beats the heck out of systems that are always just one more revision from being released. See Babbage. If we are still worried about chaining up our information, well, if that virus last week didn't do anything else, it sure made me organize the paper in the file cabinet. Tedious to use, but not zero-length at the whim of someone who thought it would be a clever stunt to wipe files for some holy cause to release me from my MS chains. Jeez. That help the InfoMustBeFree Warriors can keep. > Among Ted's gifts, some would say, is an unusual > ability to damn mediocrity by identifying it and labeling it > so plainly that it hurts. Something else I hope I have learned: I can't educate by hurting that which doesn't learn from pain. It's just more pain. This is as true of Gates as it is of Ted: whatever they have, they have because they want it. Me, I am a mediocre mind; I just want to change the strings on my guitar next. If this is the cry of someone who has lost their higher aspirations, so be it. Those who listen get better sound. This isn't, worse is better; it is something for someone. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 17 04:59:54 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:13:12 2004 Subject: Top-down or bottom-up? References: <199906111513.LAA27001@hesketh.net> <E10sSdc-0001iC-00@romeo.ic.ac.uk> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> <14180.64662.493404.927680@localhost.localdomain> <3765B35D.EF0886F9@prescod.net> <14182.23225.319557.152831@localhost.localdomain> Message-ID: <376854EC.6835@hiwaay.net> David Megginson wrote: > > That's not what I mean -- creating a data model is tractable, but a > data model is of questionable value if it's not based on a fairly > accurate business model, use cases, etc. I don't think that any of us > can reasonably draw up a reliable business model that will cover the > Web for the next five years, and even the use cases will be pretty > shakey. Without good models, bottom-up is our best bet. Umm.. isn't that why we do markup and write DTDs? They may not last forever, but like mudbricks that cleave, they make a reasonable structure and, well, beat the heck out of fighting bears for caves. We can always resort to "things change; why bother?" We bother because we get more done when we agree to what is to be done and the means and tools for doing it. We make contracts. For some years now, some have referred to DTDs as contract-validated communications. It works as long as parties agree, and agreements get renegotitated. What some refer to as bottom up is responding to local requirements with local means. Global requirements can also be met with local means but may not work for long. Global requirements met with global means may not work any longer. Say, ok good for people, not good enough for machines? I disagree. It may not be good enough for certain chores, but good for enough chores gets enough done. The fact is, you make a model, watch the output at every loop, and adjust. If it means a new model, then the old model taught you what to look for to know when it wasn't working. We can talk endlessly about the meta-models needed to keep that knowledge and so on, but eventually, we run out of time, mental stack space, whatever. Exhaustion or no achievements. no roof? Pooped out and broken but dry is better. There is no best bet. There is practice that works until it fails and what you design to cope with failure. The problem of SGML, XML, and markup in general is the futile attempt of some to permanently capture process by static means. It is always at best, a snapshot. That is OK. A snapshot is all you need to make comparisons. Used like that, seen without the moral obligations to build edifices for the greater glory of some One, markup works great. Even an instamatic takes a good picture if the hand and eye are talented. Take a block of marble and hack, and you get rock. The art is in the eye. If I learned nothing from CALS, SGML, HyTime, etc., I hope I learned that our tools are just tools to be wielded by hands. Every DTD written so far is being modified by human hands, or languishes somewhere in a thousand page tome. Every mudbrick house needs patching or is buried in sand somewhere waiting for Ozymandias to return. Still, better than the caves. 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Jun 17 06:15:19 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:12 2004 Subject: More CDATA questions References: <87256792.00775487.00@d53mta03h.boulder.ibm.com> Message-ID: <376876DA.797C6040@pacbell.net> roddey@us.ibm.com wrote: > > Is CDATA effectively the same as an entity reference No -- CDATA is characters. Entity reference is "contents" which may be characters, but may also have elements, nested references, and more. > except that its in place? > I.e. is it basically just a blob of text which, once seen will > have the > bracketting gorp removed and the characters will be taken as > character data of > the enclosing element? Just characters ... which isn't the same as an entity ref. > if I see this: > > <foo> > <![CDATA[ ]]> > </foo> > > should the spaces inside the CDATA be treated as either ignorable > whitespace or > characters according to the normal processing rules for a CHILDREN > element? Treated as characters. There was some discussion here a few months back on this topic, initiated by Henry S. Thompson. It should be in the archives (sometime before February). The OASIS test suite in consequence has a case for this; I recall putting Henry's case into that collection of tests, after it seemed there was agreement. > I guess part of the question is that are the contents of CDATA > sections REALLY > not passed judgement on, as you would think from the spec, Really! ;-) - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dirkg at tectrade.be Thu Jun 17 11:40:05 1999 From: dirkg at tectrade.be (Dirk Germonpre) Date: Mon Jun 7 17:13:12 2004 Subject: supporting unicode in XML tools Message-ID: <3.0.6.32.19990617113836.00976d20@relay.tectrade.be> Hello, I'm going to write some XML tools. How can I support both UTF-8 and UTF-16 at the same time? Am I better of writing XML software in C++ or Java with respect to supporting unicode? Thanks in advance. ---------------------------------- Dirk Germonpr? - dirkg@tectrade.be Tectrade NV Pieter de Conincklaan 33 B-8200 Brugge Belgium xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dirkg at tectrade.be Thu Jun 17 12:28:57 1999 From: dirkg at tectrade.be (Dirk Germonpre) Date: Mon Jun 7 17:13:12 2004 Subject: detecting character set of an XML doc Message-ID: <3.0.6.32.19990617122656.00977a10@relay.tectrade.be> Hello, If I'm writing an XML tool, how can I detect what character set is used for an XML document? I've read that for UTF-16, an encoding signature (xFEFF) is used at the beginning of the document. Is there a different encoding signature for each character set? If so, where can I find documentation on this? Where can I find encoders and decoders for C++ to convert to and from unicode? Thanks in advance. ---------------------------------- Dirk Germonpr? - dirkg@tectrade.be Tectrade NV Pieter de Conincklaan 33 B-8200 Brugge Belgium xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Thu Jun 17 12:54:58 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:13:12 2004 Subject: detecting character set of an XML doc Message-ID: <01BEB8C0.94B05BD0@grappa.ito.tu-darmstadt.de> Dirk Germonpre wrote: > If I'm writing an XML tool, how can I detect what character set is used for > an XML document? I've read that for UTF-16, an encoding signature (xFEFF) > is used at the beginning of the document. Is there a different encoding > signature for each character set? If so, where can I find documentation on > this? See Appendix F of the XML spec. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ketil at ii.uib.no Thu Jun 17 12:58:57 1999 From: ketil at ii.uib.no (Ketil Z Malde) Date: Mon Jun 7 17:13:12 2004 Subject: Storing application state as XML Message-ID: <KETIL-86yahjdoxo.fsf@ketilboks.bgo.nera.no> Hi, I must admit I don't have the time to follow this list as diligently as I'd like, so it is possible that my questions have been answered already. I'll submit them nevertheless. :-) We have a rather complex application which stores its state using the standard MFC serialize stuff (well, actually a somewhat hacked version, but that's beside the point). Now, this limits our freedom in (or at least severely complicates) redesigning internal class structure while maintaining backwards file compatibility, and we've been pondering an XML format instead. There are of course other advantages, like accessing the information from other applications, or generating HTML and whatnot. The question is whether this, in general, is a good idea, and whether people have done this, and if so, to what degree of success, and by what methods. I can see two ways of doing this: 1) Use a DOM-based document, which can be passed around, much the way a CArchive class is, and modifying the Serialize() to fill in the relevant nodes in the document tree or 2) Encapsulating the document (DOM or otherwise) in a separate class, which traverses the application's classes and picks whatever information is relevant in whatever sequence it desires. The advantage of model 1 is a structure quite similar to what already exists, most of the code base could be left alone, I think. On the other hand, if our existing classes are well designed, all the relevant information should be accessible through the public: interfaces, and it should be easier to build the document in a flexible way. E.g. the placement of various information might not be obvious from the class' perspective. So, before we jump the gun, I'd like to hear from people who have done this, and are willing to share their experiences, or otherwise contribute suggestions and ideas. Thanks for listening, -kzm -- If I haven't seen further, it is by standing in the footprints of giants xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Thu Jun 17 13:18:43 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:13:12 2004 Subject: detecting character set of an XML doc Message-ID: <5F052F2A01FBD11184F00008C7A4A800022A19B4@eukbant101.ericsson.se> > -----Original Message----- > From: Dirk Germonpre [SMTP:dirkg@tectrade.be] > > Hello, > > If I'm writing an XML tool, how can I detect what character set is used > for > an XML document? I've read that for UTF-16, an encoding signature (xFEFF) > is used at the beginning of the document. Is there a different encoding > signature for each character set? > Not each "character set" - but each encoding, yes. They all exhibit different binary signatures, otherwise they would be the same... :) > If so, where can I find documentation on this? You can start with the XML spec, appendix B (I think it's B) contains some brief information. Or John Cowan posted a C decoder which detected the most common ones, or you can find my perl Apache module on CPAN, which detects the character sets and encoding. Matt. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jlangdon at copeland.com Thu Jun 17 14:53:05 1999 From: jlangdon at copeland.com (Jeff Langdon) Date: Mon Jun 7 17:13:12 2004 Subject: Building the "World's Largest Portal" with XML Message-ID: <85256793.0046AC59.00@mail.copeland.com> FYI... Did anybody else get this annoying solicitation? Is this person just pulling names off the mailing lists? Please excuse the cross posting Jeff Langdon Senior Web Developer The Copeland Companies Cathey Cotten <cathey@metasearchinc.com> on 06/16/99 06:36:40 PM To: Jeff Langdon/IT/The Copeland Companies@The Copeland Companies cc: Subject: Building the "World's Largest Portal" with XML My name is Cathey Cotten. I am the Founder of MetaSearch Inc., one of the Bay Area's leading Technology Industry Search Firms. I have recently had an opportunity to review an overview you had written with regard to XML technology and I was wondering if you would be interested in entertaining career opportunities. MetaSearch is a consulting firm specialized in staffing experts for pre-IPO start-ups in electronic commerce and knowledge management. These players are well positioned for the marketplace in their respective fields. As such, the value proposition that most offer to our candidates is an aggressive salary, a challenging environment and pre-IPO equity. As XML is fast becoming the standard Web specification, many of our clients are using it to build their e-commerce businesses. One of our current clients is building a truly exciting fast-paced electronic-commerce project that will be one of the "World's Largest Portals" with the expectation of 250 Million Hits and over a Billion page views per day! This project is working in conjunction with several companies and nations. Not only will you be working with some of the Internet's "heavy hitters" ... you will be building a portal for a great cause. The project will include streaming of live events and world-wide simulcasts both on radio and television. We are also working with a pre-ipo "start-up" head quartered in Silicon Valley. This company develops business-to-business electronic commerce software products and services that automate business transactions and collaborative processes in the supply chain. These applications enable participation/collaboration of the supply channel in material planning/forecast, quote and procurement management, engineering change management, new product introduction, flow-through distribution, logistics integration, and other business processes. In addition to the realization of tremendous cost savings, reduction in cycle times and errors, and increased efficiencies and gains in productivity, these applications enable companies to source, manufacture, and ship on a global level. I would like an opportunity to speak with you to discuss in more detail your experience, career aspirations, and current requirements. I invite you to visit our web site at www.metasearchinc.com to familiarize yourself both with our firm and with the current open positions. If you are not entertaining new opportunities at this time would you kindly send a simple reply to this E-mail to that effect. Thank you. I can be reached at 415.256.2970. I look forward to speaking with you soon. Best regards, Cathey __________________________________________________________ Beatrice Murch Communications Manager MetaSearch Inc. Post Office Box 129 San Anselmo, CA 94960, USA Voice: 415.256.2970 Data: 415.256.2979 http://www.metasearchinc.com ____________________________________________________________ MetaSearch focuses on one of the most critical challenges for technology managers today...locating the best talent available to build dynamic teams. We are committed to assisting emerging technology companies hire world-class, high-performance contributors in software development, sales, marketing and operations. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From malliks at rocketmail.com Thu Jun 17 16:07:30 1999 From: malliks at rocketmail.com (Mallikarjuna Sangappa) Date: Mon Jun 7 17:13:12 2004 Subject: Nested DTDs Message-ID: <19990617140812.29723.rocketmail@web4.rocketmail.com> Hi Everyone, Is it possible to have nested DTDs. If so I would like to have samples. Its pretty urgent. Thanks in advance. CU, Malliks _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Jun 17 16:25:39 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:13:12 2004 Subject: Namespace URI address resources Message-ID: <004c01beb8c5$80812d10$35f96d8c@NT.JELLIFFE.COM.AU> From: Mark Birbeck <Mark.Birbeck@iedigital.net> >Rick Jelliffe wrote: >> A schema is "processing" not "data": it is tied to whatever >> applications >> understand the schema format. Editing, creating and >> validating against a >> schema are all applications. > > As far as I can see, one point of the schema proposal is to >be functionally equivalent to a DTD with a few obvious advantages, one >of these being that if we get the definition right, each node can >specify its own schema. What you gain on the swing you lose on the roundabout. I have been using Adobe's EDD system for several years for defining document structures: it allows syntax directed editing of the schema, tree views, rich text comments, nicely formatted direct export to HTML and PDF, linking to styles, pre- text and post-text and hard coding of flow objects (if you want). I like it, but I still prefer DTDs. The XML Schema Structure draft was disappointing to me: DTD syntax is given a great leap forward (i.e., superficial but nice) from 70's syntax (macros) to 80's syntax (objects) and a couple of things from HyTime get twisted and added like a balloon poodle. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at metalab.unc.edu Thu Jun 17 16:31:42 1999 From: elharo at metalab.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:13:12 2004 Subject: Building the "World's Largest Portal" with XML In-Reply-To: <85256793.0046AC59.00@mail.copeland.com> Message-ID: <v03102806b38eb6de314b@[168.100.203.234]> At 8:55 AM -0400 6/17/99, Jeff Langdon wrote: >FYI... > >Did anybody else get this annoying solicitation? > >Is this person just pulling names off the mailing lists? > >Please excuse the cross posting > I got it too. Given the way it was worded, I thought it was a more specific solicitaion from somebody who'd read my book but I guess not. I'll dump it in the recycle bin with all the other recruiter spam. (And recruiters wonder why I don't want to deal with them and insist on dealing only with principals...) +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | XML: Extensible Markup Language (IDG Books 1998) | | http://www.amazon.com/exec/obidos/ISBN=0764531999/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://sunsite.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://sunsite.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Jun 17 16:42:29 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:13:12 2004 Subject: XSL and the semantic web References: <199906111851.OAA05005@hesketh.net> <199906141411.KAA11113@hesketh.net> <199906161526.LAA22488@hesketh.net> <3767CF1C.503A6E9A@pacbell.net> <19990617101522.A3103@io.mds.rmit.edu.au> Message-ID: <376909AA.A17D32D0@pacbell.net> Marcelo Cantos wrote: > > On Wed, Jun 16, 1999 at 09:21:48AM -0700, David Brownell wrote: > > > If the semantic content is a "web" then anything short of looking at > > the whole web at once (yeah, right!) is looking through a "firewall". > > I'm a little confused, and I think it relates to a degree of confusion > between formatting and transformation (XSL/XTL?). > > My understanding is that Simon et al object to the use of server XSL > to provide formatted output to the client. Paul suggests that this is > a good thing because it gives the owner of the data choice in what to > make available to the user. David then provides some examples to back > up this argument. Actually, I gave more general examples too ... when you transform the data in any way (not only turning into "formatted" output like HTML, FOs, etc) you may be preventing "clients" from seeing data that some may want to be able to see. > My problem with all this is that the cases-in-point that David > supplies (embedded systems notwithstanding, though they really are a > separate issue in my opinion) are all more appropriately dealt with by > transforming the data rather than formatting it (in fact, David even > refers to it as such). But this is not, as far as I understand it, > what Simon is objecting to. I see all of those transformations as points on a spectrum, and the note I responded to didn't seem to be restricted to XSL FOs; it didn't mention FOs or formatting, as I recall. (I was concerned about whether the discussion lost some context, too!) Turning data into presentation-only data is just another transform, in any case, for all that it's a bit more apparent how much was removed. Clients don't generally have any "right" to see that extra data. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Jun 17 16:50:57 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:13:12 2004 Subject: Namespace URI address resources Message-ID: <005301beb8c9$1a2aea70$35f96d8c@NT.JELLIFFE.COM.AU> From: David Megginson <david@megginson.com> >Murray Maloney writes: > > > Well. Maybe meta-data, but a schema is simply declarative. > > It does not perform any processing. Editing, creating and > > validating are all applications. So what? > >Schemas and stylesheets are both declarative, and both include >information that can be acted on by processors. In the case of a >schema, the result is a truth value (valid/not valid) and, optionally, >a transformation (supplying default values, etc.); in the case of a >stylesheet, the result is a transformation or rendition. I think that this exchange reveals the central confusion that people have. If the editor of the Information Set draft and the editor of the Schema draft still are feeling around the issue of a schema, what hope for the rest of us :-) They are both exceptional men, but it shows that there is lot of room for community discussion. Murray views schemas largely as the patterns by which documents are constructed (or "described"). David views schemas as a specifications for validation. It is quite possible to build languages which do both, but the result may be mediocre. Xeena is OK but it is not great--even Adobe's brilliant DTD-to-EDD transformations leaves a lot of things out that are worthwhile for building. In my view, DTDs are definitely validation schemas: they are a big fat assert() statements bundled with other header information. A schema that would be useful for document construction should include human-readable comments, the ability of one attribute to enable another, specifying the end types of reference, etc. Newbies ask predictable questions about structures; the draft has not addressed those questions. A language validation should be some selection of the schema patterns expressed as (possibly weaker) constraints and delivered in a very terse form. There was a great book on parsing called "Syntax, Structures, Schemes, Semantics, Verification". It seems that people use "schema" interchangably for any of these different things. The XML Schema draft seems to be a "construction" schema for database documents and simple untyped hypertext documents. It is certainly not a validation suited for documents with structures outside tree structures, and it is not suited for client-end validation unless there are no bandwidth issues. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Jun 17 16:59:11 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:13:13 2004 Subject: Advice on DTD's Message-ID: <006401beb8ca$37a33520$35f96d8c@NT.JELLIFFE.COM.AU> From: Andrew Wheeler <akwheel@talos.org> >I am currently working for client that has developed a data model and is >using an XML DTD to describe it. ...We would like to >produce the DTD without comments for applications, and some other output >that would document the hierarchical structure of the DTD but with added >bonus of clicking on a element and getting a description for it (We do >not really want to spend time writing bespoke code, which we have to >maintain). Err...what about HTML? You write the DTD in an HTML editor with some JavaScript popup links on each interesting keyword. To generate the text version of the DTD, SaveAs... to text. You can hypertext link to any part of the DTD and you don't need to buy any tools, or sit around waiting for future DTD-in-instance-schema tools to be marketed. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jun 17 17:02:32 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:13 2004 Subject: Top-down or bottom-up? In-Reply-To: <376854EC.6835@hiwaay.net> References: <199906111513.LAA27001@hesketh.net> <E10sSdc-0001iC-00@romeo.ic.ac.uk> <199906111325.JAA21943@hesketh.net> <032201beb404$f6b46940$0b2e249b@fileroom.Synapse> <199906111608.MAA29936@hesketh.net> <37626FCB.457EF174@prescod.net> <14180.64662.493404.927680@localhost.localdomain> <3765B35D.EF0886F9@prescod.net> <14182.23225.319557.152831@localhost.localdomain> <376854EC.6835@hiwaay.net> Message-ID: <14185.3218.512310.594578@localhost.localdomain> Len Bullard writes: > > That's not what I mean -- creating a data model is tractable, but a > > data model is of questionable value if it's not based on a fairly > > accurate business model, use cases, etc. I don't think that any of us > > can reasonably draw up a reliable business model that will cover the > > Web for the next five years, and even the use cases will be pretty > > shakey. Without good models, bottom-up is our best bet. > > Umm.. isn't that why we do markup and write DTDs? They may not > last forever, but like mudbricks that cleave, they make a > reasonable structure and, well, beat the heck out of fighting bears > for caves. Just so, but imagine if we had all waited to start writing DTDs until ISO approved a master document architecture that would govern all DTDs in the SGML and XML document space (kudos to HyTime for trying, though). This is the point that I (and others) have been making in this discussion: a top-down approach (start with the master architecture) can work for something like a new parts-management system for ACME.com; a bottom-up approach (start with the components, such as individual specs and DTDs) is pretty much required in an open and fast-changing system like the Web. As Paul Prescod has pointed out, however, in both cases the process is really iterative: in a bottom-up approach, it's often useful to stop and throw together a straw-man architecture to see if what we've done so far makes sense together; in a top-down approach, it's often useful to stop and throw together some proof-of-concept components, to see if there will be any obvious implementation problems. The difference comes simply from which of the two is formalized. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murray at muzmo.com Thu Jun 17 17:03:49 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:13:13 2004 Subject: Namespace URI address resources In-Reply-To: <01BEB807.0420E8A0@grappa.ito.tu-darmstadt.de> Message-ID: <3.0.1.32.19990617110408.0196b308@mail.muzmo.com> At 02:46 PM 6/16/99 +0200, Ronald Bourret wrote: >My apologies for the sarcasm, but although I find the use of namespace URIs >to find schemas a wonderful theoretical idea, I'm having more than a little >trouble seeing how it could possibly work in practice. > Come work with Commerce One and we'll show you. ---------------------------------------------------------- Murray Maloney, Esq. Phone: (905) 509-9120 Muzmo Communication Inc. Fax: (905) 509-8637 671 Cowan Circle Email: murray@muzmo.com Pickering, Ontario Web: http://www.muzmo.com Canada, L1W 3K6 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 17 17:15:51 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:13:13 2004 Subject: Namespace URI address resources In-Reply-To: <005301beb8c9$1a2aea70$35f96d8c@NT.JELLIFFE.COM.AU> References: <005301beb8c9$1a2aea70$35f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <14185.4221.583529.316510@localhost.localdomain> Rick Jelliffe writes: > A schema that would be useful for document construction should > include human-readable comments, the ability of one attribute to > enable another, specifying the end types of reference, etc. > Newbies ask predictable questions about structures; the draft has > not addressed those questions. Rick makes a very good point -- the schema requirements for authoring and validation/processing are very different. Additional complexity comes from the fact that there is also an n:n relationship also between authoring and processing schemas: a document created using any given authoring schema may match n validation schemas, and vice-versa. The main point, I think, is that it would be a mistake to try to force any kind of 1:1 relationship onto XML documents and their schemas/stylesheets, etc. by using the Namespace URI to locate a single, canonical schema. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Jun 17 17:14:01 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:13:13 2004 Subject: ISO SGML character mapping entities sets Message-ID: <008f01beb8cc$4526ea50$35f96d8c@NT.JELLIFFE.COM.AU> From: Dave Dieno <daved@aeroinfo.com> >Does anyone know if the ISO SGML character mapping entities sets such as: > ><!ENTITY % ISOnum PUBLIC "ISO 8879-1986//ENTITIES Numeric and Special >Graphic//EN"> > >have been ported to XML to remove the SDATA entities and updated with >Unicode characters? They are available at http://www.ascc.net/xml/resource/entities/index.html By the way, could anyone who has mirrored these update them to the most recent versions. I get a couple of complaints per month about errors that are long fixed. Also, there is a technical question I have for everyone: what is the preferred entity value for the percnt entity? I now have <!ENTITY percnt "&#37;" ><!--=percent sign--> SGML'86 validators do not pick up the following WF errror: <!ENTITY percnt "%" ><!--=percent sign--> Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Thu Jun 17 17:46:08 1999 From: jborden at mediaone.net (Jonathan Borden) Date: Mon Jun 7 17:13:13 2004 Subject: Namespace URI address resources Message-ID: <027601beb8d7$809488d0$0b2e249b@fileroom.Synapse> Murray Maloney wrote: >At 02:46 PM 6/16/99 +0200, Ronald Bourret wrote: >>My apologies for the sarcasm, but although I find the use of namespace URIs >>to find schemas a wonderful theoretical idea, I'm having more than a little >>trouble seeing how it could possibly work in practice. >> >Come work with Commerce One and we'll show you. > There is no doubt in my mind that using the namespace URI can work in many circumstances to locate a schema. There is also no doubt in my mind that a PI containing an href can also be used to locate a schema. The issue ought not be what has been done in pre-spec implementations rather what is the best way to do this for the future. The problem with using the namespace URI is that 1) it identifies a single resource 2) the location and protocol used to access the resource is hardcoded into the namespace and hence cannot be changed without causing fundamental changes to the structure of the entire document. 3) mechanisms to resolve URIs which are location and protocol indenpendent (e.g. "urn:xxx") are not widely available and hence cannot be used in practice. Jonathan Borden http://jabr.ne.mediaone.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Jun 17 18:02:06 1999 From: tbray at textuality.com (Tim Bray) Date: Mo