From jarle.stabell at dokpro.uio.no Mon Feb 1 00:04:20 1999 From: jarle.stabell at dokpro.uio.no (Jarle Stabell) Date: Mon Jun 7 17:08:21 2004 Subject: XML query engines Message-ID: <01BE4D7F.66BCB0E0.jarle.stabell@dokpro.uio.no> Glassbox wrote: > > >There exists a neat trick which enables simple SQL-Select queries answering > >for two given nodes, whether one is a subnode of the other, and also how > >many levels deep, in constant time, assuming you do some simple > >preprocessing on the structure. (Assigning two integers to each node in the > >tree). > > Can you please explain it precisely ? I will only do a very short explanation, or else I will be much too tired (and/or late) at work tomorrow! :-) (it's already Monday here) (But I think you either will understand it directly, or have some fun playing with the details, it's a simple and elegant idea.) The basic idea is to assign an interval (using a pair of integers) to each node, and assigning them such that Interval(n1) contains Interval(n2) if and only if n2 is a subnode of n1. Then you only need to do two integer compares in order to check whether a given node is a subnode of another. You can think of the interval of a parent node p as the union of all the intervals of the subnodes. (or projection) To assign the integers, you may start with assigning the "left" side of the root node the number 1 (or whatever!), and traverse the tree and increase the number as appropriate. (When you come to a leaf node, you assign both a "leftside" number and "rightside" number) (I believe different strategies for when to increase the number may give slightly different extra info when comparing the intervals of two nodes, but I don't remember whether the differences are substantial. You may increase by 1 on each "step".) Cheers, Jarle Stabell Digital Logikk AS xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 1 00:35:56 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:21 2004 Subject: XML query engines In-Reply-To: <01BE4D7F.66BCB0E0.jarle.stabell@dokpro.uio.no> from "Jarle Stabell" at Feb 1, 99 01:08:38 am Message-ID: <199902010124.UAA14220@locke.ccil.org> Jarle Stabell scripsit: > The basic idea is to assign an interval (using a pair of integers) to each > node, and assigning them such that Interval(n1) contains Interval(n2) if > and only if n2 is a subnode of n1. Or, equivalently: Assign a sequentially increasing number to each *tag* (start-tag or end-tag) in the document, treating an empty tag as a start-tag followed by an end-tag. Then e1 is a descendant of e2 iff e1.start > e2.start and e1.end < e2.end. Also, e1 is a left sibling of e2 (and e2 is a right sibling of e1) iff e1.end + 1 = e2.start; e1 is the leftmost child of e2 iff e1.start = e2.start + 1. Modeling the child/parent relationship is not so easy, and requires iteration. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Feb 1 00:53:33 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:21 2004 Subject: XML query engines Message-ID: <3.0.32.19990131165229.00b3dc30@pop.intergate.bc.ca> At 08:24 PM 1/31/99 +73900, John Cowan wrote: >Assign a sequentially increasing number to each *tag* (start-tag or end-tag) >in the document, treating an empty tag as a start-tag followed by an >end-tag. Then e1 is a descendant of e2 iff e1.start > e2.start >and e1.end < e2.end. Also, e1 is a left sibling of e2 (and e2 is >a right sibling of e1) iff e1.end + 1 = e2.start; e1 is the leftmost >child of e2 iff e1.start = e2.start + 1. Modeling the child/parent >relationship is not so easy, and requires iteration. This structure has all sorts of advantages; that's how the Open Text SGML-savvy search engine of yore used to run. Fast as hell, equal access to any & all elements without performance penalty. But hard to update. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Mon Feb 1 02:03:48 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:21 2004 Subject: XML query engines Message-ID: <002601be4d86$7b59ed40$c9a8a8c0@thing2> >Modeling the child/parent >relationship is not so easy, and requires iteration. Why not add a third number, depth? An element's children are those within range and with a depth 1 greater. (Speaking entirely from ignorance here--never learned SQL.) Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjaakkol at cs.Helsinki.FI Mon Feb 1 06:04:25 1999 From: jjaakkol at cs.Helsinki.FI (Jani Jaakkola) Date: Mon Jun 7 17:08:21 2004 Subject: XML query engines In-Reply-To: <3.0.32.19990131165229.00b3dc30@pop.intergate.bc.ca> Message-ID: On Sun, 31 Jan 1999, Tim Bray wrote: > This structure has all sorts of advantages; that's how the > Open Text SGML-savvy search engine of yore used to run. Fast as > hell, equal access to any & all elements without performance > penalty. That is also how sgrep works (the two integers are actually indexes in to the SGML/XML-files, but the idea is the same). > But hard to update. That too. - Jani xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 1 10:30:07 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:21 2004 Subject: Interesting Monday. Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136ADA@eukbant101.ericsson.se> Boy, you people sure can write when something stirs you up... It's 10:10am and I've only just got through my backlog of XML-Dev mail... Well, as the person who introduced the topic "Will XML eat the web?", I feel I should just add some points of note. I thank everyone who has contributed to this topic though. Firstly, I think there is still an issue with processing power and XML, although I can see that my system is poorly designed. Time for a rethink... The area where I can forsee potential problems is in e-commerce. Take an e-commerce transaction processing company that's moved to an XML transaction format. They don't have a shop web site, they just process credit card transactions for other sites. I imagine they are going to need to process hundreds of transactions per second. I don't for a second suggest that they store the XML as the primary data format (store it as a backup as suggested here) - it should immediately be put into an RDBMS. But to do that they have to parse each transaction. There's no caching that can go on here. Luckily that's their problem and not mine . My problem was slightly different. I needed to be ready for the 5.0 browsers (probably IE5, although I'd prefer NS5), and XML seemed ideal because we would be displaying/editing documents that look like data (or data that looks like a document if you like). We really needed an object database, but I needed to get moving quickly (a typical web project: "Can we have it yesterday"). Learning an object database wasn't a possibility. I already knew XML. So I looked at it like this - we could have it 2 ways: 1) Store XML now, process into HTML now, Transmit XML in the future. 2) Store in RDBMS now, process into HTML now, process into XML in the future. #1 looked like a nicer solution because it gives performance gains in the future, which #2 doesn't really (except perhaps XML is a lighter weight format to transmit than HTML). However this, it appears, is not the right way to go because RDBMS->*ML is always faster than XML->HTML. That's a lesson learned, and I thank you for it. Some of the points about caching are great when you're reading 1 XML file multiple times, but we're talking about 400 - 1000 XML files being accessed and constantly changed. A nicer solution would be an OODB. It's probably time to go shopping... Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 1 10:40:06 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:21 2004 Subject: Interesting Monday. Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136ADB@eukbant101.ericsson.se> I thought I should add: The topic "Will XML eat the web" was only designed to stir up interest. I certainly don't believe XML is doomed to failure. I've used it with fantastic success so far, aside from my speed issues. For example, it was a godsend in converting a database from MSSql to Postgresql. Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paagarwal at hss.hns.com Mon Feb 1 11:06:11 1999 From: paagarwal at hss.hns.com (parul agarwal) Date: Mon Jun 7 17:08:21 2004 Subject: XSL Draft? Message-ID: <01BE4E15.32F4B410.paagarwal@hss.hns.com> Hi, I am new to XML developers list. I was looking at XSL. Does any one have an idea on its status? Has it still not become a standard? It was proposed more than a year back. Are there existing stylers in the market? Thanks in anticipation Parul xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 1 11:39:49 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:21 2004 Subject: Compound Documents - necessary for success? Message-ID: <01BE4DDF.134A6140@grappa.ito.tu-darmstadt.de> Marcus Carr wrote: > With all due respect Roger, I think that the problem is that we're both asking > questions and with few exceptions, nobody's answering. In my own case, I assume > that this is due to the fact that: > > a) creating compound documents with fragments using the same DTD as the parent > may cause problems, but that there would always be a better way to handle such > documents, > > b) nobody's sure whether this will be a problem once XLink, XPointer, XML > Fragments and X?? have spun their magic, > > c) I've not clearly explained what I think the problem is, > > d) I'm missing the point so totally that nobody feels that it even merits a > reply, > I've been following this conversation with interest. I'll hazard two guesses for the lack of answers. First is (b) -- schemas and fragments are likely to answer some, but not all, of these questions. Second is that these questions are on or ahead of the bleeding edge, so it's not surprising that nobody has answers yet. I think that many of us have a notion of a "compound document" and "reusing schemas" but that, for most of us, these notions don't go much beyond the actual words and a hazy, utopic, AI-intensive dream that XML documents will somehow magically recombine themselves to solve all of our problems. Let's look at a simple example. Suppose we have a DTD for NBA players: Now suppose we also have a DTD for heights: What I think a lot of people would like is to automagically combine these two DTDs so that the following document is valid: Joe Tall Iowa Talls 3 meters This does not currently work for two reasons. First, there is no way to express that a document is valid under two different DTDs. Second, the above document is clearly not valid under either of the above DTDs. To create such a document under the current spec, we need to rewrite players.dtd: %height; There are two important things to notice here: 1) We got nothing for free. That is, we had to write a new DTD because we have a new file type, and the new file type (DTD) is different from either of the previous file types. In Roger's case, he needs to generate new DTDs dynamically, as was mentioned in an earlier message. 2) When we wrote the new DTD, a *human* made the decision about where was legal. Anybody figuring out a foolproof way for a machine to do this usefully -- that is, without defining the content model of all elements as ANY -- will probably get a Turing Award for AI. Without knowing much about fragments, it appears these have more to do with the delivery of pieces of an XML document rather than assembling and validating pieces from multiple documents. In particular, requirement 12 of the XML Fragement Interchange Requirements states that, "Issues involved with the possible "return" of any fragment to its original context and the determination of the possible validity of the "returned" fragment in its original context are beyond the scope of this activity." However, I have no doubt that the fragments project will turn up some interesting ideas about compound documents. In schema languages, the current state of the problem is to generalize the step: %height; That is, to define a general syntax that makes it easy to reuse parts (generally elements and attributes, but possibly any part) of other schemas without bringing in all of the second schema. This may not sound too exciting, but it is very useful. I personally think that anything more utopian than this is going to require, at the very least, a new definition of validity. One such definition was that proposed in this thread: that each subdocument is validated under its own DTD and the overall document is not validated but merely checked for well-formedness. This obviously is a specific case, but interesting nonetheless, as it suggests a useful application for partial validity. (As an aside, anybody figuring out an algorithm by which compound documents such as that shown above are "valid" under multiple DTDs and still work with existing tools would significantly advance the field. Personally, I'm not too hopeful.) So for the moment, don't be disappointed by the lack of answers. You're just ahead of us. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Mon Feb 1 14:16:57 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:21 2004 Subject: Another errata? Message-ID: <01BE4DF5.095E8BF0@grappa.ito.tu-darmstadt.de> Tim Bray wrote: > I repeat: in the sense the spec uses the word namespace, an unprefixed > attribute is NOT IN ANY NAMESPACE. I'm happy to live with this interpretation -- it's just that it comes as a complete surprise to me (and apparently to others as well). In this respect, how anybody can read A.2 and determine that prefixed attributes belong to a namespace and unprefixed attributes do not belong to a namespace is beyond me. One very important consequence of this interpretation is that namespace-aware applications need to be sure they don't look for namespace-prefixed local attribute names and namespace-aware SAX and DOM implementations need to be careful that the namespace name passed for local attributes is null. Although it's probably too late, a clarification would be welcome, especially since I can find nothing outside of A.2 that talks about whether attributes (prefixed or unprefixed) belong to a namespace. For example, the first paragraphs of 5.1 and 5.2 state that: "The namespace declaration is considered to apply to the element where it is specified and to all elements within the content of that element..." and: "A default namespace is considered to apply to the element where it is declared (if that element has no namespace prefix), and to all elements with no prefix within the content of that element. ... Note that default namespaces do not apply directly to attributes." This clarifies that default namespaces do not apply to attributes, but does not tell us anything about what does apply to attributes, prefixed or not. I suggest changing the first paragraph of 5.1 to the following: "The namespace declaration is considered to apply to the element **and all prefixed attributes** where it is specified and to all elements **and prefixed attributes** within the content of that element, unless overridden by another namespace declaration with the same NSAttName part. **Namespace declarations do not apply to unprefixed attributes.**" -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 1 14:24:29 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:21 2004 Subject: Namespace prefixes in attribute declarations Message-ID: <01BE4DF6.184018E0@grappa.ito.tu-darmstadt.de> According to the namespace spec, the following is legal: What does it mean and why is the prefix legal for the attribute? DTDs have no way to declare global attributes and local attributes are, by definition, unprefixed. Thus, it seems this declares a local attribute that can only be used as a global attribute: The only thing I can think of is so global attributes can be declared in and validated against XML 1.0 DTDs by declaring them on each element. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Feb 1 15:24:44 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:22 2004 Subject: SAX: Next Round (Lexical Event Handler) References: <199901202122.QAA00962@megginson.com> <36AA93F3.B98FAE05@jclark.com> <36B21948.5F74CEED@eng.sun.com> <14004.51695.816155.975439@localhost.localdomain> Message-ID: <36B5C88B.C903EF3D@locke.ccil.org> David Megginson scripsit: > Do we need the declarations, or just the boundaries -- or, in other > words, do we need to provide information about declared but unused > external parsed entities? Sorry I'm too lazy to puzzle this out from > the spec right now. The DOM is silent on the matter of completeness in general. In this case we are told that Entity objects model entities, not ENTITY declarations, so presumably a declared but unused entity would not be modeled. > > * expose values of defaults so that the DOM can ensure > > that defaulted attributes always have values; > > The parser should take care of this. > > > * distinguish attributes which were defaulted from those > > that were explicitly in the document. > > Yes, this is necessary, as a few others have also pointed out > (grumble, grumble). Unfortunately these items go together for DOM purposes, something I hadn't noted before. If the application removes an attribute that has a default but didn't use it, it is magically reinserted with the default value. So DOM builders need both the default and the actual value. (This also affects you-know-what.) > Probably -- the problem is that if we extend Parser then we'll have > both a setDocumentHandler and a setLexicalDocumentHandler event, and > that causes some funny problems that I'd rather punt. Not necessarily. setDocumentHandler could simply check if its argument is an instanceof LexicalDocumentHandler, thus making setLexicalDocumentHandler unnecessary. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Feb 1 15:51:21 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:22 2004 Subject: Namespace prefixes in attribute declarations References: <01BE4DF6.184018E0@grappa.ito.tu-darmstadt.de> Message-ID: <36B5CED9.DD3AEBBF@locke.ccil.org> Ronald Bourret wrote: > a:my_attribute CDATA #IMPLIED> > > What does it mean and why is the prefix legal for the attribute? DTDs have > no way to declare global attributes [...] Sure they do. There's just no way to declare them once and for all: the declaration must be repeated for every element, as here. Remember that "global attribute" does not mean "universally applicable attribute" but rather "attribute with (by convention) a universal meaning." > The only thing I can think of is so global attributes can be declared in > and validated against XML 1.0 DTDs by declaring them on each element. Just so. One might have a global attribute such as "iso4217:currency" that is applicable only to a few attributes in a particular DTD, those which represent money amounts. But its meaning would be universal: an ISO 4217 currency code. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Mon Feb 1 16:57:46 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:22 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) Message-ID: At 31 January 1999 20:33, W. Eliot Kimber wrote: > [In response to Mark Birbeck] > But you've not solved my problem, because the in-memory > abstraction of the > *document* is still: > > (xml-document > (data-instances > (element > (gi "person") > (content > (element > (gi "name") > (content > (literal "Eliot"))))))) > > So, while the result is closer to the abstraction of the > data, it is still > not the original abstraction. True. But I could have said: if that was a better model of the internal data. Maybe I've missed the subtlety of what you are saying the problem is, but in our system the attributes of an object are exported as described above, and the children of an object are exported as elements within other elements. Seems to me to mirror exactly our object structure - and so far we have been able to re-interpret DTDs back as data definitions. In other words, we *can* generalise the solution. > And note that even for an early-bound form, there are still > infinitely many > ways to construct it I still don't follow your logic - just because there are many ways to construct it, doesn't mean you can't construct it. > So no matter how you slice it, there will always be a > disjoint between the > abstraction of the serialization form and the abstraction of the data > objects being serialized, which means that a query onto the > abstraction of > the serialization will not be the same as a query onto the > abstraction of > the data that has been serialized. The gap might be bigger or > smaller, but > there will always be a gap. Sure. But I still have two issues. First, why would you query the serialisation anyway? Wouldn't you want to query your original database and generate XML pages that reflect the results? Even if you have serialised the data to XML files to speed up the movement of data, you would still want to do searches against the original data. (The nice thing about that - as a little aside - is that you create XML pages that are 'results' pages, ready for the user to drill down through, using whatever super-duper, 3D-helmet, speech-activated interface they have access to.) But second, and I think the main point, I don't understand why you are distinguishing between the XML representation of an object and its serialised form in the way you do? Why not just serialise and de-serialise between XML and the database? I know you ARE doing that, but the XML you are creating is some sort of 'normalised' representation of the original data. You keep talking of the 'abstract' representation of your data, but actually you are *losing* the abstraction, moving from: a person who has the name Eliot to an object which contains another object which has two properties, one set to name and the other set to Eliot Of course both are abstractions, but they model completely different things (data and people). And modelling the data rather than the person means you can no longer interchange your XML with other systems because you have two completely different sets of data, using different DTDs. (And you can't say that your serialisation schema *will* allow this interchange, because although your serialised data may be well-formed, the underlying data it represents may not be, so you need the proper DTD for the object.) > Which begs the question: if the abstraction of the document is not the > abstraction of the data, why bother to create and store the > abstraction of > the document when you can just as easily create and store the > abstraction > of the data? All I am saying is that the document *itself* could be the abstraction of the data. Anyway ... if I've missed the plot then I look forward to your clarification, since we are dealing with similar issues here. Regards, Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 1 17:12:16 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:08:22 2004 Subject: XSL Draft? In-Reply-To: <01BE4E15.32F4B410.paagarwal@hss.hns.com> References: <01BE4E15.32F4B410.paagarwal@hss.hns.com> Message-ID: * parul agarwal | | I am new to XML developers list. I was looking at XSL. Does any one | have an idea on its status? It's a Working Draft, and last I heard it was supposed to become a recommendation (that is, be finalized) this summer. | It was proposed more than a year back. Sure, but it wasn't expected to become a final recommendation until much later. The public drafts have been put out so that people can comment on them, and developing a standard like that takes its time. | Are there existing stylers in the market? Sure: However, any stylesheets you write may well have to change to reflect updates in the spec. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon Feb 1 17:16:42 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:22 2004 Subject: What is a good database for very large collections? (was Re: XSL/ECMAscript (was RE: Frontier as a scalable XML repository (was Re: Is XML dead already or what?)) Message-ID: <007a01be4e06$da6cb440$60f96d8c@NT.JELLIFFE.COM.AU> From: Simon St.Laurent >This thread(s) has proven more capable of shifting subjects than any I've >seen in a while ... Can I try to shift it back to a vital question asked earlier, but not answered? What is a good database for XML? The criteria are: * over 20, 000, 000 document fragments, each less than 256 characters, each with some flat metadata, able to be incrementally reloaded onto the live system * about simultaneous 30 users accessing about 10 fragments a minute each, grouped together (along with other dynamic data) and transformed, with a high need for immediate response * constant data-mining tools using various adhoc AI and linguitic retrieval software augmenting the metadata in the background. Rick xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Feb 1 17:30:47 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:22 2004 Subject: Another errata? References: <01BE4DF5.095E8BF0@grappa.ito.tu-darmstadt.de> Message-ID: <36B5E5DD.6F94FE4E@mecomnet.de> Up until the remark quoted below appeared, I had taken the namespace spec 'with grain of salt', and simply presumed matters would clear up eventually. If matters continue in this direction, however, there is a Ronald Bourret wrote: > > Tim Bray wrote: > > > I repeat: in the sense the spec uses the word namespace, an unprefixed > > attribute is NOT IN ANY NAMESPACE. > > I'm happy to live with this interpretation -- it's just that it comes as a > complete surprise to me (and apparently to others as well). In this > respect, how anybody can read A.2 and determine that prefixed attributes > belong to a namespace and unprefixed attributes do not belong to a > namespace is beyond me. While I could live with the assertion, I would, unfortunately, be unable to write useful software which conformed to it. If an "unprefixed attribute name" is really not in any namespace, then it would be impossible for application code to execute an affirmative comparison against the name, and it would be, for similar reasons, impossible to write xsl patterns which addressed the attribute. Are these consequences really intended? I would be very surprised if they were. An unqualified attribute name may be in a namespace with a unique structure, or in one which has a unique name form, but it should be in some namespace. Otherwise it's not possible to refer to an identifier more than once. I suggest that one take the spec at its word and propose that qualified attribute names are in exactly the namespace which the spec describes, that is, a namespace which has a two part name: the element identifier's uri and the element identifier's local part. This is straight forward. I can even imaging why one might want to do it. One alternative, that they are in the so-called "null" namespace, would be workable, but it contradicts much of the exposition in the spec. (see below for a qualification to this). Another alternative, that they are not in any namespace, means that a name cannot be repeated, which has very limited utility for something intended to be an encoding mechanism. > > One very important consequence of this interpretation is that > namespace-aware applications need to be sure they don't look for > namespace-prefixed local attribute names and namespace-aware SAX and DOM > implementations need to be careful that the namespace name passed for local > attributes is null. Since we've gotten this far, we should also be clear that a namespace with a null name is not identical to a null namespace. The "grain of salt" referred to above, is that I had been presuming that the spec meant the former where the latter appears. Perhaps someone can suggest another interpreation which makes sense. > ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Rudyard.Merriam at COMPAQ.com Mon Feb 1 17:38:31 1999 From: Rudyard.Merriam at COMPAQ.com (Merriam, Rudyard) Date: Mon Jun 7 17:08:22 2004 Subject: SNMP Message-ID: Does anyone know of an XML representation for SNMP MIBs? Rud Merriam KD5DTV 281-514-3252 rudyard.merriam@compaq.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Feb 1 17:43:03 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:22 2004 Subject: What is a good database for very large collections? In-Reply-To: <007a01be4e06$da6cb440$60f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <001c01be4e09$0955e950$d3228018@jabr.ne.mediaone.net> > > Can I try to shift it back to a vital question asked earlier, but not > answered? > > What is a good database for XML? > > The criteria are: > * over 20, 000, 000 document fragments, each less than 256 > characters, each with some flat metadata, able to be incrementally > reloaded onto the live system > * about simultaneous 30 users accessing about 10 fragments a minute > each, grouped together (along with other dynamic data) and transformed, > with a high need for immediate response How are the fragments selected? By query? If you can easily represent the 20M fragments in tabular form, and if you can easily represent the queries in SQL then a relational db is the way to go. this is not a particularly large, nor high-volume application for RDBMS. Ought you store the 20m fragments each in its own file ... probably not (a big waste). Ought you employ an ODBMS? not unless SQL wouldn't work well (you could always load it into say Oracle/SQL Server/DB2 etc vs. ODI/Poet etc and test it out). My expectation would be that if you need to run queries, the RDB will win. > * constant data-mining tools using various adhoc AI and linguitic > retrieval software augmenting the metadata in the background. > > Rick 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 1 17:43:18 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:22 2004 Subject: What is a good database for very large collections? (was ...) In-Reply-To: <007a01be4e06$da6cb440$60f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <199902011739.MAA10416@hesketh.net> (I'm responding in part to reduce the length of our crazy subject header) At 04:18 AM 2/2/99 +1100, Rick Jelliffe wrote: >Can I try to shift it back to a vital question asked earlier, but not >answered? > >What is a good database for XML? > >The criteria are: > * over 20, 000, 000 document fragments, each less than 256 >characters, each with some flat metadata, able to be incrementally >reloaded onto the live system > * about simultaneous 30 users accessing about 10 fragments a minute >each, grouped together (along with other dynamic data) and transformed, >with a high need for immediate response > * constant data-mining tools using various adhoc AI and linguitic >retrieval software augmenting the metadata in the background. Wow! That's quite a set of criteria, and looks almost nothing at all like my criteria, which are more like: * over 20,000 document fragments, ranging in length from 1 to 100,000 characters, all with some metadata, which will remain on the system in mostly stable form. * about 5 simultaneous authors, up to maybe a thousand people reading the information. * indexing and searching moving around in the background. Given these wildly different criteria (and I'm sure others out there have different ideas as well), the concept of a database for XML seems pretty weird. Maybe we should focus on tools for getting information into and out of a repository, and let vendors create different back ends created to match our widely differing needs. That way we can still share tools, and read each other's material, but aren't locked into a particular vendor whose approach won't work for everyone. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Feb 1 17:55:01 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:22 2004 Subject: Compound Documents - necessary for success? References: <01BE4DDF.134A6140@grappa.ito.tu-darmstadt.de> Message-ID: <36B5EB8E.972F351D@mecomnet.de> Ronald Bourret wrote: > ... > > 2) When we wrote the new DTD, a *human* made the decision about where > was legal. Anybody figuring out a foolproof way for a machine to > do this usefully -- that is, without defining the content model of all > elements as ANY -- will probably get a Turing Award for AI. > hmm, I've not been following this discussion, but, if one were to first treat the model as ANY - in order to be able to represent the domain, and then to examine the asserted elements, couldn't this be modeled as a straight-forward learning problem? > ... > I personally think that anything more utopian than this is going to > require, at the very least, a new definition of validity. One such > definition was that proposed in this thread: that each subdocument is > validated under its own DTD and the overall document is not validated but > merely checked for well-formedness. Which would require nothing more complicated in the encoding than an attribute to enable/disable validation on an element basis: validation="none" validation="content attributes", "content", "attributes" validation="element" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Mon Feb 1 18:02:08 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:22 2004 Subject: Interesting Monday. References: <5F052F2A01FBD11184F00008C7A4A80001136ADA@eukbant101.ericsson.se> Message-ID: <36B5EAE7.54EC8E70@infinet.com> "Matthew Sergeant (EML)" wrote: > Boy, you people sure can write when something stirs you up... It's 10:10am > and I've only just got through my backlog of XML-Dev mail... > > Well, as the person who introduced the topic "Will XML eat the web?", I feel > I should just add some points of note. I thank everyone who has contributed > to this topic though. > > Firstly, I think there is still an issue with processing power and XML, > although I can see that my system is poorly designed. Time for a rethink... > The area where I can forsee potential problems is in e-commerce. Take an > e-commerce transaction processing company that's moved to an XML transaction > format. They don't have a shop web site, they just process credit card > transactions for other sites. I imagine they are going to need to process > hundreds of transactions per second. I don't for a second suggest that they > store the XML as the primary data format (store it as a backup as suggested > here) - it should immediately be put into an RDBMS. But to do that they have > to parse each transaction. There's no caching that can go on here. There seems to be a major misconception here I think in terms of what software needs to do for businesses. The issue for XML I think should be scalability, not just raw speed. What use is the XML/XSL architecture if it costs mucho deneiro in development dollars for fly-by-night consultants, overpriced databases, and application servers. Maybe some giant bank has money to burn, but the average web-shop if they are even profitable is running their business on very thin margins. Raw performance of using XML is not what should be the focus here, simplicity should be the focus. Using XML for backup or log files is not a bad use of XML. In fact it is a very simple use of XML to do some very simple things. What major benefit is XML other than through some document API like the DOM if it is stored in the DBMS. Are you going to have the DBMS construct an XML stream on the fly which then needs to be reparsed into some in-memory data structure like the DOM to do anything useful with it at the server level. > Luckily that's their problem and not mine . > > My problem was slightly different. I needed to be ready for the 5.0 browsers > (probably IE5, although I'd prefer NS5), and XML seemed ideal because we > would be displaying/editing documents that look like data (or data that > looks like a document if you like). We really needed an object database, but > I needed to get moving quickly (a typical web project: "Can we have it > yesterday"). Learning an object database wasn't a possibility. I already > knew XML. So I looked at it like this - we could have it 2 ways: > > 1) Store XML now, process into HTML now, Transmit XML in the future. Basically to do this you will need in effect a flat-file database. I think a lot of people who will be using XSL will be doing things this way. Just write some XML file by hand that contains your data, apply a stylesheet, and voila! you have HTML. Transmitting XML does no real good unless it is in some document format the browser understands. Even then you will probably want to use XSL to spit content out into this presentation format. This can be done at the server-level or else in the web-browser. > 2) Store in RDBMS now, process into HTML now, process into XML in the > future. > > #1 looked like a nicer solution because it gives performance gains in the > future, which #2 doesn't really (except perhaps XML is a lighter weight > format to transmit than HTML). However this, it appears, is not the right > way to go because RDBMS->*ML is always faster than XML->HTML. That's a > lesson learned, and I thank you for it. Of course this is under the assumption the browser has XSL capabilities and that they are compliant (MS XSL for instance in IE5 is not exactly what you would call compliant XSL at the moment). > Some of the points about caching are great when you're reading 1 XML file > multiple times, but we're talking about 400 - 1000 XML files being accessed > and constantly changed. A nicer solution would be an OODB. It's probably > time to go shopping... Of course. My previous comments were under the assumption that the XML content was pretty much static. Nevertheless, using an OODB will not necessarily give any benefits over an RDBMS. It all depends on your particular business problem. I will let the fight of "whose database is better" up to the DBMS vendors. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Feb 1 18:04:50 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:22 2004 Subject: What is a good database for very large collections? (was Re: XSL/ECMAscript (was RE: Frontier as a scalable XML repository (was Re: Is XML dead already or what?)) Message-ID: <3.0.32.19990201094706.00bab450@pop.intergate.bc.ca> At 04:18 AM 2/2/99 +1100, Rick Jelliffe wrote: >What is a good database for XML? > >The criteria are: > * over 20, 000, 000 document fragments, each less than 256 >characters, each with some flat metadata, able to be incrementally >reloaded onto the live system > * about simultaneous 30 users accessing about 10 fragments a minute >each, grouped together (along with other dynamic data) and transformed, >with a high need for immediate response > * constant data-mining tools using various adhoc AI and linguitic >retrieval software augmenting the metadata in the background. For little fragments like this, you can't possibly (it seems to me) have all that much internal structure, because there's nowhere to put it. Given this, my intuition would be to stuff these puppies into whichever of Oracle/Sybase/Informix was the best fit for my existing installation. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Feb 1 18:05:15 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:23 2004 Subject: Another errata? Message-ID: <3.0.32.19990201100346.00b5d4a0@pop.intergate.bc.ca> At 06:35 PM 2/1/99 +0100, james anderson wrote: >While I could live with the assertion, I would, unfortunately, be unable to >write useful software which conformed to it. If an "unprefixed attribute name" >is really not in any namespace, then it would be impossible for application >code to execute an affirmative comparison against the name, and it would be, >for similar reasons, impossible to write xsl patterns which addressed the >attribute. Are these consequences really intended? The namespace spec gets more over-interpretation than any document this side of the Old Testament. It seems simple to me. 1. There are abstract things called "namespaces", each identified by some URI 2. There is a syntactic mechanism, involving reserved attributes, placeholder tokens, and colon-delimited prefixes 3. The mechanism can be used to map namespaces directly to element types 4. The mechanism can be used to map namespaces directly to attribute names 5. There is a defaulting mechanism to map namespaces to unprefixed element types, purely syntactic sugar The spec says *nothing* normative about the relationship between namespaces, as defined in #1, and an unprefixed attribute. Appendix A provides a scheme which can be used to create a unique identifier for each element type & attr name in a document, using in part the namespace information. If it's any consolation, this very issue was more or less what tied up the WG for months and months. What really crystallizes it is the question, given this: what can you say about the namespace of the href= attribute? The most common and reasonable-sounding answer is, "it's in the namespace of the html:a element". OK, but what does that mean, formally? It turns out to be hard to write down. You could decree that it's in the HTML namespace. A consequence of this is that is identical to which it might be in some circumstances; but always, for all element types and all namespaces? Tough to buy into. Anyhow, the final consensus was that all you can say about the href= above is that it's attached to an element that's in the html namespace. For the purposes of many applications, that might be equivalent to being in the html namespace; but that interpretation isn't compulsory. For places where you want it to be compulsory, go on and prefix the attributes. In my first few implementations of namespace-savvy software, I've had no trouble finding the attributes I needed. What's a scenario that causes problems? -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Feb 1 18:20:47 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:23 2004 Subject: Another errata? References: <3.0.32.19990201100346.00b5d4a0@pop.intergate.bc.ca> Message-ID: <36B5F1D2.13073B73@locke.ccil.org> Tim Bray scripsit: > A consequence of this is that > > is identical to > > > which it might be in some circumstances; but always, for all element > types and all namespaces? Tough to buy into. Why is it so tough? If the committee decreed it, fine; but I'd like to see the argument that says the above is implausible. I find it eminently plausible. > In my first few implementations of namespace-savvy software, I've had > no trouble finding the attributes I needed. What's a scenario that > causes problems? -Tim The trouble is, I think, that people would like to "intern" (uniquify) every name in an XML document while parsing it. Element names can be converted to URI^Qname, where ^ is some separator, and interned as such; global attribute names likewise. But it won't do to identify all foo attributes (unqualified) across the entire document, as they may be utterly unrelated. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Feb 1 18:53:54 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:23 2004 Subject: NamespaceFilter and ParserFilter updates Message-ID: <36B5F999.FA852119@locke.ccil.org> NamespaceFilter is now updated to handle unprefixed attributes in accordance with the xml-names REC rather than by the old WD formulation. ParserFilter also has a few bugs fixed. The MDSAX team should particularly note these changes. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Mon Feb 1 19:36:35 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:08:23 2004 Subject: Real world DTD Message-ID: <49092BAEAC84D2119B0600805FD40F9F120C69@MDYNYCMSX1> >Or one step up in size, DocBook 3.1 in XML: Discussions on the Davenport list about the possibility of a "DocBook Lite" have ended up concluding that different subsets of it work best for different people, so there's no single "DocBook Lite" out there. Apparently, making one's own customized subset of DocBook is pretty common, so keep that in mind if the full DTD is more than you need. Its modular design makes this kind of subsetting easier. I've used my own "DocBook Very Lite" for examples in writing about SGML, but at 24 element declarations, it's a bit too light for a lot of applications. I use it for taking notes and things; I wrote a perl script that converts Emacs outline format to it so that I can use Norm W's DSSSL style sheets to make nice RTF out of my Emacs outlines. If anyone's interested, see "ol2dbvl" on http://www.snee.com/bob/sgml.html. Bob DuCharme www.snee.com/bob see www.snee.com/bob/xmlann for "XML: The Annotated Specification" from Prentice Hall. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Mon Feb 1 19:41:32 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:08:23 2004 Subject: Another errata? Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEED6@RED-MSG-08> The example is identical to used in earlier mails to this list is less than ideal for the purpose of explaining namespaces on attributes. Let's back up. The A element in HTML is defined in http://www.w3.org/TR/REC-html40/ as It happens that the href attribute in HTML is also defined for a few other element types, for example LINK and BASE, and for these elements it is also CDATA with essentially the same rules and meaning. This might lead one to think that the HREF attribute of an A tag is the same attribute type as the HREF attribute of the LINK tag. One might even go so far as to imagine that both HREF attributes are defined in some global scope, at the same level as elements, in other words, in the "HTML" namespace. The English text of the specification clearly implies that these attributes are to be seen as essentially the same. But the DTD does not say this. The English text and our experience using HTML gives us information not written in the DTD. DTDs today do not have any facility to express that two attributes with the same name, used within different element types, are the same in type or meaning. Within the expressive power of DTD, all we can observe is that the A tag has an attribute named HREF with certain properties. That is, there is an "href" attribute used within the "A" tag. There is also an "href" attribute used within the "LINK" tag. There is also an "href" attribute used within the "BASE" tag. And so forth. They happen to have the same properties. We know that they have the same meaning. But a DTD could equally well have defined an "href" attribute for a "TABLE" element that was a NUMBER and had no relation to the "href" of an "A" element. The DTD can only go so far as to say that an "href" used on an "A" element has certain properties, and that there is also an "href" on a "TABLE" element that has certain other properties. In other words, the definition of an attribute, within the expressive powers of DTD, is relative to its containing element. An unqualified attribute is identified by the triple consisting of the namespace of the element, the name of the element, and the name of the attribute. (See appendix A.3 of the namespaces spec.) This is a long build-up to the conclusion that an unqualified attribute cannot be presumed to come from the same namespace as its element, without qualification. Rather, the element provides a local namespace for its attributes. So is it true that is identical to ? There is nothing in a DTD that would allow us to decide that they are identical. They are no more the same than if the HTML DTD defined another element called "ANCHOR" and the English spec said that it has exactly the same meaning as the "A" element. We might, reading the English spec, know that they are the same. But qua DTD, they are different. The namespaces specification is designed to support the current practice of DTDs, and so defines unqualified attributes in this way, while leaving the door open to future forms of schema that express richer and more-global attribute scopes. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Mon Feb 1 21:05:22 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:23 2004 Subject: NamespaceFilter and ParserFilter updates Message-ID: <002101be4e25$f2695b60$c9a8a8c0@thing2> >The MDSAX team should particularly note these changes. Thanks John. We have your namespace and inheritance filters working with MDSAX now, and will be sure to include your updates in the next release. FYI, here's the configuration document we are using to test inheritance. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Mon Feb 1 21:54:10 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:23 2004 Subject: NamespaceFilter and ParserFilter updates Message-ID: <000a01be4e2c$ce497240$c9a8a8c0@thing2> John, Your new namespace filter looks good, though I must admidt I'm still finding the output a bit strange. Thanks to Paul for integrating namespace and MDSAX. Bill Before: After: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From deke at tallent.com Mon Feb 1 22:10:49 1999 From: deke at tallent.com (Deke Smith) Date: Mon Jun 7 17:08:23 2004 Subject: Frontier as a scalable XML repository (was Re: Is XML dead already or what?) Message-ID: <1294218445-103751506@server2.tallent.com> As someone who uses Frontier with XML I will try to make a brief outline of my experiences (I can get a little verbose sometimes). Frontier is a good example of how some people use XML in a PRODUCTION ENVIRONMENT. All the users of the current version use XML whether they know it or not. As part of a subscription to Frontier, the user is provided constant updates for bug fixes and new features. Those updates are provided via HTTP using XML. The documentation can be downloaded and referenced from within the program and that, too, is updated the same way. Both of these uses of XML are invisible to the end user... I think many people who are currently using Frontier as a processor for XML would agree with this: Tyler Baker, tyler@infinet.com said on 2/1/99 11:56 AM: >There seems to be a major misconception here I think in terms of what >software >needs to do for businesses. The issue for XML I think should be >scalability, not >just raw speed. What use is the XML/XSL architecture if it costs mucho >deneiro >in development dollars for fly-by-night consultants, overpriced databases, >and >application servers. Maybe some giant bank has money to burn, but the >average >web-shop if they are even profitable is running their business on very thin >margins. Raw performance of using XML is not what should be the focus here, >simplicity should be the focus. In a production environment where expediency is important as well as flexibility and reuseability, *TODAY* XSL is not the answer. If I am not mistaken, XSL is still in working draft. I have based work I have done on a working draft before and had to redo it later to be reuseable. There is a need, and tools like the Xmltr Suite have filled the vacuum in the Frontier environment. I have tried to see how much XML Frontier can munch on and used the religion xml files as a stress test. Last time I tried (three months ago) Frontier could not parse that quantity of text at one time. It coughed a hair ball about a quarter of a way through it. As far as being a repository for terabytes of information...that is an interesting question and one that sounds intriquing enough to try. Parsing huge files may be a problem as I mentioned before. Although most of Frontier's information is stored in the main database of the program called the 'root', 'guest' databases can be created as needed. Unfortunately I don't have a terabyte disk drive nor do I think I can scrounge up a terabyte worth of information on my own to try. I search for XML data once it is inside of Frontier by creating indices. Right now, indices are pretty much a roll your own proposition. I have a database of approximately 1,000 contacts from around the world in an XML file. That way, it can be edited by volunteers who have no computer experience on Mac, Windows, Unix, BeOS, etc. I can bring this data into Frontier and create a "Yahoo-style" directory from the information with about a hundred pages. I also can replicate the directory in Spanish and German using XML-based dictionaries to translate geographic names and interface elements. After creating my scripts, it takes me about thirty minutes to bring the revised listing into Frontier and get it started. A couple of hours later it is done and the Website online has been updated via FTP. Deke ----------------------------------------------------------------- Deke Smith Tallent Communications Group, Brentwood TN deke@tallent.com, 615-661-9878 "Cats are smarter than dogs. You can't get eight cats to pull a sled through snow." - Jeff Valdez ----------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Mon Feb 1 23:17:05 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:23 2004 Subject: Interesting Monday. In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136ADA@eukbant101.ericss on.se> Message-ID: <4.1.19990202100959.00c80910@steptwo.com.au> At 20:29 1/02/1999 , Matthew Sergeant (EML) wrote: | My problem was slightly different. I needed to be ready for the 5.0 browsers | (probably IE5, although I'd prefer NS5), and XML seemed ideal because we | would be displaying/editing documents that look like data (or data that | looks like a document if you like). We really needed an object database, but | I needed to get moving quickly (a typical web project: "Can we have it | yesterday"). Learning an object database wasn't a possibility. I already | knew XML. So I looked at it like this - we could have it 2 ways: | | 1) Store XML now, process into HTML now, Transmit XML in the future. | | 2) Store in RDBMS now, process into HTML now, process into XML in the | future. I would personally recommend a third option: 3) Store in RDBMS now, process into XML, process this into HTML now. Process the XML into whatever you want in the future. I have been using this in an electronic publishing system, and while it seems like overkill, it isn't. It both makes the generation of HTML easier, and inserts a very nice level of abstraction into the whole system. For example, you can change the structure of the RDBMS without having to worry about the HTML, etc, as long as the XML DTD is still valid. And if you want to generate paper, online help, etc it is much easier from the XML. Cheers, J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Mon Feb 1 23:56:12 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:23 2004 Subject: Another errata? Message-ID: There seems to be a lot of confusion here. A few interesting points have been made, but I think the defence of the namespaces spec has not been made strongly enough. To recap: some people are querying as to why the namespaces spec does not allow attributes that do not have a namespace specified to belong to a default namespace. Elements with no namespace can belong to a default one, they argue, so why can't attributes? Others in the discussion have said, well, even if we accept this, why doesn't the attribute at least belong to the same namespace as its element? There are two confusions here: - the first relates to default namespaces, and why their application to attributes would be a problem, not a help - the second relates to a misunderstanding as to what role namespaces play anyway Let's look at the default namespace question first. As Ronald said on this thread - quoting from the namespaces spec - default namespaces do NOT apply to attributes (or not *directly* anyway). To see why this is necessary, imagine for a moment that they did. What would the following document give us (picking up on an example from the namespaces spec)?: Cheaper by the Dozen In this document 'isbn' would be part of the HTML 4.0 namespace - not what is intended at all! Now, everyone out there that's moaning - do you really want to have to prefix every attribute with the namespace of its element, to ensure it is not confused with a default namespace? OK then, some have argued, at least shouldn't 'isbn' automatically be part of the 'bk' namespace? Still no, I'm afraid. Every member of a namespace is meant to be unique. If we do this 'auto-joining' we cannot guarantee uniqueness. Let's extend the above example (having now hopefully accepted that 'isbn' is *not* part of HTML 4.0) to include another object which is probably not part of the 'urn:loc.gov:books' namespace, but bear with me: Cheaper by the Dozen A list of loads of books In this case, 'auto-joining' an attribute to its element's namespace would make 'isbn' into a *global* attribute. Handy, if you wanted to process all bk:isbn numbers in a document - but wrong!! In this document we do NOT have two instances of bk:isbn, we have one of bk:book:isbn and one of bk:catalogue:isbn. So after all that, what namespace is it in? Taking on board the points in section A.2, 'isbn' actually occurs twice, once in the per-element type partition for bk:book, and again for bk:catalogue. But now, unlike before, each is guaranteed to be unique, which is what namespaces are for! On to the second issue. I think some of the confusions have arisen by mixing up namespaces with validation. All namespaces do is give you a syntax for ensuring that elements and attributes are unique. In our examples above, we don't want to ensure that 'isbn' is unique within the entire document, we just want it to be unique within 'book' and 'catalogue'. But XML already ensures that, so we don't actually need an explicit namespace. A parser already has all the information it needs about the attribute from its context within an element. If an application processing the nodes in the document had to act differently when processing 'isbn' fields that come from inside the company, versus processing the public ones; and further, if 'catalogue' is defined inside our company, but 'book' is public; then, in the following document we already have ALL the information we need: Cheaper by the Dozen A list of loads of books The parser will already give us all the information we need to process the two 'isbn' values differently, even though neither are prefixed with a namespace! We don't need one! So hopefully now you can see why this is unnecessary: y this is OK: y and this is not good practice at all (see Andrew Layman's comments on this, too): y Regards, Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From db at Eng.Sun.COM Tue Feb 2 00:07:31 1999 From: db at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:08:23 2004 Subject: SAX: Next Round (Lexical Event Handler) References: <199901202122.QAA00962@megginson.com> <36AA93F3.B98FAE05@jclark.com> <36B21948.5F74CEED@eng.sun.com> <14004.51695.816155.975439@localhost.localdomain> Message-ID: <36B64057.205FCFB0@eng.sun.com> David Megginson wrote: > > David Brownell writes: > > > > > I haven't checked, but I think that this gives us everything we need > > > > for DOM level one. > > > > Doesn't quite ... there's some more DTD information needed to: > > > > * ensure that PIs within the DTD (e.g. internal subset) > > don't show up anywhere in the DOM tree (ugh); > > You can determine this using the start/end DTD events and start/end > entity events, I think. Seemed like the start/end DTD event was for the external subset though. Sun's interface works that way, so this can be done given a real API description ... :-) > > * see declarations of external general entities; > > Do we need the declarations, or just the boundaries -- or, in other > words, do we need to provide information about declared but unused > external parsed entities? Sorry I'm too lazy to puzzle this out from > the spec right now. Actually I misspoke: It's not DOM that needs to see the declarations, it's the namespace spec which places a constraint that entity names be colon-free. (As noted, I was assuming namespaces should be layerable.) > > * expose values of defaults so that the DOM can ensure > > that defaulted attributes always have values; > > The parser should take care of this. Only if DOM and the parser are joined at the hips -- since when you remove a defaultable attribute from a DOM element, the DOM must then restore that value to its default value. (John Cowan also noted this.) > > * distinguish attributes which were defaulted from those > > that were explicitly in the document. > > Yes, this is necessary, as a few others have also pointed out > (grumble, grumble). > > > (In addition the above, if XML namespaces are to be layerable over > > a normal XML 1.0 parser, declarations of all other entities need to > > be exposed so they can be examined for conformance: they must not > > contain colons!) > > This is probably overkill for SAX -- if someone wants to layer > namespaces on top of SAX, they'll have to miss this one. ... or add new interfaces! > > > I wonder whether LexicalHandler ought to extend DocumentHandler. The > > > events it reports are synchronous with the events reported by > > > DocumentHandler. It seems to me that applications are always going to > > > want to implement either DocumentHandler or both DocumentHandler and > > > LexicalHandler. > > Probably -- the problem is that if we extend Parser then we'll have > both a setDocumentHandler and a setLexicalDocumentHandler event, and > that causes some funny problems that I'd rather punt. What I did is effectively group the two: if you set one, you set the other. One can always argue purity of essence, but that seemed to be the most useful choice for applications. - Dave > All the best, > > David > > -- > David Megginson david@megginson.com > http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Feb 2 00:47:38 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:23 2004 Subject: Since we're talking about databases... Message-ID: <3.0.32.19990201164621.00a5e360@pop.intergate.bc.ca> One reason that I've been particularly interested in these threads is that I've been doing a bunch of work for a German company named Software AG. Those who have some grey hairs will remember a database package named "ADABAS" that used to be hot stuff in pre-relational days (still is pretty hot stuff, but marginalized due to being non-relational). Anyhow, they've been working on a REALLY BIG REALLY FAST xml data store, and have actually started talking a little bit about this in public: check out http://www.softwareag.com/corporat/press/jan99/e-cebit.htm Pretty thin information as yet, but people who are interested in wrangling XML en masse should keep an eye on these guys. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From harvey at eccnet.eccnet.com Tue Feb 2 01:14:28 1999 From: harvey at eccnet.eccnet.com (Betty L. Harvey) Date: Mon Jun 7 17:08:23 2004 Subject: Since we're talking about databases... In-Reply-To: <3.0.32.19990201164621.00a5e360@pop.intergate.bc.ca> Message-ID: On Mon, 1 Feb 1999, Tim Bray wrote: > One reason that I've been particularly interested in these threads is that > I've been doing a bunch of work for a German company named Software AG. > Those who have some grey hairs will remember a database package named > "ADABAS" that used to be hot stuff in pre-relational days (still is > pretty hot stuff, but marginalized due to being non-relational). I don't remember ADABAS but I remember a database called S2K (which was also pre-relational). S2K was a hierarchical database. I worked with S2K a few years ago (many of the individuals on this list were probably still in diapers). I have often thought that a database like S2K with XML would be pretty powerful We ran a Personnel and Accounting Control System (PACS) that managed all the H.R. and Accounting information for 10,000 employees. Back then (in the dark ages) XML wasn't invented yet. I haven't heard of S2K applications in years but I have often thought that the hierarchical database model (one that isn't dependent on COBOL |-) and XML would be a pretty powerful team and the right tool for the job. I look forward to hearing more about ADABAS. Betty /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 301-540-8251 FAX: 4268 Electronic Commerce Connection, Inc. | 13017 Wisteria Drive, P.O. Box 333 | Germantown, Md. 20874 | harvey@eccnet.eccnet.com | Washington,DC SGML/XML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/sgmlug/ /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Tue Feb 2 01:33:27 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:23 2004 Subject: Since we're talking about databases... References: <3.0.32.19990201164621.00a5e360@pop.intergate.bc.ca> Message-ID: <36B65517.8FAE4EC5@manhattanproject.com> I'm rather new to the list. I was wondering if there is any current (open source?) work for storing XML in relational databases. I was thinking of using PostgreSQL. Thoughts: (I've read almost everything on Robin Cover's site) a) I've been reading everything I can on XML and see a big opportunity to have a standard based upon formal systems. The forest automata papers are expecially exciting, now I regret goofing-off during computational complexity... Anyway, I'd love to see/learn more on this aspect of XML before I jump head first into coding. Any more pointers? b) The XML Archetectures seems to be the right way to go from my understanding of the readings, thus any database would have to support this. Is this the concensus or are their vaired opinions? c) GROVES look pretty cool. Is there anyone working on a xml property set? Would it be smart to implement an xml database upon the groves abstraction, or would a direct (DOM) based implemention be better? d) How hard would it be to develop a transition/rewrite engine (say by modifying JADE) to work using a database store instead of memory? Thoughts? Any work in this area? e) Is there any thoughts on a XML transport layer (instead of using CORBA), based upon SMTP and POP3 or equivalent? I was thinking more along the lines of LISTSERV, where message logistics are handled in a smart way. f) Has anyone proposed a standard SQL 92 RDBMS mapping? :) Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 2 01:50:24 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:08:23 2004 Subject: Since we're talking about databases... In-Reply-To: <36B65517.8FAE4EC5@manhattanproject.com> Message-ID: <000601be4e4e$003a7800$5118a8c0@kuantech1.quokka.com> There is work on XML-based transport using HTTP: the WebBroker NOTE from W3C. As far as XML and databases are concerned, I believe Oracle has integrated an XML parser into their RDBMS product. I don't know any more details than that. Jeff Sussna -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Clark Evans Sent: Monday, February 01, 1999 5:30 PM To: xml-dev@ic.ac.uk Subject: Re: Since we're talking about databases... I'm rather new to the list. I was wondering if there is any current (open source?) work for storing XML in relational databases. I was thinking of using PostgreSQL. Thoughts: (I've read almost everything on Robin Cover's site) a) I've been reading everything I can on XML and see a big opportunity to have a standard based upon formal systems. The forest automata papers are expecially exciting, now I regret goofing-off during computational complexity... Anyway, I'd love to see/learn more on this aspect of XML before I jump head first into coding. Any more pointers? b) The XML Archetectures seems to be the right way to go from my understanding of the readings, thus any database would have to support this. Is this the concensus or are their vaired opinions? c) GROVES look pretty cool. Is there anyone working on a xml property set? Would it be smart to implement an xml database upon the groves abstraction, or would a direct (DOM) based implemention be better? d) How hard would it be to develop a transition/rewrite engine (say by modifying JADE) to work using a database store instead of memory? Thoughts? Any work in this area? e) Is there any thoughts on a XML transport layer (instead of using CORBA), based upon SMTP and POP3 or equivalent? I was thinking more along the lines of LISTSERV, where message logistics are handled in a smart way. f) Has anyone proposed a standard SQL 92 RDBMS mapping? :) Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Tue Feb 2 04:30:55 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:23 2004 Subject: Since we're talking about databases... In-Reply-To: <36B65517.8FAE4EC5@manhattanproject.com> References: <3.0.32.19990201164621.00a5e360@pop.intergate.bc.ca> Message-ID: <3.0.5.32.19990201214853.009c9b10@amati.techno.com> At 01:29 AM 2/2/99 +0000, Clark Evans wrote: >I'm rather new to the list. I was wondering if there is any >current (open source?) work for storing XML in relational >databases. I was thinking of using PostgreSQL. >c) GROVES look pretty cool. Is there anyone working >on a xml property set? Would it be smart to implement >an xml database upon the groves abstraction, or would >a direct (DOM) based implemention be better? David Megginson's Work Group is charged with developing the official abstract data model for XML--but I doubt it will be defined as a property set using the PSDR approach. Defining a grove plan over the SGML property set that reflects what XML gives you is pretty trivial and adding some properties for XML-specific stuff (dare I say it, namespaces?) wouldn't be too hard. TechnoTeacher (www.techno.com) is pursing large-scale grove-based systems. We've certainly talked about relational vs object approaches. They'll probably have to do both eventually. I'm in the process of rewriting my PHyLIS grove manager/HyTime engine in Python. As there's an RDBMS package for Python, I'm thinking about trying to put it under PHyLIS as a persistent grove store. Not sure how it will work, but it will be easy to experiment with. >d) How hard would it be to develop a transition/rewrite >engine (say by modifying JADE) to work using a database >store instead of memory? Thoughts? Any work in >this area? Shouldn't be too hard. One way to do it is to simply put a grove API over a database, so that the grove is really just a bunch of indirections to the real data. This is the way I've designed my GroveNode class for PHyLIS, to enable this sort of grove binding. There's probably a more efficient way to do this from a CS standpoint, but it seemed pretty easy to implement. I wouldn't be surprised if Alex Milowski, of Copernican Solutions and Veo Systems, hasn't done some of this stuff-he put a lot of effort into building a completely grove-based server system. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From CBerry at works.com Tue Feb 2 05:14:23 1999 From: CBerry at works.com (Chris Berry) Date: Mon Jun 7 17:08:24 2004 Subject: No subject Message-ID: <958E41703996D21197A200A0C9D4C65672B1@AUS-SERVER4> Greetings, I am a relative newbie to XML, so please bear w/ me if this is a poor question... It looks like everything in the DOM must be dealt w/ in the context of a particular document. It seems you cannot drop one Document into another, or even one DocumentFragment into another Document context. I have tried to do the following... (using Microsoft's implementation of the DOM) IXMLDOMDocument doc = (IXMLDOMDocument) new DOMDocument(); IDOMDocumentFragment docFrag = doc.createDocumentFragment(); IDOMElement userElem = doc.createElement("USER"); userElem.setAttribute("TIMESTAMP", new Variant("123456") ); docFrag.appendChild( userElem ); doc.appendChild( docFrag ); System.out.println( doc.getXml() ); // >>>> Yields the correct results IXMLDOMDocument doc2 = (IXMLDOMDocument) new DOMDocument(); doc2.appendChild( docFrag ); System.out.println( doc2.getXml() ); // >>>> Yields an empty string It seems like this should work to me. Shouldn't we be able to cut and paste between documents?? Or more important, shouldn't we be able to build up documents compositionally?? I.e. compose Address 1 and Address 2 as DocumentFragments (or their own Documents -- with their own DTDs) and then drop these into, say, User (providing that the User DTD agrees). I must be missing something here. Thanks in advance, Cheers, -- Chris Chris Berry cberry@works.com 512-231-1341 works.com 6850 Austin Center Blvd. Austin, TX 78731 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From da at cp.net Tue Feb 2 05:19:13 1999 From: da at cp.net (da) Date: Mon Jun 7 17:08:24 2004 Subject: How XML Just Might Eat the Web Someday (was Re: Interesting Monday.) In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136ADA@eukbant101.ericss on.se> Message-ID: Hi there, Well, I've been off the list for a while in the middle of switching jobs. But, oddly enough, some opportunities to use XML have come up at my new gig as well. Whether this is more because I've got a hammer and everything looks like a nail or a reflection of the actual usefulness of XML remains to be seen, but I have a feeling it's the latter. One note regarding that: I've downloaded gecko and it's great, it looks like it's going to do exactly what I want to do with it. Very cool. I know the focus of this list isn't really interface stuff, but I can't pass a thread with a title like that up without dropping in my $2E-2. If you go to http://www.vizbang.com/ and click on the one link there that isn't a mailto, you'll find a whitepaper that I wrote about a year ago on 3D representations of XML and published under the aegis of the VRML consortium. I'm working with a designer right now on doing up an entire personal site using this technology, so there will be a good demo soon, I hope. (It's been slowed down a lot by having a new job that I like and living in the most amazing city on earth...sigh.) But the basic, admittedly wacky and either ahead of it's time or unimplementable in a scaleable way idea is to render links, to use 3D to show the relationships between chunks of information. You could see how big a site is. You could see where it you've been and where you can go. You could make your own links. I'm excited about the navigational improvements it could make to the web in the short term, but the longer term application that I'm even more excited about is for collaborative document authoring. The whitepaper isn't exactly a classic of technical literature, but it does have most of the stuff I've been thinking about, and soon there will be a demo. I've got some reasons to think it might happen, eventually. A number of very knowledgeable folks from the web design, XML and VRML communities have said they think it's pretty hot stuff, and at least one person who is active on this list has told me that he tried to do what I'm trying to do and it's impossible. The former response has given me hope, but the latter response has admittedly been more useful in keeping me motivated (which may very well have been why that person wrote it, for all I know). /da At 11:29 AM 2/1/99 +0100, Matthew Sergeant (EML) wrote: >Boy, you people sure can write when something stirs you up... It's 10:10am >and I've only just got through my backlog of XML-Dev mail... > >Well, as the person who introduced the topic "Will XML eat the web?", I feel >I should just add some points of note. I thank everyone who has contributed >to this topic though. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Feb 2 05:56:59 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:08:24 2004 Subject: Another errata? Message-ID: <005101be4e70$ab37d820$2ee044c6@arcot-main> >The namespace spec gets more over-interpretation than any document this >side of the Old Testament. It seems simple to me. I beg to differ. The namespace spec is short and hard to read, difficult to understand, and leaves the reader with many unanswered questions. Answers might have been in the spec in the form of some carefully chosen sequence of words but they were not apparent. It is also lumpy in terms of information density which has similar effect as being questioned by Colombo: easy sentences mixed with hard logic ambushes. Considering that namespaces affect most XML developers, this is truely unfortunate. If the spec seems simple to you, that is because you are one of the authors. My evidence for its failure to satisfy the readers is in the very confusions and over-interpretations you have noted. Like the majority of the XML developers, I have tremendous respect for the work you have done, especially the XML spec. I do hope you will consider what can be done to remedy the situation rather than trying to defend the namespace spec. Perhaps the Annotated Namespaces in XML will do the job if it fully discusses the implications and applications of namespaces. Perhaps not. We, the slaves of the standard specs which seemingly breeds like rabbits, have very little control over these matters without getting pissed off as a whole. We are at your mercy. Help us if you can. Best, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Tue Feb 2 09:05:46 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:24 2004 Subject: Interesting Monday. Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136ADE@eukbant101.ericsson.se> > -----Original Message----- > From: Tyler Baker [SMTP:tyler@infinet.com] > Sent: Monday, February 01, 1999 5:57 PM > To: Matthew Sergeant (EML) > Cc: 'xml-dev@ic.ac.uk' > Subject: Re: Interesting Monday. > > "Matthew Sergeant (EML)" wrote: > > > Boy, you people sure can write when something stirs you up... It's > 10:10am > > and I've only just got through my backlog of XML-Dev mail... > > > > Well, as the person who introduced the topic "Will XML eat the web?", I > feel > > I should just add some points of note. I thank everyone who has > contributed > > to this topic though. > > > > Firstly, I think there is still an issue with processing power and XML, > > although I can see that my system is poorly designed. Time for a > rethink... > > The area where I can forsee potential problems is in e-commerce. Take an > > e-commerce transaction processing company that's moved to an XML > transaction > > format. They don't have a shop web site, they just process credit card > > transactions for other sites. I imagine they are going to need to > process > > hundreds of transactions per second. I don't for a second suggest that > they > > store the XML as the primary data format (store it as a backup as > suggested > > here) - it should immediately be put into an RDBMS. But to do that they > have > > to parse each transaction. There's no caching that can go on here. > > There seems to be a major misconception here I think in terms of what > software > needs to do for businesses. The issue for XML I think should be > scalability, not > just raw speed. What use is the XML/XSL architecture if it costs mucho > deneiro > in development dollars for fly-by-night consultants, overpriced databases, > and > application servers. Maybe some giant bank has money to burn, but the > average > web-shop if they are even profitable is running their business on very > thin > margins. Raw performance of using XML is not what should be the focus > here, > simplicity should be the focus. Using XML for backup or log files is not > a bad > use of XML. In fact it is a very simple use of XML to do some very simple > things. What major benefit is XML other than through some document API > like the > DOM if it is stored in the DBMS. Are you going to have the DBMS construct > an XML > stream on the fly which then needs to be reparsed into some in-memory data > structure like the DOM to do anything useful with it at the server level. > I think you've missed my point all together here (correct me if I'm wrong). Much e-commerce in the future is going to be done using XML. For e-commerce to work you have order-generators (the web-shop) and transaction processors (the credit card company, or someone who processes the order). Generally these aren't the same company. The transaction processing companies will have their work cut out for them performing hundreds of transactions a second using XML. That's all I'm saying. How they get around that is their business. (it might even be my business in the near future, just not now). 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Tue Feb 2 09:12:00 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:24 2004 Subject: Interesting Monday. Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136ADF@eukbant101.ericsson.se> > -----Original Message----- > From: James Robertson [SMTP:jamesr@steptwo.com.au] > > At 20:29 1/02/1999 , Matthew Sergeant (EML) wrote: > > | My problem was slightly different. I needed to be ready for the 5.0 > browsers > | (probably IE5, although I'd prefer NS5), and XML seemed ideal because > we > | would be displaying/editing documents that look like data (or data > that > | looks like a document if you like). We really needed an object > database, but > | I needed to get moving quickly (a typical web project: "Can we have it > | yesterday"). Learning an object database wasn't a possibility. I > already > | knew XML. So I looked at it like this - we could have it 2 ways: > | > | 1) Store XML now, process into HTML now, Transmit XML in the future. > | > | 2) Store in RDBMS now, process into HTML now, process into XML in the > | future. > > I would personally recommend a third option: > > 3) Store in RDBMS now, process into XML, process this into HTML now. > Process the XML into whatever you want in the future. > > Nonononono. :) This generates probably 5% more overhead than I have already (the RDBMS). XML doesn't parse quickly (well, OK, it parses quickly, but not compared to reading data from an RDBMS). When you are processing tens of XML files per second this becomes a huge problem. 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Rschoening at unforgettable.com Tue Feb 2 09:26:52 1999 From: Rschoening at unforgettable.com (Rob Schoening) Date: Mon Jun 7 17:08:24 2004 Subject: Interesting Monday. In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136ADE@eukbant101.ericsson.se> References: <5F052F2A01FBD11184F00008C7A4A80001136ADE@eukbant101.ericsson.se> Message-ID: <000342de26f5e966_mailit@mail.ptld.uswest.net> >The transaction processing >companies will have their work cut out for them performing hundreds of >transactions a second using XML. That's all I'm saying. How they get around >that is their business. (it might even be my business in the near future, >just not now). I don't think this is such a big deal. It seems like it would be trivial to load-balance the XML component of the server. There would be a slight increase in latency to account for XML parsing, but it wouldn't drag the database. It's not as if the XML processing must be done in lock-step with the transaction processing. Rob > > 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/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Feb 2 11:59:35 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:24 2004 Subject: SAX: Next Round (Lexical Event Handler) In-Reply-To: <36B64057.205FCFB0@eng.sun.com> References: <199901202122.QAA00962@megginson.com> <36AA93F3.B98FAE05@jclark.com> <36B21948.5F74CEED@eng.sun.com> <14004.51695.816155.975439@localhost.localdomain> <36B64057.205FCFB0@eng.sun.com> Message-ID: <14006.59356.214061.86210@localhost.localdomain> David Brownell writes: > Seemed like the start/end DTD event was for the external subset > though. Sun's interface works that way, so this can be done > given a real API description ... :-) I had intended it for the whole DOCTYPE rather than just the external DTD subset -- the external subset would be delimited by a start/end entity event with the pseudo-entity '[dtd]'. > Only if DOM and the parser are joined at the hips -- since when you > remove a defaultable attribute from a DOM element, the DOM must then > restore that value to its default value. (John Cowan also noted this.) Yes, I understand the problem now. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Feb 2 12:03:54 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:24 2004 Subject: Since we're talking about databases... In-Reply-To: <36B65517.8FAE4EC5@manhattanproject.com> References: <3.0.32.19990201164621.00a5e360@pop.intergate.bc.ca> <36B65517.8FAE4EC5@manhattanproject.com> Message-ID: <14006.59502.362962.284178@localhost.localdomain> Clark Evans writes: > I'm rather new to the list. I was wondering if there is any > current (open source?) work for storing XML in relational > databases. I was thinking of using PostgreSQL. If you want to start this yourself, you probably want to code in Java to vanilla JDBC, for two reasons: 1. Most decent XML tools are in Java -- it's a nice turn-around to see people asking "is this tool available in C++" rather than "is this tool available in Java"? Of course, Perl is catching up fast... (I use Perl for quick batch processing scripts and Java for larger applications). 2. JDBC will let people put exactly as much power as they need on the back end, from MSQL or PostgreSQL (or, if they're masochists, Access) for light-weight work, to Oracle, Sybase, DBII, etc. for heavy-grade stuff. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Tue Feb 2 12:59:00 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:08:24 2004 Subject: Namespaces Message-ID: <36B6F365.24E4E19@jclark.com> I have been disturbed by the amount of confusion surrounding the XML Namespaces Recommendation. So I have written a document http://www.jclark.com/xml/xmlns.htm that tries to explain the mechanism specified by the XML Namespaces Recommendation. It explains things in a somewhat different way which I hope at least some people may find less confusing than the explanation in the Recommendation. Constructive suggestions for improvement are welcome. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Tue Feb 2 13:10:03 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:24 2004 Subject: Namespaces without a domain name Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AE1@eukbant101.ericsson.se> Can you do namespaces if you don't have a domain name? (I do, but I was thinking others might not, e.g. individuals rather than companies). This might be answered by James Clark's document which I just started reading, if it is, then I apologise. Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Feb 2 13:43:42 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:25 2004 Subject: Namespaces without a domain name In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136AE1@eukbant101.ericss on.se> Message-ID: <199902021343.IAA29829@hesketh.net> At 02:08 PM 2/2/99 +0100, Matthew Sergeant (EML) wrote: >Can you do namespaces if you don't have a domain name? > >(I do, but I was thinking others might not, e.g. individuals rather than >companies). > >This might be answered by James Clark's document which I just started >reading, if it is, then I apologise. You can always get a PURL (see http://purl.oclc.org), or use some URL that you have control over, even if its not a complete domain. DDML uses PURLs. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Tue Feb 2 14:24:28 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:25 2004 Subject: Namespaces without a domain name Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AE4@eukbant101.ericsson.se> > -----Original Message----- > From: Simon St.Laurent [SMTP:simonstl@simonstl.com] > > At 02:08 PM 2/2/99 +0100, Matthew Sergeant (EML) wrote: > >Can you do namespaces if you don't have a domain name? > > > >(I do, but I was thinking others might not, e.g. individuals rather than > >companies). > > > >This might be answered by James Clark's document which I just started > >reading, if it is, then I apologise. > > You can always get a PURL (see http://purl.oclc.org), or use some URL that > you have control over, even if its not a complete domain. DDML uses > PURLs. > Actually, now I think about it, you could use a geocities, or surf.to or any other type of free account. 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 2 14:48:42 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:25 2004 Subject: Another errata? References: Message-ID: <36B70FE4.B38B0E13@locke.ccil.org> Mark Birbeck wrote: > OK then, some have argued, at least shouldn't 'isbn' automatically be > part of the 'bk' namespace? Still no, I'm afraid. Every member of a > namespace is meant to be unique. Well, not quite. An element can have the same name as a global attribute without problem. There is a contradiction, AFAI can see, between clause 5.3 and Appendix A, and obviously 5.3 is normative. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Feb 2 14:53:27 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:25 2004 Subject: Another errata? References: Message-ID: <36B71137.8E4D145D@locke.ccil.org> Mark Birbeck wrote: > OK then, some have argued, at least shouldn't 'isbn' automatically be > part of the 'bk' namespace? Still no, I'm afraid. Every member of a > namespace is meant to be unique. Well, not quite. An element can have the same name as a global attribute without problem. There is a contradiction, AFAI can see, between clause 5.3 and Appendix A, and obviously 5.3 is normative. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Feb 2 15:15:11 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:25 2004 Subject: Namespaces without a domain name Message-ID: <005601be4ebf$12186020$2ff96d8c@NT.JELLIFFE.COM.AU> From: Matthew Sergeant (EML) > Can you do namespaces if you don't have a domain name? The namespace can be any URI. You could use Microsoft's admirable UUID notation. "uri:uuid:put the UUID here" I don't know if URIs currently allow SGML Formal Public Identifiers. If they do, you can go "uri:fpi:-//your name here//ELEMENTS your description here//EN" or if you want to publish them, and you can get an ISBN number: "uri:fpi:+//ISBN your number here//ELEMENTS your description here//EN" Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Tue Feb 2 15:27:15 1999 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:08:25 2004 Subject: Is this invalid? Message-ID: <199902021526.PAA13192@stevenson.cogsci.ed.ac.uk> Consider: ]> The second attribute declaration is ignored. But is it still a validity error that its default value is not an NMTOKEN? (This occurred to me after seeing an article by Chris Maden in comp.text.xml, but in that case the answer was clear.) -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cvonsee at onramp.net Tue Feb 2 15:44:04 1999 From: cvonsee at onramp.net (Chris von See) Date: Mon Jun 7 17:08:25 2004 Subject: Compound Documents - necessary for success? In-Reply-To: <01BE4DDF.134A6140@grappa.ito.tu-darmstadt.de> Message-ID: <199902021543.JAA10430@mailhost.onramp.net> At 12:33 PM 2/1/99 +0100, Ron Bourret wrote: >I think that many of us have a notion of a "compound document" and "reusing >schemas" but that, for most of us, these notions don't go much beyond the >actual words and a hazy, utopic, AI-intensive dream that XML documents will >somehow magically recombine themselves to solve all of our problems. > >What I think a lot of people would like is to automagically combine these >two DTDs so that the following document is valid: > > > > > > > Joe Tall > Iowa Talls > > 3 > meters > > > > >This does not currently work for two reasons. First, there is no way to >express that a document is valid under two different DTDs. Second, the >above document is clearly not valid under either of the above DTDs. To >create such a document under the current spec, we need to rewrite >players.dtd: > > > > > > >%height; > I may be showing my gross ignorance of both XML and namespaces here, but isn't this at least part of the problem that namespaces were meant to address? Granted, as Ron pointed out, a human still has to make the decision as to whether "" is relevant to "", but once there is agreement on what "height.dtd" represents authors should be able to re-use that DTD wherever it makes sense. I see the "height.dtd" as being something established by a world standards organization that allows common representation of "vertical height" information across all applications that use such things. With that in mind, it should be straightforward to use it in this context. Chris ------------------------------------ "Beware of all enterprises that require new clothes." -- Thoreau xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Tue Feb 2 15:57:58 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:25 2004 Subject: Compound Documents - necessary for success? Message-ID: <01BE4ECC.5177E760@grappa.ito.tu-darmstadt.de> Chris von See wrote: > I may be showing my gross ignorance of both XML and namespaces here, but > isn't this at least part of the problem that namespaces were meant to > address? Granted, as Ron pointed out, a human still has to make the > decision as to whether "" is relevant to "", but once > there is agreement on what "height.dtd" represents authors should be able > to re-use that DTD wherever it makes sense. Nope -- no ignorance at all. This is very definitely the problem namespaces were meant to address. It's just that the original reaction of many people to the namespaces spec is that it somehow solves the "automagic combination" and "'valid' against multiple DTDs" problems as well. (Put another way, you can get lunch, but it's not free.) -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Feb 2 16:00:47 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:25 2004 Subject: Namespaces without a domain name In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136AE1@eukbant101.ericsson.se> References: <5F052F2A01FBD11184F00008C7A4A80001136AE1@eukbant101.ericsson.se> Message-ID: <14007.8203.803886.346132@localhost.localdomain> Matthew Sergeant (EML) writes: > Can you do namespaces if you don't have a domain name? > > (I do, but I was thinking others might not, e.g. individuals rather than > companies). > > This might be answered by James Clark's document which I just started > reading, if it is, then I apologise. That's the nice thing about using URIs rather than domain names for namespaces: anyone who owns *any* URI can construct a namespace. For example, my personal (and badly out-of-date) home page is at http://home.sprynet.com/sprynet/dmeggins/ I don't own the sprynet.com domain name, but since I do have control over this URL, I can base namespaces on it: Of course, this isn't very stable, since I might switch ISPs at any time, but at least it's possible. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at goon.stg.brown.edu Tue Feb 2 16:42:42 1999 From: richard at goon.stg.brown.edu (Richard L. Goerwitz) Date: Mon Jun 7 17:08:25 2004 Subject: Is this invalid? References: <199902021526.PAA13192@stevenson.cogsci.ed.ac.uk> Message-ID: <36B72A7A.10032783@goon.stg.brown.edu> Richard Tobin wrote: > > Consider: > > > > > ]> > This is valid. Duplicate ATTLIST decls are okay. If a particular attribute such as "a" is declared more than once, the first declaration holds. Note that elicits a warning from some validators, because it uses the special empty-tag syntax, without having been ex- plicitly declared EMPTY (one of those "for interoperability" constraints). If you have questions about such things, often you can just run some sample text through our (STG's) validator, http://www.stg.brown.edu/service/xmlvalid/. Its output is pretty much self-explanatory. Here's what it says when I paste in the above document instance: ================================================================================================ Validation Results for [user-supplied text] A list of warning messages follows: line 4, [user-supplied text]: warning (652): element has more than one attlist declaration: foo line 4, [user-supplied text]: warning (581): discarding duplicate attribute definition: a line 6, [user-supplied text]: warning (1106): empty-tag syntax used for element not declared with EMPTY content model: foo ================================================================================================ Document validates OK. ================================================================================================ -- Richard Goerwitz PGP key fingerprint: C1 3E F4 23 7C 33 51 8D 3B 88 53 57 56 0D 38 A0 For more info (mail, phone, fax no.): finger richard@goon.stg.brown.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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mathieu.Mangeot at xrce.xerox.com Tue Feb 2 16:45:26 1999 From: Mathieu.Mangeot at xrce.xerox.com (Mathieu Mangeot Lerebours) Date: Mon Jun 7 17:08:26 2004 Subject: how to browse xml files with xsl style sheet LOCALLY ? Message-ID: <36B72B0C.E6D21BC4@xrce.xerox.com> Hello, I'm trying to write a xsl for my xml documents. As I'm not an expert in xsl, I wanted to start from an example. I'm working with ie5b2. I found an example at this address : http://www.silab.dsi.unimi.it/~sz475745/etl/rivista/Sommario.xml I can browse it perfectly. Then I decided to copy this file on my local disk. I also copyed the dtd and the xsl files on my local disk. But when I browse the local copy, msxml generates an error : =================================================== The XML page cannot be displayed Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later. -------------------------------------------------------------------------------- MSXML error detected: 80070005 Line 4, Position 1 ^ ================================================= I tried with another example from www.microsoft.com and encountered the same problem. Next, there was the same example but with css. This time, I could browse my local copy without any problem. So : What can I do to browse xml files with xsl locally ? thank you for your answers Mathieu -- Mathieu MANGEOT-LEREBOURS | Phone : +33 4 76 61 51 32 Xerox Research Centre Europe | Fax : +33 4 76 61 50 99 6 chemin de Maupertuis | E-mail: Mathieu.Mangeot@imag.fr F-38240 Meylan FRANCE | http://www.xrce.xerox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 2 17:01:30 1999 From: jmcdonou at library.berkeley.edu (Jerome McDonough) Date: Mon Jun 7 17:08:26 2004 Subject: Since we're talking about databases... In-Reply-To: <14006.59502.362962.284178@localhost.localdomain> References: <36B65517.8FAE4EC5@manhattanproject.com> <3.0.32.19990201164621.00a5e360@pop.intergate.bc.ca> <36B65517.8FAE4EC5@manhattanproject.com> Message-ID: <3.0.5.32.19990202084714.00be3400@library.berkeley.edu> At 07:02 AM 2/2/1999 -0500, David Megginson wrote: > >2. JDBC will let people put exactly as much power as they need on the > back end, from MSQL or PostgreSQL (or, if they're masochists, > Access) for light-weight work, to Oracle, Sybase, DBII, etc. for > heavy-grade stuff. > > I agree with David completely on the JDBC issue, but a word of warning from someone who's been there. *Don't* think that you can do this with Microsoft Access (not sure about other Microsoft products). Having spent a month trying to persuade both Intersolv's and Microsoft's JDBC/ODBC bridges to not blow up in my face after three queries into Access, I think I can vouch for that not being a stable solution. I tried the same Java code and same relational structure under Sybase and it worked just fine, however. I'd stick with databases that support JDBC directly. 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Feb 2 18:01:51 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:26 2004 Subject: Compound Documents - necessary for success? Message-ID: Chris von See wrote: > [snip on Ron Bourret's comments on how to use two DTDs in the same XML document] > I may be showing my gross ignorance of both XML and namespaces here, but > isn't this at least part of the problem that namespaces were meant to > address? In response Ronald Bourret wrote: > Nope -- no ignorance at all. This is very definitely the problem > namespaces were meant to address. Well, sort of. But note that you can use namespaces even without using a DTD. A standalone document that is well-formed might still want to have the following, in order to provide clues to any application that is processing it: Fred blonde In this example, if the application was going to process 'type' in a certain way (say an XSL processor), then it needs the namespaces to help it work out which 'type' is which. Also, if the namespace wasn't there, then you wouldn't be able to use both 'type' attributes in the same element. But note that no schemas need be involved. Conversely, if you devise a DTD that uses another DTD, you don't necessarily need to use namespaces. In the height/player example given before there is no ambiguity, so why would you introduce a namespace? So, back to compound documents. I think as a stop-gap you need dynamic DTDs. Just as many features of XML are best implemented using dynamic documents generated from databases, why not generate a top-level DTD that contains whatever lower level DTDs it needs to define the relevant compound XML document? The top DTD would include some basic stuff for containing a list of documents, and then include whatever other DTDs it needs for each document in turn. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From CBerry at works.com Tue Feb 2 18:13:05 1999 From: CBerry at works.com (Chris Berry) Date: Mon Jun 7 17:08:26 2004 Subject: Compositional Documents Message-ID: <958E41703996D21197A200A0C9D4C65672B7@AUS-SERVER4> Greetings, Sorry for the wasted bandwidth, but I posted this last night (without a Subject) and did not receive any response. I'm hoping this time around I might be luckier... I am a relative newbie to XML, so please bear w/ me if this is a poor question... It looks like everything in the DOM must be dealt w/ in the context of a particular document. It seems you cannot drop one Document into another, or even one DocumentFragment into another Document context. I have tried to do the following... (using Microsoft's implementation of the DOM) IXMLDOMDocument doc = (IXMLDOMDocument) new DOMDocument(); IDOMDocumentFragment docFrag = doc.createDocumentFragment(); IDOMElement userElem = doc.createElement("USER"); userElem.setAttribute("TIMESTAMP", new Variant("123456") ); docFrag.appendChild( userElem ); doc.appendChild( docFrag ); System.out.println( doc.getXml() ); // >>>> Yields the correct results IXMLDOMDocument doc2 = (IXMLDOMDocument) new DOMDocument(); doc2.appendChild( docFrag ); System.out.println( doc2.getXml() ); // >>>> Yields an empty string It seems like this should work to me. Shouldn't we be able to cut and paste between documents?? Or more important, shouldn't we be able to build up documents compositionally?? I.e. compose Address 1 and Address 2 as DocumentFragments (or as their own Documents -- with their own DTDs) and then drop these into, say, User (providing that the User DTD agrees). I must be missing something here. Thanks in advance, Cheers, -- Chris Chris Berry cberry@works.com 512-231-1341 works.com 6850 Austin Center Blvd. Austin, TX 78731 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From danf at yipinet.com Tue Feb 2 19:34:50 1999 From: danf at yipinet.com (Dan Finkelstein) Date: Mon Jun 7 17:08:26 2004 Subject: Stripping leading and trailing spaces??? Message-ID: <000001be4ee3$060e5d60$a39b56d1@danf> It seems that leading and trailing spaces are being removed from PCDATA before it is returned to me. For example, Hello there! Message-ID: <36B75B1B.E2EBCCC1@mecomnet.de> Ronald Bourret wrote: > > Nope -- no ignorance at all. This is very definitely the problem > namespaces were meant to address. It's just that the original reaction of > many people to the namespaces spec is that it somehow solves the "automagic > combination" and "'valid' against multiple DTDs" problems as well. (Put > another way, you can get lunch, but it's not free.) how about this for a synopsys: it guarantees you your own seat at the bar, but you still going to have to be old enough to drink. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Feb 2 21:06:09 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:26 2004 Subject: 5.3 and Appendix A contradiction [Re: Another errata?] References: <36B70FE4.B38B0E13@locke.ccil.org> Message-ID: <36B769E4.DC41937B@mecomnet.de> John Cowan wrote: > > Mark Birbeck wrote: > > > OK then, some have argued, at least shouldn't 'isbn' automatically be > > part of the 'bk' namespace? Still no, I'm afraid. Every member of a > > namespace is meant to be unique. > > Well, not quite. An element can have the same name as a global > attribute without problem. In a similar vein, one unqualified attribute defined for one element can have the same name as another unqualified attribute of another element without sharing the same declaration. More than one kind of "namespace" is necessary to interpret an xml document which conforms to the spec. One kind of space maps QName's and Name's to identifiers. Another kind maps identifiers to declarations. The namespace spec itself does not do justice to this, and, in fact, introduces - in relation to the notion of universal attribute names - the impression that XML requires a Name -> Identifier -> Attribute-Declaration mapping/namespace, when it does not. While one could accept that the illusion of such a namespace is helpful for things like XSL patterns, this kind of namespace is not entailed by the xml spec itself. It specifies a mapping of the form Name -> Identifier -> Identifier -> Attribute-Declaration. That is, it requires an element identifier in addition to an attribute identifier in order to identify a declaration. > ... There is a contradiction, AFAI can see, > between clause 5.3 and Appendix A, and obviously 5.3 is normative. > ? While I recognize a contradiction between Bray's interpretation of the body of the spec and its Appendix A, I don't seen one between the spec itself and Appendix A. Following A.3, example 1, line 5, the form from 5.3 would have the equivalent (extended) Clark encoding (http://www.jclark.com/xml/xmlns.htm) <{http://www.w3.org}x xmlns:n1="http://www.w3.org" xmlns="http://www.w3.org" > <{http://www.w3.org}good {{http://wwww.w3.org}good}a="1" {{http://wwww.w3.org}good}b="2" /> <{http://www.w3.org}good {{http://wwww.w3.org}good}a="1" {http://www.w3.org}a="2" > which would appear conformant. Where is the contradiction? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Feb 2 21:12:44 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:26 2004 Subject: Another errata? Message-ID: John Cowan wrote: > Mark Birbeck wrote: > > > OK then, some have argued, at least shouldn't 'isbn' > automatically be > > part of the 'bk' namespace? Still no, I'm afraid. Every member of a > > namespace is meant to be unique. > > Well, not quite. How not quite? A namespace is a set of unique entries *by definition*. That's what they are - a set of unique entries. You can't have a 'set of unique entries' that contains a duplicate. > An element can have the same name as a global > attribute without problem. True. But they are not in the same namespace. According to A.2 the element would be in the 'all element types' partition, and the global attribute would be in the 'global attribute' partition. > There is a contradiction, AFAI can see, > between clause 5.3 and Appendix A, and obviously 5.3 is normative. Well why not spell it out then, since I can't see one? I can only guess what you are driving at, so I'll go through 5.3 (anyone interested in this might want to open http://www.w3.org/TR/REC-xml-names/ whilst reading): In XML documents conforming to this specification, no tag may contain two attributes which: 1. have identical names, or 2. have qualified names with the same local part and with prefixes which have been bound to namespace names that are identical. Well, number 1 is already given by XML 1.0. You cannot have: so I assume that is not where your contradiction lies. To look at the second point; the following *would* be OK in XML 1.0 (colons are fine, as per http://www.w3.org/TR/PR-xml-971208#NT-Nmtoken): However, the spec is saying that it becomes illegal - if you want your XML document to conform to the namespace spec - to use the above attribute names if you have bound the prefixes to namespaces as follows: because first:name and sur:name would end up being the same thing (uri:mycodes:name). (Note that it still does NOT break the XML 1.0 spec.) A.4 suggests how this might be implemented using 'expanded attribute names', saying that every EAN must be unique. (EANs include the URI that a namespace prefix points to as an attribute, not the prefix itself.) Of course, this might not be the source of your contradiction either. Given there's only one bit of 5.3 that I haven't discussed here (it's not that big), I guess you think the contradiction is in the 'good' example: However, each of the following is legal, the second because the default namespace does not apply to attribute names: I can only assume that you mean that this breaks the uniqueness rule, but it doesn't. If we look at the attributes both from the perspective of partitions or of expanded attribute names we will see that they are completely unique. PARTITIONS 'a' and 'n1:a' are in different namespace partitions, as described above. 'n1:a' is actually a global attribute and so appears in the 'global attribute' partition, whilst 'a' would be in the 'per-element-type' partition for the element 'good'. If we use '^' to break partitions, namespaces and local names, your have two completely different attributes. 'n1:a' becomes: GA^http://www.w3.org^a where 'n1' has been mapped to its full URI, and 'a' becomes: PET^good^a i.e., 'a' is in the 'good' namespace within the 'per-element-type' partition (because it is unqualified). EXPANDED ATTRIBUTE NAMES 'a' and 'n1:a' also have very different expanded attribute names. 'a' has: whilst 'n1:a' has: As you can see - completely different. One actually has a namespace attribute the other doesn't, and instead gets attributes of the type and namespace of the element that owns it. So where is the contradiction? I don't know why these standards guys are getting such a hard time - particularly with all these poorly worked through criticisms. IMHO if you want to be at the leading edge of technology then you have to put the work in - read, read, and re-read. It is not the job of standards developers to make sure we understand everything they write, although there is no problem with asking for clarification. But if instead of the phrase 'I don't understand' you choose 'there is a contradiction' then at least show some respect for their work and take the trouble to spell out what you think it is - and don't be surprised if a rant comes back ;-) Rant over ... Regards, Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From fasthand at bigfoot.com Tue Feb 2 21:55:47 1999 From: fasthand at bigfoot.com (fasthand@bigfoot.com) Date: Mon Jun 7 17:08:26 2004 Subject: ANN: ezDTD v1.5 -- DTD Editor/Generator/Formatter In-Reply-To: <3.0.1.16.19990114192641.4b97656e@pop3.demon.co.uk> References: <5F052F2A01FBD11184F00008C7A4A80001136A14@eukbant101.ericss on.se> Message-ID: <199902022200.QAA52233@cotton.vislab.olemiss.edu> ezDTD v1.5 DTD Editor/Generator/Formatter ---------------------------------------------------------------- FOA, please forgive me if you receive this mail more than once. ezDTD is a freeware for DTD authoring. (WIN95+ or NT) - ezDTD can be use as as an alternative besides commercial DTD editor and text editor, and - ezDTD can convert DTD to HTML with internal links. ezDTD is a text-base DTD editor. Unlike some commercial DTD tools which present DTD in graphic mode, ezDTD forms the DTD into HTML format. So author can navigate the document via hyperlinks. The latest ezDTD is v1.5. You can fint it at http://www.geocities.com/SiliconValley/Haven/2638/ezDTD.htm o Why create ezDTD? ezDTD, as a handy tool, it can help 1. Quickly jumping from one element to another. 2. Complete the typing by filling something like ANY, EMPTY, #IMPLIED .. etc. 3. Export a HTML-format DTD file which has internal links among elements. Since this version ezDTD can import existing DTD, you can use it to create HTML-format document for existig DTD as well. o What's new? Version 1.5 (1999-01-20) - Simplified interface. - View/Browse the DTD in HTML format on the fly. Version 1.1 (1998-02-12) - Modify some interface. - You can import a DTD file. As long as it does not have too complex comment structure. - Support Start Tag and End Tag definition. - Export DTD in either SGML or XML fashion (with or without the minization) - Correct the including example file appraisal.edz which did not explain itself clear enough. o Download Please check out http://www.geocities.com/SiliconValley/Haven/2638/ezDTD.htm Thanks for your time Duncan Chen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Duncan Chen fasthand@bigfoot.com FNC, Inc. 601-232-1218 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 2 22:03:34 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:08:26 2004 Subject: Namespaces Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEEFA@RED-MSG-08> James has done an outstanding job of explaining what namespaces are and are not. I especially recommend his document because it accurately stops short of implying that there is more to the namespaces specification than is there. --Andrew Layman co-editor of the Namespaces spec xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 2 22:15:55 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:26 2004 Subject: Another errata? References: Message-ID: <36B778F8.B3FCCFD7@locke.ccil.org> Mark Birbeck wrote: > How not quite? A namespace is a set of unique entries *by definition*. > That's what they are - a set of unique entries. You can't have a 'set of > unique entries' that contains a duplicate. That is not the definition of "namespace" used by REC-xml-names. Clause 1 specifically denies that XML namespaces are sets. > > An element can have the same name as a global > > attribute without problem. > > True. But they are not in the same namespace. According to A.2 the > element would be in the 'all element types' partition, and the global > attribute would be in the 'global attribute' partition. They are in separate partitions of the same namespace. > Of course, this might not be the source of your contradiction either. Appendix A says that unprefixed attributes are assigned to one of the per-element-type partitions of the namespace. It also says that unprefixed attributes are assigned to "associated namespaces". Clause 5.3 is not involved and I shouldn't have dragged it in. But none of this matters much because Appendix A is not normative. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msf at mds.rmit.edu.au Tue Feb 2 22:21:35 1999 From: msf at mds.rmit.edu.au (Michael Fuller) Date: Mon Jun 7 17:08:26 2004 Subject: What is a good database for very large collections? (was Re: XSL/ECMAscript (was RE: Frontier as a scalable XML repository (was Re: Is XML dead already or what?)) In-Reply-To: ; from Rick Jelliffe on Tue, Feb 02, 1999 at 04:18:11AM +1100 Message-ID: <19990203092046.A11167@io.mds.rmit.edu.au> On Tue, Feb 02, 1999, Rick Jelliffe asked: > What is a good database for XML? [Warning: product-related discussion follows.] Why not look at systems that are built around an SGML data model, rather than built over the top of a OODBMS or RDBMS model? SIM, the "Structured Information Manager", is a commercial XML/SGML system produced here at RMIT (I am not personally involved in its development but work with people who are; they are the source for some of the following; see http://www.simdb.com/ for more information). For me, the key issue is that SIM stores and parses XML documents natively. SIM is optimised to efficiently store, index, and retrieve XML/SGML documents from multi-gigabyte collections under heavy concurrent user loads. XML/SGML documents can also be formated or manipulated using an SGML scripting language (free from http://ace.mds.rmit.edu.au/). XML/SGML document structure can be directly queried. Although SIM does not directly AI and linguistic software, it does have free text querying, ranking, lots of text searching functions; it also has the ability to define standing queries so that new records that match a standing query are brought to the attention of users (normally via nightly email). On the scalabity side of things, SIM supports incremental updates on live systems. SIM had been used by customers with 800 'concurrent' users over the web; by customers with databases of >6gb and >3,000,00 records; to run in-house test collections of around 50gb. Michael Fuller ____________________________________________________________________________ Multimedia Databases Systems, Phone: +61 3 9925 4148 RMIT University Fax: +61 3 9925 4098 Level 3, 110 Victoria St, msf@mds.rmit.edu.au Carlton 3053, Australia. http://www.mds.rmit.edu.au/~msf/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From derekdb at microsoft.com Tue Feb 2 22:29:59 1999 From: derekdb at microsoft.com (Derek Denny-Brown) Date: Mon Jun 7 17:08:26 2004 Subject: Compositional Documents Message-ID: <8B57882C41A0D1118F7100805F9F68B506F1BD55@RED-MSG-45> The problem with the code below is that the first: doc.appendChild( docFrag ); moves the contents of docFrag into doc. It does not copy/clone or otherwise duplicate, but rather removes the contents of the document fragment, and appends them to the list of children of doc. Before executing that line, the following would be a true assertion: docFrag.getChildNodes().getLength() == 1 after executing that line the following is true docFrag.getChildNodes().getLength() == 0 Thus executing the following tidbit after the above doc.appendChild(docFrag), is an obfuscated no-op. doc2.appendChild( docFrag ); -derek -----Original Message----- From: Chris Berry [mailto:CBerry@works.com] Sent: Tuesday, February 02, 1999 10:11 AM To: 'xml-dev@ic.ac.uk' Subject: Compositional Documents Greetings, Sorry for the wasted bandwidth, but I posted this last night (without a Subject) and did not receive any response. I'm hoping this time around I might be luckier... I am a relative newbie to XML, so please bear w/ me if this is a poor question... It looks like everything in the DOM must be dealt w/ in the context of a particular document. It seems you cannot drop one Document into another, or even one DocumentFragment into another Document context. I have tried to do the following... (using Microsoft's implementation of the DOM) IXMLDOMDocument doc = (IXMLDOMDocument) new DOMDocument(); IDOMDocumentFragment docFrag = doc.createDocumentFragment(); IDOMElement userElem = doc.createElement("USER"); userElem.setAttribute("TIMESTAMP", new Variant("123456") ); docFrag.appendChild( userElem ); doc.appendChild( docFrag ); System.out.println( doc.getXml() ); // >>>> Yields the correct results IXMLDOMDocument doc2 = (IXMLDOMDocument) new DOMDocument(); doc2.appendChild( docFrag ); System.out.println( doc2.getXml() ); // >>>> Yields an empty string It seems like this should work to me. Shouldn't we be able to cut and paste between documents?? Or more important, shouldn't we be able to build up documents compositionally?? I.e. compose Address 1 and Address 2 as DocumentFragments (or as their own Documents -- with their own DTDs) and then drop these into, say, User (providing that the User DTD agrees). I must be missing something here. Thanks in advance, Cheers, -- Chris Chris Berry cberry@works.com 512-231-1341 works.com 6850 Austin Center Blvd. Austin, TX 78731 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cvonsee at onramp.net Tue Feb 2 22:52:15 1999 From: cvonsee at onramp.net (Chris von See) Date: Mon Jun 7 17:08:27 2004 Subject: Compound Documents - necessary for success? In-Reply-To: Message-ID: <199902022251.QAA09621@mailhost.onramp.net> At 05:52 PM 2/2/99 +0000, Mark Birbeck wrote: > >Well, sort of. But note that you can use namespaces even without using a >DTD. A standalone document that is well-formed might still want to have >the following, in order to provide clues to any application that is >processing it: > > > > Fred > > blonde > > > >In this example, if the application was going to process 'type' in a >certain way (say an XSL processor), then it needs the namespaces to help >it work out which 'type' is which. Also, if the namespace wasn't there, >then you wouldn't be able to use both 'type' attributes in the same >element. But note that no schemas need be involved. Without a DTD or schema on which to "hang your hat", so to speak, you're vesting the application with the knowledge of what the various namespace-qualified constructs mean. This strikes me as a Very Bad Thing, because it leaves individual applications to interpret (potentially, interpret very differently) what a particular attribute or element means. Generating a specific meaning and rules for usage for a particular DTD or schema isn't "automagic", but at least it forces people to think about what they're doing and lends some semblance of order. For small applications you can get away with not having such an anchor point, but for anything larger than a few documents you're asking for trouble. > >Conversely, if you devise a DTD that uses another DTD, you don't >necessarily need to use namespaces. In the height/player example given >before there is no ambiguity, so why would you introduce a namespace? Granted, as long as there are no conflicts in naming between the DTDs. However, as soon as you change a DTD you get into problems with DTD versioning, and as soon as you clone it to add the new DTD reference the proliferation of DTDs introduces a potential management problem. Yuk. > >So, back to compound documents. I think as a stop-gap you need dynamic >DTDs. Just as many features of XML are best implemented using dynamic >documents generated from databases, why not generate a top-level DTD >that contains whatever lower level DTDs it needs to define the relevant >compound XML document? The top DTD would include some basic stuff for >containing a list of documents, and then include whatever other DTDs it >needs for each document in turn. In order to do what you're proposing, you have to have knowledge *somewhere* of what is and is not acceptable... just as RDBMS catalogs govern the creation of dynamic DTDs for database data, so you would have to provide some sort of intelligence in your DTD generation mechanism to prevent unwanted, ambiguous usage. Chris ------------------------------------ "Beware of all enterprises that require new clothes." -- Thoreau xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Tue Feb 2 22:56:00 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:27 2004 Subject: 5.3 and Appendix A contradiction [Re: Another errata?] Message-ID: james anderson wrote: > John Cowan wrote: > > > > Mark Birbeck wrote: > > > > > OK then, some have argued, at least shouldn't 'isbn' > automatically be > > > part of the 'bk' namespace? Still no, I'm afraid. Every > member of a > > > namespace is meant to be unique. > > > > Well, not quite. An element can have the same name as a global > > attribute without problem. [I've replied to this in the 'Another errata?' thread] > In a similar vein, one unqualified attribute defined for one > element can have > the same name as another unqualified attribute of another > element without > sharing the same declaration. A very odd response! Follow the three comments through: - in response to demands for more errata I say that an unqualified attribute should *not* automatically join the namespace of its element - as part of my justification I say that all members of a namespace must be unique, and then go on - John disagrees - although why I don't know, because that's what a namespace is - and backs up his argument by saying that an element and a global attribute can have the same name. But that doesn't prove that namespaces can have duplicates, because they are actually in different namespaces - and then James comes to his assistance by adding that an unqualified attribute for one element can have the same name as an unqualified attribute on another element BUT WHY?! Well ... because an unqualified attribute does not automatically join the namespace of its element!! If it did then you would have duplicates in your namespace, because they are different attributes. Sound familiar? > More than one kind of "namespace" is necessary to interpret > an xml document > which conforms to the spec. One kind of space maps QName's > and Name's to > identifiers. If we're going to pursue this to the bitter end ... you can't have a 'Name' in a conforming doc, they must all be 'QNames' (no colons except after a prefix). > The namespace spec itself does not do justice to this, and, in fact, > introduces - in relation to the notion of universal attribute > names - the > impression that XML requires a Name -> Identifier -> > Attribute-Declaration > mapping/namespace, when it does not. While one could accept > that the illusion > of such a namespace is helpful for things like XSL patterns, > this kind of > namespace is not entailed by the xml spec itself. It > specifies a mapping of > the form Name -> Identifier -> Identifier -> > Attribute-Declaration. That is, > it requires an element identifier in addition to an attribute > identifier in > order to identify a declaration. This may be true - that XML does NOT require this - but I think the spec rightly draws attention to its need in many applications. Take for example the difficulty of dealing with global attributes. Say that I want every single node in a magazine article to have a unique identifier so that if it gets edited I can put it back into the database easily. I might define:
My Article An interesting thingy. More of the same.
Without the namespace spec, 'id' is in four different namespaces. Now you're right that each has context: article->id article->title->id and so on, but I disagree with you saying that this contextual information 'is enough'. What if I wanted to process all database 'id' values? Say my application needs to work out if any nodes have been deleted before returning the data to my database. Well OK, you could say, in XSL-style syntax: */attribute(id) or whatever it is. That is - give me all elements that contain an 'id' attribute. But what if we were to add an additional 'id' attribute, say for use by some other site to allow paragraphs to be quoted. And say also, that it was not a requirement of each node to have a database 'id' value. Then without namespaces we get:
My Article An interesting thingy. More of the same.
Now my poor old database application cannot tell the difference between the database version of 'id' on 'article', 'title' and 'paras' and the reference version of 'id' on 'para' - unless of course we process every single node that comes back from the '*/attribute(id)' query, or we query for each of the possible types. But with namespaces I can say 'give me every id value in the uri:mydatabasespec namespace'. Of course, you could argue that I should just name my attributes something else - 'db:id' perhaps - and then I can query them uniquely. But what if I want to use two DTDs, and someone else has used 'db:id'? I'm back to square one again. Whichever way you turn, if you want to assist applications built on an XML processor - and I believe 'assist' is all that is being said in the spec - namespaces are very, very handy. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nikita.ogievetsky at csfb.com Tue Feb 2 23:19:41 1999 From: nikita.ogievetsky at csfb.com (Ogievetsky, Nikita) Date: Mon Jun 7 17:08:27 2004 Subject: Another errata? Message-ID: <9C998CDFE027D211B61300A0C9CF9AB44246E3@SNYC11309> Mark Birbeck wrote: > xmlns:bk='urn:loc.gov:books'> > > Cheaper by the Dozen > > > A list of loads of books > > >In this case, 'auto-joining' an attribute to its element's namespace >would make 'isbn' into a *global* attribute. Handy, if you wanted to >process all bk:isbn numbers in a document - but wrong!! In this document >we do NOT have two instances of bk:isbn, we have one of bk:book:isbn and >one of bk:catalogue:isbn. .............................. >this is OK: > y > >and this is not good practice at all (see Andrew Layman's comments on >this, too): > y > Seems that we should think of the namespace scope here. Imagine if Schema designer was not creative and instead of isbn used id And to identify authors he also used id attribute, say ssn (being picky, one can invent a datatype for ssn: xxx-xx-xxxx) Cheaper by the Dozen Now how do we know if book's id belong to default namespace or to bk? Or, if child inherits namespace from parents, should not the above be equal to: Cheaper by the Dozen It should because I should freely be able to convert this XML to another where title is an attribute. equal to so either both are valid or not. Now, what if inside the book we want to use default id (ssn) - for editor? Or can't we ? (trully I can not imagine a reasoble situation to do so...) There is no prefix for it. Looks like a mess... Any toughts? Nikita Ogievetsky Cogitech Inc http://www.cogx.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Tue Feb 2 23:32:39 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:08:27 2004 Subject: Since we're talking about databases... References: <3.0.32.19990201164621.00a5e360@pop.intergate.bc.ca> <36B65517.8FAE4EC5@manhattanproject.com> Message-ID: <36B78A5B.2FAF@hiwaay.net> Take a look at the papers of Dr. Michael Stonebraker (www.informix.com) on the design of relational databases with object support designed into the kernel which enable user-defined extensions, support for complex types, etc. His claim is that this approach is the new generation of db. He posits arguments and figures for the performance of this approach over middleware that might be interesting. I find myself wondering about how this approach would work if XML support were built into the kernel. Stonebraker posits it would be far superior for 3D. Since we have some experience with geodata and the performance problems of keeping this in the relational db (not the way to go), I wonder if architectural issues with XML systems that rely on middleware will be similar. len bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Feb 2 23:43:25 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:27 2004 Subject: Compound Documents - necessary for success? In-Reply-To: <199902022251.QAA09621@mailhost.onramp.net> References: <199902022251.QAA09621@mailhost.onramp.net> Message-ID: <14007.35658.443324.182548@localhost.localdomain> Chris von See writes: > Without a DTD or schema on which to "hang your hat", so to speak, > you're vesting the application with the knowledge of what the > various namespace-qualified constructs mean. This strikes me as a > Very Bad Thing, because it leaves individual applications to > interpret (potentially, interpret very differently) what a > particular attribute or element means. The situation that Chris describes exists with or without a DTD. Imagine that I have a DTD containing the following: I know where

is allowed to appear, and I know what it is allowed to contain, but I know *nothing* more about what it means -- that information is still hard-coded in an application somewhere. I am a big fan of DTDs and have even written a book on them, but I don't buy the 'discipline-of-writing-a-DTD-makes-you-think' model any more than I buy the 'discipline-of-learning-Latin-makes-you-think' model (and I enjoy reading Latin). Namespaces actually help the problem a bit: they still do not tell me what an element means (and I will be stunned if the result of the XML Schema WG's work does that either), but at least they provide a global point of reference. I do not know if

in document A and

in document B are meant to have anything in common, but I do know that (using James Clark's notation) <{http://www.megginson.com/ns/doc/}p> in document A and <{http://www.megginson.com/ns/doc/}p> in document B are meant to have something in common. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Tue Feb 2 23:44:01 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:27 2004 Subject: Another errata? Message-ID: John Cowan wrote: > Mark Birbeck wrote: > > How not quite? A namespace is a set of unique entries *by > definition*. > > That's what they are - a set of unique entries. You can't > have a 'set of > > unique entries' that contains a duplicate. > > That is not the definition of "namespace" used by REC-xml-names. > Clause 1 specifically denies that XML namespaces are sets. Clause 1 refers to the definition of 'XML namespace', which, as you rightly say, is not a set. But as I understand it an 'XML namespace' comprises numerous 'namespaces' (in the sense in which I used it) which each DO have unique entries, because they *are* sets. My understanding of the motivation for this is that if a single 'namespace' (i.e. set) was used then we would lose contextual information about a name. We therefore partition them in order to preserve this information. An 'XML namespace' is therefore a 'namespace container' that is not itself a 'namespace'. Clause 1 seems to put the emphasis on the presence of structure, rather than the lack of uniqueness. > > > An element can have the same name as a global > > > attribute without problem. > > > > True. But they are not in the same namespace. According to A.2 the > > element would be in the 'all element types' partition, and > the global > > attribute would be in the 'global attribute' partition. > > They are in separate partitions of the same namespace. No again - they are in separate partitions of the same 'XML namespace'. Each partition is itself a namespace. A.2 has it that: ".. we identify the names appearing in an XML namespace as belonging to one of several disjoint traditional (i.e. set-structured) namespaces ..." > Appendix A says that unprefixed attributes are assigned to one of the > per-element-type partitions of the namespace. It also says that > unprefixed attributes are assigned to "associated namespaces". Nothing wrong with that. Each element appears by name in the 'all elements type' partition. However, each element also has its own partition - a 'per-element-type' partition - into which are collected all the unqualified attributes for that element. This PET partition is a true 'namespace' (in the sense I used it) because from XML 1.0 we know that we cannot have duplicate attributes on an element. And that is why the spec refers to it as an 'associated namespace' - associated to the element. > Clause 5.3 is not involved and I shouldn't have dragged it in. I see. > But none of this matters much because Appendix A is not normative. I suppose so. But it does help to understand what it is that is making a particular element or attribute name unique with the entire document. I particularly think that the expanded attribute stuff is very useful. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 2 23:46:11 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:08:27 2004 Subject: Since we're talking about databases... In-Reply-To: <36B78A5B.2FAF@hiwaay.net> Message-ID: <000701be4f05$b9282800$5118a8c0@kuantech1.quokka.com> Please please please let this list not degenerate into a philosophical debate about the merits of various approaches to database design. I have been following the relational vs. object vs. object-relational debate for some ten years now, and the mere mention of Dr. Stonebraker's name still makes me shiver. :-) Jeff -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of len bullard Sent: Tuesday, February 02, 1999 3:30 PM To: xml-dev@ic.ac.uk Subject: Re: Since we're talking about databases... Take a look at the papers of Dr. Michael Stonebraker (www.informix.com) on the design of relational databases with object support designed into the kernel which enable user-defined extensions, support for complex types, etc. His claim is that this approach is the new generation of db. He posits arguments and figures for the performance of this approach over middleware that might be interesting. I find myself wondering about how this approach would work if XML support were built into the kernel. Stonebraker posits it would be far superior for 3D. Since we have some experience with geodata and the performance problems of keeping this in the relational db (not the way to go), I wonder if architectural issues with XML systems that rely on middleware will be similar. len bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 00:04:49 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:27 2004 Subject: Compound Documents - necessary for success? Message-ID: Chris von See wrote: > Without a DTD or schema on which to "hang your hat", so to > speak, you're > vesting the application with the knowledge of what the various > namespace-qualified constructs mean. This strikes me as a > Very Bad Thing, > because it leaves individual applications to interpret (potentially, > interpret very differently) what a particular attribute or > element means. [and] > Generating a specific meaning and rules for usage for a > particular DTD or > schema isn't "automagic", but at least it forces people to > think about what > they're doing and lends some semblance of order. All a DTD can do is say something about the structure of a document. If someone wants to write an application that uses your CD collection data as a basis for their long-term investment plans on, you - and your DTD - can't stop them, other than by keeping the data to yourself. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 00:42:17 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:27 2004 Subject: Stripping leading and trailing spaces??? In-Reply-To: <000001be4ee3$060e5d60$a39b56d1@danf> References: <000001be4ee3$060e5d60$a39b56d1@danf> Message-ID: <14007.39575.773121.658045@localhost.localdomain> Dan Finkelstein writes: > It seems that leading and trailing spaces are being removed from > PCDATA before it is returned to me. For example, > > Hello there! > comes back as "Hello there!" instead of " Hello there! ". I'm > using Sun's early release parser, and I'm wondering if this is > standard XML behavior? if there is a way to preverse the spaces? Which interface are you using? If you're using SAX, it could be that the spaces are being delivered in separate characters() events (parsers are allowed to chunk up character data any way they want). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Wed Feb 3 00:59:49 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:27 2004 Subject: Interesting Monday. In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136ADF@eukbant101.ericss on.se> Message-ID: <4.1.19990203115244.00bc0d40@steptwo.com.au> At 19:11 2/02/1999 , Matthew Sergeant (EML) wrote: | > I would personally recommend a third option: | > | > 3) Store in RDBMS now, process into XML, process this into HTML now. | > Process the XML into whatever you want in the future. | > | > | Nonononono. :) | | This generates probably 5% more overhead than I have already (the | RDBMS). XML doesn't parse quickly (well, OK, it parses quickly, but not | compared to reading data from an RDBMS). When you are processing tens of XML | files per second this becomes a huge problem. Well, I guess you have to balance elegance & expandability vs raw performance. Not an uncommon trade-off ... But, that being said ... Creating XML from an RDBMS is very quick, particularly when you do it using straightforward non-XML code. True, XML->HTML is not as quick as would be liked, but it again depends on the nature of the work. If your HTML needs a lot of complex cross-linking, tables of contents, navigation bars, etc, then doing this straight from the RDBMS can be a real bitch. Also, the speed of processing XML will depend on the tool. Have you considered using something like Omnimark, instead of DOM, etc? Just some more food for thought, J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Feb 3 02:59:56 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:08:27 2004 Subject: Namespaces Message-ID: <014801be4f21$17207230$2ee044c6@arcot-main> >James has done an outstanding job of explaining what namespaces are and are >not. I especially recommend his document because it accurately stops short >of implying that there is more to the namespaces specification than is >there. I agree wholehearted. I would like to reccommend that we use James' document as the start of the "XML Namespaces FAQ" and build on it. The question is not "can we understand it?" but "can my customers understand it?". Cheers, Don Park Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Feb 3 04:54:59 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:27 2004 Subject: Interesting Monday. References: <5F052F2A01FBD11184F00008C7A4A80001136ADF@eukbant101.ericsson.se> Message-ID: <36B7D4B1.4ADAB18F@prescod.net> "Matthew Sergeant (EML)" wrote: > > Nonononono. :) > > This generates probably 5% more overhead than I have already (the > RDBMS). XML doesn't parse quickly (well, OK, it parses quickly, but not > compared to reading data from an RDBMS). When you are processing tens of XML > files per second this becomes a huge problem. You could build a parse tree in a "servlet" and hand it right to an XSL stylesheet. The benefit of this is that you have the modularization of having style application be independent of your database structure but you don't actually create a file, start another process, parse the file and continue. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 04:57:03 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:27 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: Message-ID: <36B7D362.1FF821D4@prescod.net> Mark Birbeck wrote: > > if that was a better model of the internal data. Maybe I've missed the > subtlety of what you are saying the problem is, but in our system the > attributes of an object are exported as described above, and the > children of an object are exported as elements within other elements. > Seems to me to mirror exactly our object structure - and so far we have > been able to re-interpret DTDs back as data definitions. In other words, > we *can* generalise the solution. If I understand correctly: * what you are saying is that you can define (have defined!) a convention such that you achieve lossless serialization of XML data through XML. What Eliot is saying is: * XML isn't doing the "heavy lifting" here, your *convention* is doing the heavy lifting. If someone handed you data that meant the same thing but did not use your convention you would be as lost as if the data were EBCDIC ISAM files. XML is doing the "light lifting" of allowing you to avoid writing a parser for EBCDIC ISAM files (or, more likely, LISP S-expressions). YEAH FOR XML! Helping with light lifting is important. Saving money is important. It just doesn't solve the hard problems. Non-ambiguous serialization has not been a hard problem since the invention of S-expressions. > Sure. But I still have two issues. First, why would you query the > serialisation anyway? Wouldn't you want to query your original database > and generate XML pages that reflect the results? You certainly would if you use XML as *only* a serialization. The thrust of this thread was that some people want to encode everything in XML so that they can "query it." But XML is a lousy query representation for anything other than human-authored documents. (and debatably the best thing for queries against those!) > You keep talking of the 'abstract' representation > of your data, but actually you are *losing* the abstraction, moving > from: > > a person who has the name Eliot > > to > > an object which contains another object which has two > properties, one set to name and the other set to Eliot > > Of course both are abstractions, but they model completely different > things (data and people). I think that this is Eliot's point. Consider someone who says that if you put a "DOM interface" on all objects everywhere in the system then they all become managable because they have a "single API." Smart (but usually inexperienced) people say this. These people are talking about an API to the serialization structure instead of an API to their original data. They've gained some uniformity but lost some abstraction. That is very seldom a useful trade-off. To make their processing useful again their very next step will be to add in some abstraction on top of the DOM. Then they're back to where they started. This is one of the most pervasive misunderstandings in XML-world. > And modelling the data rather than the person > means you can no longer interchange your XML with other systems because > you have two completely different sets of data, using different DTDs. I don't follow that. > (And you can't say that your serialisation schema *will* allow this > interchange, because although your serialised data may be well-formed, > the underlying data it represents may not be, so you need the proper DTD > for the object.) Well-formedness has very little to do with DTDs so I don't follow this either. > All I am saying is that the document *itself* could be the abstraction > of the data. This is something else I don't follow. XML documents are always encodings of abstractions. They are concrete, tangible, interchangable, printable and can be given global names. Concrete, not abstract. The objects they represent are logical, usually inaccessible outside of an "address space" (i.e. your brain, your relational database) and are thus termed abstract. The reason we need XSL is because the abstractions cannot "stand alone". I can't transmit a book from my head to your head. I need to serialize it on paper or online. I also can't transmit a "book object" without serializing it somehow (i.e. XML). Before serialization it is an abstraction. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 05:38:22 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:27 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <36B7D362.1FF821D4@prescod.net> Message-ID: <000e01be4f36$c7b29370$d3228018@jabr.ne.mediaone.net> Paul Prescod wrote: ... > > You certainly would if you use XML as *only* a serialization. The thrust > of this thread was that some people want to encode everything in XML so > that they can "query it." But XML is a lousy query representation for > anything other than human-authored documents. (and debatably the best > thing for queries against those!) > and later... > > I think that this is Eliot's point. Consider someone who says that if you > put a "DOM interface" on all objects everywhere in the system then they > all become managable because they have a "single API." Smart (but usually > inexperienced) people say this. These people are talking about an API to > the serialization structure instead of an API to their original data. > They've gained some uniformity but lost some abstraction. That is very > seldom a useful trade-off. To make their processing useful again their > very next step will be to add in some abstraction on top of the DOM. Then > they're back to where they started. > > This is one of the most pervasive misunderstandings in XML-world. You have missed the point here. If I put a DOM interface onto a SQL Server or Oracle or ODI or Poet database, I am hardly using an API to the serialization structure. When people say this, they mean that the DOM API/interface is used against the native datastore. The utility of this would demonstrate itself in a distributed environment where something like XQL was used as a query language. If we are in the relational db world, ODBC/SQL 92 provides an interface onto disparate databases. Not all information is stored on relational dbs. The DOM interface aims to provide the same database and vendor neutrality and interoperability that ODBC or JDBC provides for tabular data. If I am using a DOM interface, it frankly doesn't matter what the serialization format is, I am interacting directly with data through an interace. I wouldn't suggest that the DOM replace ODBC, yet I'm quite sure that those experienced using a variety of systems with disparate data types and data usages will appreciate that certain types of data are best expressed in tree format. Such data scenario's might best be interfaced with via the DOM. XSL transforms can be applied directly to DOM representations, rather than serialized XML documents. This yeilds the possibility that serial transforms be applied within 'DOM space' (assuming the XSL transform output is a DOM structure rather than a serialized string). The act, thus, of web page generation from a database can be automated via XSL rather than, say ASP or perl scripts. Is this useful? Sometimes it is. Are the DOM interfaces the best for all situations, clearly not. However if a significant percentage of people can agree to use them a significant percentage of the time, this is a big win. 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Wed Feb 3 08:58:12 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:08:28 2004 Subject: Fw: Namespaces Message-ID: <008e01be4f52$a23b2410$5402a8c0@oren.capella.co.il> Don Park wrote: >I would like to recommend that we use James' document as the start of the >"XML Namespaces FAQ" and build on it. The question is not "can we >understand it?" but "can my customers understand it?". Excellent notion. While we are at it, here's a question which seems to be at the heart of the issue and which, alas, James didn't address: global attributes. Andrew Laymen has made a pretty good case that they simply don't exist. However most of the wrangling about namespaces seem to refer as to how they are handled. If Andrew is wrong, I'd like to know why. If he's right, what is the debate about? I note that this contradicts a sample which was not challenged by anyone: would have the equivalent (extended) Clark encoding (http://www.jclark.com/xml/xmlns.htm) <{http://www.w3.org}x xmlns:n1="http://www.w3.org" xmlns="http://www.w3.org" > <{http://www.w3.org}good {{http://wwww.w3.org}good}a="1" {{http://wwww.w3.org}good}b="2" /> <{http://www.w3.org}good {{http://wwww.w3.org}good}a="1" {http://www.w3.org}a="2" > >From reading Andrew's post I presumed it would be converted to: <{http://www.w3.org}x xmlns:n1="http://www.w3.org" xmlns="http://www.w3.org" > <{http://www.w3.org}good {{http://wwww.w3.org}good}a="1" {{http://wwww.w3.org}good}b="2" /> <{http://www.w3.org}good {{http://wwww.w3.org}good}a="1" {{{http://www.w3.org}good}http://www.w3.org}a="2" > On what is the previous interpretation based? If the second one is correct, wouldn't it solve all the issues? Take Mark's example of multiple use of 'id'. It would become immediately clear that the XSL pattern: */attribute(id) Would match: */attribute({}id) While the pattern: */attribute(db:id) Would match */attribute({{} Jerome McDonough wrote: > *Don't* think that you can do this with > Microsoft Access (not sure about other Microsoft products). Having spent > a month trying to persuade both Intersolv's and Microsoft's JDBC/ODBC bridges > to not blow up in my face after three queries into Access, I think I can > vouch for that not being a stable solution. The problem might be the bridge, not the Access driver or Access. I've been using Sun's JDBC/ODBC bridge with Microsoft's Access driver for quite a while without any problems. (Sun JDK 1.1.7, Windows NT 4.0 (service pack 3), MS Access driver 3.50.360200). -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Wed Feb 3 09:41:56 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:28 2004 Subject: Interesting Monday. Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AE8@eukbant101.ericsson.se> > -----Original Message----- > From: Paul Prescod [SMTP:paul@prescod.net] > > "Matthew Sergeant (EML)" wrote: > > > > Nonononono. :) > > > > This generates probably 5% more overhead than I have already > (the > > RDBMS). XML doesn't parse quickly (well, OK, it parses quickly, but not > > compared to reading data from an RDBMS). When you are processing tens of > XML > > files per second this becomes a huge problem. > > You could build a parse tree in a "servlet" and hand it right to an XSL > We're looking at several possibilities now to increase performance. I'm not terribly worried about my particular application. Although it will be a parse tree stored in mod_perl, not a servlet . The overall issue is now a concern for XML e-commerce. You can't cache or store parse trees for XML data that isn't static in any way, and that you only use once and then throw away. 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 09:48:40 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:28 2004 Subject: Interesting Monday. Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AE9@eukbant101.ericsson.se> > -----Original Message----- > From: James Robertson [SMTP:jamesr@steptwo.com.au] > > At 19:11 2/02/1999 , Matthew Sergeant (EML) wrote: > > | This generates probably 5% more overhead than I have already (the > | RDBMS). XML doesn't parse quickly (well, OK, it parses quickly, but > not > | compared to reading data from an RDBMS). When you are processing tens > of XML > | files per second this becomes a huge problem. > > Well, I guess you have to balance elegance & expandability vs raw > performance. Not an uncommon trade-off ... > Indeed. > But, that being said ... > > Creating XML from an RDBMS is very quick, particularly when you > do it using straightforward non-XML code. > > True, XML->HTML is not as quick as would be liked, but it > again depends on the nature of the work. If your HTML needs > a lot of complex cross-linking, tables of contents, navigation > bars, etc, then doing this straight from the RDBMS can be > a real bitch. > Actually, the thing I really like about the XML solution - and I think others will agree, is that it's a whole lot easier to update your XML structure than it is to update your database. Changing code that accesses a database is a lot harder than changing code that format's XML. > Also, the speed of processing XML will depend on the tool. > Have you considered using something like Omnimark, instead > of DOM, etc? > We don't use DOM. We use expat (using perl's XML::Parser and my CGI::XMLForm module). Expat is very quick. E.g. we can raw-parse (doing nothing in the parse phase) 100 of our files in 0.25 seconds, but it's 30 seconds to do the same with XML::DOM (another perl module - although that module has large overheads because it's a pure-perl solution). Of course that's not a very fair benchmark, because it's a lot easier to manipulate DOM than it is using expat, but the performance/flexibility tradeoff is worth it. 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 paul at prescod.net Wed Feb 3 09:57:32 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:28 2004 Subject: Interesting Monday. References: <5F052F2A01FBD11184F00008C7A4A80001136AE8@eukbant101.ericsson.se> Message-ID: <36B81B22.865CE9D1@prescod.net> "Matthew Sergeant (EML)" wrote: > > The overall issue is > now a concern for XML e-commerce. You can't cache or store parse trees for > XML data that isn't static in any way, and that you only use once and then > throw away. Well, e-commerce is actually engaged in interchange so I grudgingly admit that XML is probably useful. ( :) ) Consider, however, that an optimized subset of XML with an optimized parser and optimized API would go faster. And if that fails, well, we can always go back to the last universal format: S-expressions! -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 10:04:05 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:28 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <000e01be4f36$c7b29370$d3228018@jabr.ne.mediaone.net> Message-ID: <36B819D3.B65C07F3@prescod.net> "Borden, Jonathan" wrote: > > You have missed the point here. If I put a DOM interface onto a SQL Server > or Oracle or ODI or Poet database, I am hardly using an API to the > serialization structure. When people say this, they mean that the DOM > API/interface is used against the native datastore. The utility of this > would demonstrate itself in a distributed environment where something like > XQL was used as a query language. If we are in the relational db world, > ODBC/SQL 92 provides an interface onto disparate databases. Not all > information is stored on relational dbs. The DOM interface aims to provide > the same database and vendor neutrality and interoperability that ODBC or > JDBC provides for tabular data. If I am using a DOM interface, it frankly > doesn't matter what the serialization format is, I am interacting directly > with data through an interace. You are interacting with data through an interface that was designed to provide access to the abstract data model of a *serialization*. In other words you are treating your database as if it were the result of parsing an XML document. You've put an "elements and attributes" interface on data that is much more complex than elements and attributes. If it were not more complex then elements and attributes we would not need stuff like XLink, HyTime, Namespaces and RDF to even *attempt* (and fail) to represent it. The XML data model, whether a grove or a DOM is the "Forrest Gump" of representations for your data. Sending a dumbed-down message by Forrest Gump is good: he will relate it faithfully. Installing him as the only conduit for information is bad. You'll have to dumb down too much information and spend too much energy re-assembling it on the other side. > I wouldn't suggest that the DOM replace ODBC, yet I'm quite sure that those > experienced using a variety of systems with disparate data types and data > usages will appreciate that certain types of data are best expressed in tree > format. Such data scenario's might best be interfaced with via the DOM. You just need an API for "tree formats". Just ask your DBMS vendor to provide some tree-structured API. It doesn't matter if that API is the DOM because making it the DOM does *not buy you anything* as a programmer. >From a programming point of view there is no benefit to working with a consistent API where everything is dumbed-down to a textual model. You might as well dumb everything down to an "object model." (see below) If you buy this, then guess what the hype will be in three years: "These new fangled data bases have this really cool feature, dude. You call it with a SQL9X query and it can return like OBJECTS!. Everything in the world can be expressed as objects! Lists of objects. Lists of objects. Trees of objects. Directed graphs of objects. Arbitary graphs of objects. It like unifies everything as objects. It's Zen, man. They call it 'JDBC' and its totally wicked." The *only benefit* of unifying things as DOMs is reusing software that was originally supposed to work with XML (i.e. XSL implementations). If you are writing new software it makes NO SENSE to do it through a DOM interface unless your data source is *XML*. Otherwise, you should just define a "tree node" interface and have your various objects implement it. You will get all of the the benefits of the DOM with none of the costs (i.e. how the hell do you represent complex properties of objects???). If you want some good hints about what a "tree node" interface looks like, take a look at the grove abstraction. > XSL transforms can be applied directly to DOM representations, rather than > serialized XML documents. This yeilds the possibility that serial transforms > be applied within 'DOM space' (assuming the XSL transform output is a DOM > structure rather than a serialized string). The act, thus, of web page > generation from a database can be automated via XSL rather than, say ASP or > perl scripts. Is this useful? Sometimes it is. First, I don't believe that publishing databases to the Web is considered a hard problem. Report writers, CGIs and application servers have been doing it for a long time. So if all you are claiming is that the DOM provides us with a small ease-of-use gain in solving an already solved problem, then I can buy that. But I hear much grander claims for these DOM interfaces. Nobody is saying: "solve simple problems slightly more elegantly." They are rather saying: "unify your enterprise." Second, Even *XSL* is not best served by a DOM representation. James Clark wrote an xsl-list article about that but I can't find it now. Remember that the DOM was invented as an extension of "DHTML." It's only half "there." But if I grant that some well-thought-through API for XSL trees could exist (i.e. Jade's grove API) then I would propose that it only be used as an optimization in a system where it would otherwise make sense to pass around serializations of text documents. i.e. the DOM is okay for skipping a layer of message passing. It is not okay as a "universal API" for "all of the data in an organization." To bastardize JWZ: "Sometimes people have a hard data unification problem. One part of their organization speaks a very different language (at the data model and object model level) than another part. They might think 'I can unify these with XML or the DOM.' Now they have two problems." There second problem is that they didn't understand the really hard problem in their organization. Data model unification is *easy* (cast to java.lang.object or w3c.dom.node). Data model *rationalization* is very difficult. And I don't think that there are many shortcuts. > Are the DOM interfaces the best for all situations, clearly not. However if > a significant percentage of people can agree to use them a significant > percentage of the time, this is a big win. That's not going to happen. The DOM will NOT be a core tool for that majority of OO programmers this year, next year, or ever. Programmers will try it and increasingly find that if they are not doing XSL styling for the Web or print that the DOM is not a core tool. "Old-fashioned" OO can provide the same benefits. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 10:08:29 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:28 2004 Subject: Another errata? Message-ID: <01BE4F64.A5B44010@grappa.ito.tu-darmstadt.de> Mark Birbeck wrote: > How not quite? A namespace is a set of unique entries *by definition*. > That's what they are - a set of unique entries. You can't have a 'set of > unique entries' that contains a duplicate. > > > An element can have the same name as a global > > attribute without problem. > > True. But they are not in the same namespace. According to A.2 the > element would be in the 'all element types' partition, and the global > attribute would be in the 'global attribute' partition. They *are* in the same "namespace", as the term is defined by the namespaces spec. The spec is, at times, quite forward about this -- for example, section A.1. At other times, you need to read very closely to determine whether the XML or traditional meaning of "namespace" is meant -- for example, in the paragraph describing per-element-type partitions, the first and second uses of the word "namespace" mean "traditional namespace"; the third usage means "XML namespace". That this is confusing is evident from the above discussion -- John means XML namespace and Mark means traditional namespace. > It is not the job of standards > developers to make sure we understand everything they write. ... Huh? It most certainly *is* the job of the standards developers to make sure we understand what they write. What is the point of a standard if nobody can understand it? Even more to the point, if what standards writers write is routinely interpreted to mean many different things by many different people, then I think the standards writers have failed their job. The SQL specs may make for abominable reading, but they are generally interpreted by everybody the same way. The XML spec is not the clearest piece of technical writing ever to come down the pipe, but after reading, and re-reading, and re-reading it, most people interpret most parts of it in the same way. In contrast, the namespaces spec *is* widely misinterpreted, and by people who, judging by their posts to this list, are intelligent and more than willing to read, re-read, and re-re-read specs. To me, that says there is something wrong, and I think a good example of this is the fact that the spec repeatedly leads the reader to believe that unprefixed attributes belong to the namespace of the element. I think a mistake made in writing many specifications is to rely on excessively formal language and write down only the rules, not the motivation. In my mind, the point of a specification is not to write rules, but to get everybody to agree to the same rules. (These are not quite the same thing -- think of the difference between the clue and the answer in a crossword puzzle. If you have a clue that immediately leads everybody to the same answer, then it is as useful as the answer, even though it is not the same.) Thus, anything that will get people to come to the same conclusion (stating the rules clearly, stating the motivation for those rules, giving examples, linking to video presentation of pet hamsters pantomiming the rules, etc.) is fair game. Finally, if you are driving a technology through standards (as opposed to the other way around, which is more common), then, whether you like it or not, those standards necessarily play a role in marketing that technology, and the more accessible those standards are, the more likely the technology will succeed. -- 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 jjc at jclark.com Wed Feb 3 10:52:42 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:08:28 2004 Subject: Fw: Namespaces References: <008e01be4f52$a23b2410$5402a8c0@oren.capella.co.il> Message-ID: <36B8229D.A5FFD27B@jclark.com> Oren Ben-Kiki wrote: > xmlns="http://www.w3.org" > > > > > > would have the equivalent (extended) Clark encoding > (http://www.jclark.com/xml/xmlns.htm) > > <{http://www.w3.org}x xmlns:n1="http://www.w3.org" > xmlns="http://www.w3.org" > > <{http://www.w3.org}good {{http://wwww.w3.org}good}a="1" > {{http://wwww.w3.org}good}b="2" /> > <{http://www.w3.org}good {{http://wwww.w3.org}good}a="1" > {http://www.w3.org}a="2" > > It would have the (non-extended) Clark encoding of: <{http://www.w3.org}x> <{http://www.w3.org}good a="1" b="2" /> <{http://www.w3.org}good a="1" {http://www.w3.org}a="2" /> Putting {{http://wwww.w3.org}good} in front of the unprefixed attribute names needlessly confuses things. When I write in XML what is the relationship between the attribute name "a" and the element type name "good"? It's hard to describe but they're clearly not unrelated: roughly speaking knowing what the attribute name "a" means depends on knowing what the element type name "good" means. But we don't need to fight this one out: whatever this relationship is, when I write <{http://www.w3.org}good a="1"/> this relationship is exactly the same relationship as holds between the attribute name "a" and the element type name "{http://www.w3.org}good". XML namespaces aren't changing anything here. That's why <{http://www.w3.org}good a="1"/> not <{http://www.w3.org}good {{http://www.w3.org}good}a="1"/> is the right way to describe what's going on. 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 oren at capella.co.il Wed Feb 3 11:04:03 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:08:28 2004 Subject: Fw: Fw: Namespaces Message-ID: <00b901be4f64$338cec30$5402a8c0@oren.capella.co.il> James Clark wrote: > > >what is the relationship between the attribute name "a" and the element >type name "good"? It's hard to describe but they're clearly not >unrelated: roughly speaking knowing what the attribute name "a" means >depends on knowing what the element type name "good" means. But we >don't need to fight this one out: whatever this relationship is, when I >write > ><{http://www.w3.org}good a="1"/> > >this relationship is exactly the same relationship as holds between the >attribute name "a" and the element type name "{http://www.w3.org}good". >XML namespaces aren't changing anything here. So far, so good. But the question is: is it the same relationship between "{http://www.w3.org}a" and "good" or "{http://www.w3.org}good" in: <{http://www.w3.org}good {http://www.w3.org}a="1"/> If it is the same relationship (I suspect it is), there's no such thing as global attributes, and a lot of bandwidth has been wasted debating them - or I misunderstood the debate :-) Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Wed Feb 3 11:09:45 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:28 2004 Subject: object databases Message-ID: <93CB64052F94D211BC5D0010A80013310EB2D1@WWMESS3> Paul Prescod: > You didn't really answer my question. If Oracle 8i provides the same > support for "graphs of data with links and annotations" that > ObjectDesign then in what sense is it NOT an object database. I'm still > asking for a definition. There are a number of definitions of an "object database", but a minimal definition requires it to be a container of "objects" - which include behaviour (interfaces and methods) as well as structure. Plus a type hierarchy, plus persistent identifiers... Rather more than just graph structures. The main area where the "pure object" db vendors differ from the "extended relational" vendors is in insisting that the concept of object database also implies persistent programming, i.e. access to persistent objects using the same syntax as transient variables. Also they typically have a completely different internal architecture which optimises the performance of navigation and retrieval of composite objects at the expense of ad-hoc query. 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 peter at homepla.net Wed Feb 3 11:17:09 1999 From: peter at homepla.net (Peter Finch) Date: Mon Jun 7 17:08:28 2004 Subject: Namespace clashes? Message-ID: <36B82FBD.AC009CDD@homepla.net> > I have been disturbed by the amount of confusion surrounding the XML > Namespaces Recommendation. So I have written a document This was really good but I have some questions that have been nagging me for ages (sorry if they are dumb questions). Imagine A, B, C, D and E and all users of some XML data. A and B exchange data and agree to use A's namespace and that "title" is a book title (among other things). Elsewhere, C and D also exchange data and agree to use D's namespace and that "title" is a book title. 1. E comes along and wants to create data and exchange data with A, B, C and D. What does E use? If E creates a new NS "title" then A, B, C and D have to update there procedures to cater for this? 2. Is there going to be (or is there) a registry for URI and tags so that this can be avoided? 3. Is there some way to "alias" names so that you can say that "an:t", "dn:t" and "en:t" are all the same (or is this up to the application)? 4. How do you validate a document that may contain tag's and attributes that are a mixture of different DTD's? It's easy when they have the same content model but what if "an:t" and "dn:t" are containers and have completely different content models? Cheers, xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jayadeva at lgsi.co.in Wed Feb 3 11:25:23 1999 From: jayadeva at lgsi.co.in (Jayadeva Babu Gali) Date: Mon Jun 7 17:08:28 2004 Subject: unsubscribe Message-ID: <36B83229.8AACC184@lgsi.co.in> unsubscribe jayadeva@lgsi.co.in xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jayadeva at lgsi.co.in Wed Feb 3 11:27:47 1999 From: jayadeva at lgsi.co.in (Jayadeva Babu Gali) Date: Mon Jun 7 17:08:29 2004 Subject: unsubscribe Message-ID: <36B8324A.ED2B039C@lgsi.co.in> unsubscribe jayadeva@lgsi.co.in xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 11:54:36 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:29 2004 Subject: Namespace clashes? Message-ID: <01BE4F73.6064BA80@grappa.ito.tu-darmstadt.de> > Imagine A, B, C, D and E and all users of some XML data. A and B exchange > data and agree to use A's namespace and that "title" is a > book title (among other things). > > Elsewhere, C and D also exchange data and agree to use D's namespace and > that "title" is a book title. > > 1. E comes along and wants to create data and exchange data with A, B, C > and D. What does E use? If E creates a new NS "title" then > A, B, C and D have to update there procedures to cater for this? E should use to exchange data with A and B and to exchange data with C and D. If E creates their own DTD, then everybody who wants to exchange data with E needs to update their software, which is unlikely to make E very popular. A much better solution is to get everybody (A-E) to agree on a single set of tags in the first place. > 2. Is there going to be (or is there) a registry for URI and tags so that > this can be avoided? There are some DTD (tag) registries already -- for example, see www.schema.net. > 3. Is there some way to "alias" names so that you can say that "an:t", > "dn:t" and "en:t" are all the same (or is this up to the application)? I believe that architectural forms allow you to do this, but I'm not sure. > 4. How do you validate a document that may contain tag's and attributes that > are a mixture of different DTD's? It's easy when they have the same content > model but what if "an:t" and "dn:t" are containers and have completely > different content models? With current parsers, you need to make sure that the same prefixes are used in both the DTD and the document. That "an:t" and "dn:t" have different content models is not a problem for validation -- they are different elements and have different names. Differentiating between two different elements with the same name (whether they represent the same real-world information or not) is exactly the problem that namespaces were designed to solve. Note that an application needs to treat "an:t" and "dn:t" differently, just as it would treat "an:t" and "an:xxx" differently. The fact that both represent a title is the application's problem and must be solved in the application. As mentioned above, a simple (but not always easy) way to do this is to get A-E to agree on a single DTD. In general, namespaces will more likely be used to differentiate between elements from two different DTDs that cover different subject areas but use the same names, such as when means book title in one DTD and job title in another DTD. This becomes a problem when somebody creates a new DTD that reuses both of these DTDs. -- 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 ht at cogsci.ed.ac.uk Wed Feb 3 11:58:50 1999 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:08:29 2004 Subject: Reminder: XML Research Dissemination Workshop 26 February in Edinburgh Message-ID: <1548.199902031156@mcilvanney.cogsci.ed.ac.uk> Research Dissemination Workshop: Markup Technologies for Computational Linguistics Hosted by the HCRC Language Technology Group University of Edinburgh 25, 26 February 1999 The Language Technology Group, with support from EPSRC, ESRC and other sources, has invested substantial effort over the last four years in building up an inventory of tools and technologies for the markup of language data. This in turn has led to the articulation of a markup-based architecture for NLP systems, which we have used for applications as diverse as discourse relation annotation, named entity recognition and tokenisation. The goal of this workshop is to introduce our work to a wider audience, with * A tutorial on XML, the W3C standard based on SGML which is at the heart of our work [No spaces left]; * Details of our use of markup technologies; * Comparison and contrast with similar technologies developed elsewhere. The keynote on Thursday evening will be given by Michael Sperberg-McQueen, and promises to be both entertaining and informative. See http://www.ltg.ed.ac.uk/nscope/ for details, including a pointer to the online registration form. -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From heretic at ihug.co.nz Wed Feb 3 12:43:18 1999 From: heretic at ihug.co.nz (David Mohring) Date: Mon Jun 7 17:08:29 2004 Subject: Compound Documents as directories stored in zip files Message-ID: <36B84467.DEB5215@ihug.co.nz> As Roger Costello defined compound documents in http://www.lists.ic.ac.uk/hypermail/xml-dev/9901/0754.html >compound-document ::= (compound-document | valid-document) >valid-document ::= <a document that conforms to a schema> >In words, a compound document is a "document of documents", where each >document conforms to a schema; i.e, a nested document conforms to a schema >as well as does its parent document. I will use the term composition and >compound document interchangeably. This limits the compound document to only being valid xml. In the real world most word processing compound documents also contain image files as well as other foreign data format. So what about giving compound document a wider definition? a "Compound Document" is a set of Documents and Objects that can refer and link to each other. The compound document can then contain any type of data format. valid xml files, DTDs , Schemes , image files etc. If you could 'unpack/unzip' a compound document you would produce a directory and files - just as in a normal file system and a root document that can define the view of the document as a Whole - index.xml or/and index.html. You can then relatively reference Xlink/Xpoint documents as easy as you would a directory of html files. So why not just store a compound document in zip achieve file format but with another affix just like java jar 'files'. It is easy to 'peer into' and 'grab' the content of a zip file, java classes and C libraries that can do this already exist. So why not just add this functionality to all XML applications, formatter, browsers 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 Mark.Birbeck at iedigital.net Wed Feb 3 13:01:43 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:29 2004 Subject: Another errata? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054943@SOHOS002> Ronald Bourret wrote: > Mark Birbeck wrote: > They *are* in the same "namespace", as the term is defined by the > namespaces spec. Where is the term defined? "XML namespace" is defined, and then from then on the word 'namespace' is used very loosely, but I so no 're-definition' of the term namespace away from its traditional meaning. I DO see an explanation of how the concept of an 'XML namespace' differs from a tradition 'namespace'. > That this is confusing is evident from the above discussion > -- John means > XML namespace and Mark means traditional namespace. I'm not confused thanks - I mean both. I am drawing a distinction. You need both to understand how the namespaces spec implements 'traditional namespaces' in a manner useful to XML. In short, one, traditional namespace would not be enough for XML because you lose structure. It therefore needs a lot of them, and this is achieved by having effectively a 'namespace container' full of other (real) namespaces. That namespace container is an 'XML namespace' - which for brevity, we call a 'namespace'. (Hey, I'm not disagreeing with you that it's tricky!!) > > It is not the job of standards > > developers to make sure we understand everything they write. ... > > <soapbox> > Huh? It most certainly *is* the job of the standards > developers to make > sure we understand what they write. I suppose we're onto matters of opinion now, but a standard must be unambiguous in its *formal* interpretation. I may read it and misunderstand, but when I get down to the nitty-gritty of implementation, provided that I eventually *do* understand it, I should be able to do this unambiguously. If you describe 'intent' then what if you do not cover a usage that later arises? You introduce ambiguity. > In contrast, the namespaces spec *is* widely misinterpreted, > and by people > who, judging by their posts to this list, are intelligent and > more than > willing to read, re-read, and re-re-read specs. To me, that > says there is > something wrong, and I think a good example of this is the > fact that the > spec repeatedly leads the reader to believe that unprefixed > attributes > belong to the namespace of the element. The spec does not! The reader's mistaken assumptions about what the namespaces spec is trying to achieve leads them to read this into it. But if we're really honest here, if we were in a discussion group on compiler technology ten years ago, you would not have such a wide range of people discussing these issues, and narrower range of misinterpretation (I'm not saying everyone understood everything then either). That's not to say we shouldn't have more people involved, but I disagree with this 'dumbing down' attitude that seems to exist, where we must ensure that everyone can understand. If you want to write a book making it clearer then do it - we'd all probably be grateful - but the spec itself MUST be a formal document. > I think a mistake made in writing many specifications is to rely on > excessively formal language and write down only the rules, not the > motivation. In my mind, the point of a specification is not to write > rules, but to get everybody to agree to the same rules. No! The job of the discussion *about* a spec is to find agreement. Once that has been arrived at you need to codify that in a way that is unambiguous. It needs to be as formal as possible! > Finally, if you are driving a technology through standards > (as opposed to > the other way around, which is more common), then, whether > you like it or > not, those standards necessarily play a role in marketing > that technology, > and the more accessible those standards are, the more likely > the technology > will succeed. I don't think that is the job of standards. Others can write books on it, produce training courses, and as you say, get hamsters involved in video production (although I believe that's illegal in some States) but the standard itself must be as terse and precise as possible. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 jjc at jclark.com Wed Feb 3 13:28:05 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:08:29 2004 Subject: Namespaces References: <00b901be4f64$338cec30$5402a8c0@oren.capella.co.il> Message-ID: <36B84B7C.30BE274A@jclark.com> Oren Ben-Kiki wrote: > > James Clark <jjc@jclark.com> wrote: > > <good a="1"/> > > > >what is the relationship between the attribute name "a" and the element > >type name "good"? It's hard to describe but they're clearly not > >unrelated: roughly speaking knowing what the attribute name "a" means > >depends on knowing what the element type name "good" means. But we > >don't need to fight this one out: whatever this relationship is, when I > >write > > > ><{http://www.w3.org}good a="1"/> > > > >this relationship is exactly the same relationship as holds between the > >attribute name "a" and the element type name "{http://www.w3.org}good". > >XML namespaces aren't changing anything here. > > So far, so good. But the question is: is it the same relationship between > "{http://www.w3.org}a" > and "good" or "{http://www.w3.org}good" in: > > <good {http://www.w3.org}a="1"/> > <{http://www.w3.org}good {http://www.w3.org}a="1"/> I would prefer not to answer this since I don't think the XML Namespaces Recommendation needs to take a position on this. All the Namespaces Recommendation does is provide a mechanism which allows element type names and attribute names to be qualified with a URI. How other applications or specifications (such as RDF or XML Schemas) choose to exploit this mechanism is up to them. However, if I was forced to answer, I would say that the relationship was not the same. An element <{http://www.w3.org}good a="1"/> doesn't have a well-defined meaning unless the specification of the {http://www.w3.org}good element type says what the "a" attribute means on elements of that type. However an element <{http://www.w3.org}good {http://www.jclark.com}a="1"/> might have a well-defined meaning even if the specification of the {http://www.w3.org}good element type doesn't mention {http://www.jclark.com}a attribute and vice-versa, in just the same way that <{http://www.w3.org/}good> <{http://www.jclark.com/}a>1</{http://www.jclark.com}a> </{http://www.w3.org/}good> might have a well-defined meaning even if the specification of the {http://www.w3.org}good element type doesn't mention {http://www.jclark.com}a element type and vice-versa. 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 Mark.Birbeck at iedigital.net Wed Feb 3 13:29:40 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:29 2004 Subject: Fw: Namespaces Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054944@SOHOS002> Oren Ben-Kiki wrote: > So far, so good. But the question is: is it the same > relationship between > "{http://www.w3.org}a" > and "good" or "{http://www.w3.org}good" in: > > <good {http://www.w3.org}a="1"/> > <{http://www.w3.org}good {http://www.w3.org}a="1"/> > > If it is the same relationship (I suspect it is) there's no > such thing as global attributes It is the same, but that's because it IS a global attribute, with an explicit namespace: <good n1:a="1" /> <n1:good n1:a="1" /> Forgive me if I am being presumptuous, but I think what you meant to ask was is *this* relationship the same: <n1:good a="1" /> <n1:good n1:a="1" /> i.e., given that 'good' is in the 'n1' namespace, is the relationship between 'a' and 'good' the same in both cases, and I think you have to say it isn't. All you can say about 'a' DIRECTLY is that it is related to 'good' and that if you want to you could retrieve the namespace for 'good'. Using the expanded syntax from A.3 in the spec (sorry James, yours is nice too), we get: <ExpAName name='a' eltype="good" elns="http://www.w3.org" /> However, we can say more about 'n1:a': <ExpAName name='a' ns="http://www.w3.org" /> Note the latter is a global attribute, because even if we add: <n1:better a="1" /> <n1:better n1:a="1" /> Our complete expanded list becomes: <ExpEType name='good' ns="http://www.w3.org" /> <ExpEType name='better' ns="http://www.w3.org" /> <ExpAName name='a' eltype="good" elns="http://www.w3.org" /> <ExpAName name='a' eltype="better" elns="http://www.w3.org" /> <ExpAName name='a' ns="http://www.w3.org" /> That is, only ONE 'n1:a' entry, even though it's used in both 'good' and 'better'. In other words, it IS a global attribute. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 simonstl at simonstl.com Wed Feb 3 14:48:03 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:29 2004 Subject: Forking the DOM (was Re: Storing Lots of Fiddly Bits) In-Reply-To: <36B819D3.B65C07F3@prescod.net> References: <000e01be4f36$c7b29370$d3228018@jabr.ne.mediaone.net> Message-ID: <199902031447.JAA20034@hesketh.net> Given the fairly strong comments excerpted below (and Paul's not the only one muttering like this), is it time to contemplate a very different API? The DOM's strong suit is that it provides a standard interface; however, that standard seems to keep running into a mismatch problem in lots of situations. Is a generalized object model simply not the answer? Do we need fifteen semi-standard models for use in different situations? Could the current DOM be subsetted/extended to provide such functionality, or do we need to take a few steps back and start over, leaving the DOM for those who need its type of functionality but defining a new set of rules for those with different needs? At 03:41 AM 2/3/99 -0600, Paul Prescod wrote: >You just need an API for "tree formats". Just ask your DBMS vendor to >provide some tree-structured API. It doesn't matter if that API is the DOM >because making it the DOM does *not buy you anything* as a programmer. >>From a programming point of view there is no benefit to working with a >consistent API where everything is dumbed-down to a textual model. You >might as well dumb everything down to an "object model." (see below) > >[...] > >The *only benefit* of unifying things as DOMs is reusing software that was >originally supposed to work with XML (i.e. XSL implementations). If you >are writing new software it makes NO SENSE to do it through a DOM >interface unless your data source is *XML*. > >Otherwise, you should just define a "tree node" interface and have your >various objects implement it. You will get all of the the benefits of the >DOM with none of the costs (i.e. how the hell do you represent complex >properties of objects???). If you want some good hints about what a "tree >node" interface looks like, take a look at the grove abstraction. > >[...] > >Second, Even *XSL* is not best served by a DOM representation. James Clark >wrote an xsl-list article about that but I can't find it now. Remember >that the DOM was invented as an extension of "DHTML." It's only half >"there." > >But if I grant that some well-thought-through API for XSL trees could >exist (i.e. Jade's grove API) then I would propose that it only be used as >an optimization in a system where it would otherwise make sense to pass >around serializations of text documents. i.e. the DOM is okay for skipping >a layer of message passing. It is not okay as a "universal API" for "all >of the data in an organization." > >[...] > >That's not going to happen. The DOM will NOT be a core tool for that >majority of OO programmers this year, next year, or ever. Programmers will >try it and increasingly find that if they are not doing XSL styling for >the Web or print that the DOM is not a core tool. "Old-fashioned" OO can >provide the same benefits. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 DuCharmR at moodys.com Wed Feb 3 15:10:11 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:08:29 2004 Subject: XML and databases (NYC talk 2/8) Message-ID: <49092BAEAC84D2119B0600805FD40F9F120C8F@MDYNYCMSX1> The Object Developers Group (www.objdev.org) is sponsoring a talk on XML and databases in New York City on February 8th. I've copied their announcement below. (It was forwarded to my by a co-worker; I know nothing about the ODG or Walter Perry.) Bob DuCharme www.snee.com/bob <bob@ snee.com> see www.snee.com/bob/xmlann for "XML: The Annotated Specification" from Prentice Hall. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Title: "XML and Databases" Speaker: Walter Perry Date: Monday, February 8, 1999 Time: 7-9pm Location: Prudential Securities, One New York Plaza, NY NY 10292 Sign in with security, take elevator to the 3rd floor, then the escalator down to 2nd floor. Follow posted signs. See http://www.objdev.org/directions/prudential.html Cost: $5 contribution http://www.objdev.org/contrib Free to Prudential Security employees (our hosts) and ODG paid annual members Register: Required, please use http://www.objdev.org/register Leader: Walter Perry, wperry@fiduciary.org Groups: XML SIG of the Object Developers Group(ODG) Abstract: "XML and Databases" XML, touted as a 'universal syntax' of information, has seemed from its beginnings to be an obvious tool for inter-database communication, for database publishing to the Web, for the mapping of complex data to relational tables -- in short, for expressing efficient translations between data and documents. The question is how large a role XML can, or should, play in the overall scheme of data management. Some think that the data repository itself should be XML documents, while others at the opposite extreme regard XML as simply a transient messaging format. Is an XML document logically reducible to normalized relational tables, or does it force us to use much less well understood object databases? What are the advantages, and the shortcomings, of XML for such routine database tasks as queries, sorts, bulk updates and reporting? This session will examine these questions and try to find several ways in which XML can provide database tools which are immediately useful. Bio: Walter Perry is Managing Director of Fiduciary Automation, which provides services and software to support complex transnational financial settlements and to produce from them multi-jurisdictional reporting satisfying management, auditing, compliance and tax and other regulatory requirements. He has wrestled with most hardware since the 360/45 and the PDP-8 and with an even wider variety of operating systems and languages. He is now happily object-oriented. Walter holds a B.A. from Columbia University and a PhD. from Trinity College, University of Dublin. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 15:13:28 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:29 2004 Subject: Forking the DOM (was Re: Storing Lots of Fiddly Bits) Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AEB@eukbant101.ericsson.se> > -----Original Message----- > From: Simon St.Laurent [SMTP:simonstl@simonstl.com] > > Given the fairly strong comments excerpted below (and Paul's not the only > one muttering like this), is it time to contemplate a very different API? > The DOM's strong suit is that it provides a standard interface; however, > that standard seems to keep running into a mismatch problem in lots of > situations. > > Is a generalized object model simply not the answer? Do we need fifteen > semi-standard models for use in different situations? Could the current > DOM be subsetted/extended to provide such functionality, or do we need to > take a few steps back and start over, leaving the DOM for those who need > its type of functionality but defining a new set of rules for those with > different needs? > Don't we already _have_ different models depending on what suits the situation best? I am coming from the perl world, not the Java world that most people here are in, but there we have DOM, Groves, Objects, Trees, etc. If DOM doesn't fit (which for a lot of tasks it doesn't) then there are other options out there. I don't think trying to define another language independant representation of XML is the answer here - otherwise we'll end up with X standards for X different problems. I think you're right, but I'd rephrase slightly: "A generalized object model isn't *always* the answer". Use what works, and if there's nothing that works create something that does - and be nice - let everyone else have it. 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 Mark.Birbeck at iedigital.net Wed Feb 3 18:30:46 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:29 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054949@SOHOS002> Paul Prescod wrote: > > Sure. But I still have two issues. First, why would you query the > > serialisation anyway? Wouldn't you want to query your > original database > > and generate XML pages that reflect the results? > > You certainly would if you use XML as *only* a serialization. > The thrust > of this thread was that some people want to encode everything > in XML so > that they can "query it." But XML is a lousy query representation for > anything other than human-authored documents. (and debatably the best > thing for queries against those!) That is my suggestion. The DOM is no way fast enough - or efficient enough - to be a query interface to loads of data. It is a handy way of navigating trees though, but you would probably want to break your processing of the data into a number of trees. For example, say I query *my database* for all articles in any issue of a magazine that contain the word 'Turkey'. The database server would now have these cached, but to begin with I might get away with just putting references to each issue into the DOM. If a user selects one of those issues from their search results, I could then add to the DOM all the articles for that issue that contain the word. I could even create a new DOM instance and populate it, so that if the user moves away from that issue I could delete the DOM and create a new one. (I could even not use the DOM at all - hey, there's no law.) Anyway, I think we're sort of agreeing, that the DOM on its own is not suitable, but some helper stuff with the DOM is. > > And modelling the data rather than the person > > means you can no longer interchange your XML with other > systems because > > you have two completely different sets of data, using > different DTDs. > > I don't follow that. I simply mean that an XML document that contains data about people has a different DTD to a document that has data about data. A server expecting a 'person' document that meets with some DTD requirements is not going to accept a document that matches the DTD for 'global data interchange'. > > (And you can't say that your serialisation schema *will* allow this > > interchange, because although your serialised data may be > well-formed, > > the underlying data it represents may not be, so you need > the proper DTD > > for the object.) > > Well-formedness has very little to do with DTDs so I don't follow this > either. I mean that you could have an XML document that fails against its DTD - say be using an attribute in the wrong place. Now, if you devise something that serialises your data so that you have entries that help define your elements and attributes, that serialised data will *pass* against *its* DTD - because its DTD is different (its the one for data serialisation). Now when you pass this serialised data to another server, it should be matched against its original DTD, otherwise you won't know that its badly formed, but with a 'universal serialiser' you could actually import it into a new database, despite its failings. > > All I am saying is that the document *itself* could be the > abstraction > > of the data. > > This is something else I don't follow. XML documents are > always encodings > of abstractions. They are concrete, tangible, interchangable, > printable > and can be given global names. Concrete, not abstract. I suppose all I'm getting at is that XML is already data', so why do we need to go to data'' in order to serialise? Why not just serialise from the database to XML? This is not the same problem as transferring schemas around. > The objects they represent are logical, usually inaccessible > outside of an > "address space" (i.e. your brain, your relational database) > and are thus > termed abstract. The reason we need XSL is because the > abstractions cannot > "stand alone". I can't transmit a book from my head to your > head. I need > to serialize it on paper or online. I also can't transmit a > "book object" > without serializing it somehow (i.e. XML). Before > serialization it is an > abstraction. Perhaps we are using the terms differently. If I have a picture of a house and I show it to you and say, point to the window, you would do so. But what you are pointing to is an 'abstraction' of the house - a picture - and there is no window there! ("ceci n'est pas une pipe", and all that.) Now, my point is that transmitting an XML mapping of some database entries is like actually transmitting that picture itself - of course it is not the house, but it *is* a representation of it. But it seems to me that to serialise everything to a universal form, always using the same DTD, is to end up transmitting a representation of the *picture*, not the house. And then you have lost a lot of information. And worse, you can now only send you data to systems that process abstractions of pictures, not ones that process abstractions of houses. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 skshirsa at nortelnetworks.com Wed Feb 3 18:31:33 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:08:29 2004 Subject: What is the purpose of ANY keyword ? Message-ID: <3.0.32.19990203115642.00740234@bl-mail2.corpeast.baynetworks.com> Hi, What's the purpose of ANY keyword in a otherwise strictly formed syntax of XML ? Also is this right if I say that : "If a top level element of a DTD has a content specifier - ANY, all the documents will be well-formed and VALID, as far as they contain the elements from that DTD in any order." Thanks & Regards, Shekhar Kshirsagar Nortel Networks. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 18:31:46 1999 From: clovett at microsoft.com (Chris Lovett) Date: Mon Jun 7 17:08:29 2004 Subject: how to browse xml files with xsl style sheet LOCALLY ? Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0874477A@RED-MSG-56> 80070005 is "Access Denied" - probably trying to load the DTD. Make sure you really did copy down the DTD and that all the URL's are relative local file access. ie5b2 xml does have a rather over-paranoid security model which will be fixed in the next release. If you still can't get it to work you can tweak the following security settings: - "Initialize and script ActiveX controls not marked as safe" - "Access data sources across domains" -----Original Message----- From: Mathieu Mangeot Lerebours [mailto:Mathieu.Mangeot@xrce.xerox.com] Sent: Tuesday, February 02, 1999 8:43 AM To: xml-dev@ic.ac.uk Cc: mangeot@xrce.xerox.com Subject: how to browse xml files with xsl style sheet LOCALLY ? Hello, I'm trying to write a xsl for my xml documents. As I'm not an expert in xsl, I wanted to start from an example. I'm working with ie5b2. I found an example at this address : http://www.silab.dsi.unimi.it/~sz475745/etl/rivista/Sommario.xml I can browse it perfectly. Then I decided to copy this file on my local disk. I also copyed the dtd and the xsl files on my local disk. But when I browse the local copy, msxml generates an error : =================================================== The XML page cannot be displayed Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later. ---------------------------------------------------------------------------- ---- MSXML error detected: 80070005 Line 4, Position 1 <root> ^ ================================================= I tried with another example from www.microsoft.com and encountered the same problem. Next, there was the same example but with css. This time, I could browse my local copy without any problem. So : What can I do to browse xml files with xsl locally ? thank you for your answers Mathieu -- Mathieu MANGEOT-LEREBOURS | Phone : +33 4 76 61 51 32 Xerox Research Centre Europe | Fax : +33 4 76 61 50 99 6 chemin de Maupertuis | E-mail: Mathieu.Mangeot@imag.fr F-38240 Meylan FRANCE | http://www.xrce.xerox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe 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 Feb 3 18:33:35 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:30 2004 Subject: Fw: Namespaces Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054947@SOHOS002> Clark - hope you don't mind but I'm copying this to the group because it may be of interest. Clark Evans wrote: > Mark Birbeck wrote: > > Using the expanded syntax from A.3 in the spec (sorry James, > > yours is nice too), we get: > > Could you translate into the syntax James put forth, I think > it much more clearly illustrates what's going on and > thus better facilitates conversation. Having to mentally translate > what you wrote caused me to get a headache. *evil grin* > > :) Clark > Sorry about your head Clark, but you can't translate because they express two different things. James's syntax allows us to see what's going on in an XML document by spelling out the namespaces to which elements and attributes belong. So (from my email): <xml xmlns:n1="http://www.w3c.org" /> <n1:good a="1" /> <n1:good n1:a="1" /> <n1:better a="1" /> <n1:better n1:a="1" /> becomes: <{http://www.w3c.org}good a="1" /> <{http://www.w3c.org}good {http://www.w3c.org}a="1" /> <{http://www.w3c.org}better a="1" /> <{http://www.w3c.org}better {http://www.w3c.org}a="1" /> in James's syntax. However, I was expressing what position those elements and attributes occupy in the XML namespace (again, from my previous email): > Our complete expanded list becomes: > > <ExpEType name='good' ns="http://www.w3.org" /> > <ExpEType name='better' ns="http://www.w3.org" /> > <ExpAName name='a' eltype="good" elns="http://www.w3.org" /> > <ExpAName name='a' eltype="better" elns="http://www.w3.org" /> > <ExpAName name='a' ns="http://www.w3.org" /> Note that 'a' on 'good' has a unique entry, as does 'a' on 'better', but in James's syntax we have 'a="1"' for both - i.e. no differentiation. James's syntax is therefore a useful 'exploded XML' but has to be used 'in context' - because it is still expressing the original XML document. But it does not tell us everything about the namespace (within the XML namespace) that an element or attribute occupies. The expanded attribute/element syntax loses information about the original XML document, but *does* map the namespace structure. As a shorthand in a previous email I used '^' between the various parts that tell you where in the XML namespace structure an element or attribute appears. So I could have expressed the above using: AETP^http://www.w3.org^good AETP^http://www.w3.org^better PETP^http://www.w3.org^good^a PETP^http://www.w3.org^better^a GAP^http://www.w3.org^a where: AETP is the 'all element types' partition PETP is the 'per-element-type' partition GAP is the 'global attribute' partition Note that we have four namespaces (i.e. sets) within the greater XML namespace. These are: AETP PETP^http://www.w3.org^good PETP^http://www.w3.org^better GAP Not sure if that helps your headache, but it *is* a more accurate representation of what is happening! Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 eric at hellman.net Wed Feb 3 18:36:12 1999 From: eric at hellman.net (Eric Hellman) Date: Mon Jun 7 17:08:30 2004 Subject: Control Characters Message-ID: <v04020a04b2de1fe26493@[192.168.1.1]> Why are the control characters x80-x9F allowed in XML character data, while x0-x8,xB,xC,xE-x1F are illegal? Is it that the illegals have meanings that XML does not support? Just wondering. Has "BEL" been banished to a "Unisound" encoding ?;--} I have a DTD in which some entities are given the default value xFFFD in the external subset because they are placeholders for strings to be supplied in an internal subset with the document. Is this an appropriate use of Unicode's "replacement character"? Eric Eric Hellman Openly Informatics, Inc. http://www.openly.com/ Tools for 21st Century Scholarly Publishing xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From skshirsa at nortelnetworks.com Wed Feb 3 18:49:25 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:08:30 2004 Subject: Can attribute value be of type ELEMENT ? Message-ID: <3.0.32.19990203133733.0075e040@bl-mail2.corpeast.baynetworks.com> Hi, In some tables, the unique identifier key be formed using more than one column values in a particular sequence . If I want to map it to attribute of type ID, what is the best way to do it ? One way to do that might be Attribute Value will be defined as a ELEMENT. But is it valid to do so ? Thanks & Regards, Shekhar Kshirsagar Nortel Networks xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Wed Feb 3 19:06:18 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:30 2004 Subject: Another errata? References: <A26F84C9D8EDD111A102006097C4CD0D054943@SOHOS002> Message-ID: <36B89820.18073A33@infinet.com> Mark Birbeck wrote: > Ronald Bourret wrote: > > That this is confusing is evident from the above discussion > > -- John means > > XML namespace and Mark means traditional namespace. > > I'm not confused thanks - I mean both. I am drawing a distinction. You > need both to understand how the namespaces spec implements 'traditional > namespaces' in a manner useful to XML. In short, one, traditional > namespace would not be enough for XML because you lose structure. It > therefore needs a lot of them, and this is achieved by having > effectively a 'namespace container' full of other (real) namespaces. > That namespace container is an 'XML namespace' - which for brevity, we > call a 'namespace'. (Hey, I'm not disagreeing with you that it's > tricky!!) Not only tricky, but unnecessarily tricky. XML should be a tool for real-world business solutions, not something that is more or less a puzzle some CS professor designs for his students. Namespaces is a pain to deal with no matter how you look at it. Once you read a document into memory and no longer preserve the original prefixes (or rather the QName), when you write the document back out (which has possibly been mutated) where do you get these prefixes? Do you simply invent them in the form a, b, c, ..., aa, ab, ac, ... etc. I suppose the people in the "Namespaces in XML" feel that once you read in a document, you throw it away. Under the old PI-Proposal it would be trivial for an XML API to allow the user to assign a prefix to a namespace before writing out an XML Document. Now it is far more difficult and practically impossible to deal with at the application level in a manageable way for the end-user. I suppose only parsing matters anymore with respect to XML and writing out XML documents no longer matters. This is sad as it effectively makes XML useless for my needs in an application I have. > > > It is not the job of standards > > > developers to make sure we understand everything they write. ... > > > > <soapbox> > > Huh? It most certainly *is* the job of the standards > > developers to make > > sure we understand what they write. > > I suppose we're onto matters of opinion now, but a standard must be > unambiguous in its *formal* interpretation. I may read it and > misunderstand, but when I get down to the nitty-gritty of > implementation, provided that I eventually *do* understand it, I should > be able to do this unambiguously. > > If you describe 'intent' then what if you do not cover a usage that > later arises? You introduce ambiguity. If people cannot understand what you write because the ideas are too complex for the average developer, then there is no real point in having a standard in the first place because all that ISV's will be doing is commoditizing their products for a niche market and overall this will reduce innovation in the marketplace. In the end everyone loses here. However, for broadly adopted technologies, standards are very important for application to application interoperability which is something end-users clamor for. But if things are too hard to understand because either the concepts have not been simplified or else the designers of those concepts don't care about clarity, then this does no one any good. > > In contrast, the namespaces spec *is* widely misinterpreted, > > and by people > > who, judging by their posts to this list, are intelligent and > > more than > > willing to read, re-read, and re-re-read specs. To me, that > > says there is > > something wrong, and I think a good example of this is the > > fact that the > > spec repeatedly leads the reader to believe that unprefixed > > attributes > > belong to the namespace of the element. > > The spec does not! The reader's mistaken assumptions about what the > namespaces spec is trying to achieve leads them to read this into it. > But if we're really honest here, if we were in a discussion group on > compiler technology ten years ago, you would not have such a wide range > of people discussing these issues, and narrower range of > misinterpretation (I'm not saying everyone understood everything then > either). That's not to say we shouldn't have more people involved, but I That is because compiler technology is a totally different field (and much more complex field) than XML will ever be. If XML is to be used by only developers and end-users who understand compiler technology then it will fail miserably no matter how much hype is in the presses these days. > disagree with this 'dumbing down' attitude that seems to exist, where we > must ensure that everyone can understand. If you want to write a book > making it clearer then do it - we'd all probably be grateful - but the > spec itself MUST be a formal document. I don't know what your definition of genius is, but mine is simple "the ability to simplify the complex". Quite plainly, if you can make reduce the learning curve for our feeble human minds to understand, it will take less time for people to learn those concepts and they can then take the time they have saved and work on new and interesting tasks. If every generation has to spend most of their adult life just learning everything that the previous generation created (but did not simplify) we will never have progress because human beings will be very old and very grey before they ever get the opportunity to even think original thoughts. > > I think a mistake made in writing many specifications is to rely on > > excessively formal language and write down only the rules, not the > > motivation. In my mind, the point of a specification is not to write > > rules, but to get everybody to agree to the same rules. > > No! The job of the discussion *about* a spec is to find agreement. Once > that has been arrived at you need to codify that in a way that is > unambiguous. It needs to be as formal as possible! If everyone told you to jump off a cliff would you do it? Compromise on technical matters is one of the worst things you can do. I personally feel you should let everyone come up with their own implementations and let public opinion and the marketplace decide who is the best. Compromise usually (but not always) creates groupthink and an atmosphere that very sub-optimal decisions are OK "as long as we can all just get along". > > Finally, if you are driving a technology through standards > > (as opposed to > > the other way around, which is more common), then, whether > > you like it or > > not, those standards necessarily play a role in marketing > > that technology, > > and the more accessible those standards are, the more likely > > the technology > > will succeed. > > I don't think that is the job of standards. Others can write books on > it, produce training courses, and as you say, get hamsters involved in > video production (although I believe that's illegal in some States) but > the standard itself must be as terse and precise as possible. You think people read all of these books and take these training courses because they want to? They take them usually because the technologies they use today are dictated to them. Java's success is an example of people writing code in Java because the "wanted to" because Java took out 85% of the pain in C++. Nevertheless, I have plenty of friends who still write C++ code on new projects using MS Visual C++ because "old grannies" at their institutions think everyone should be doing things they way they did them 10-15 years ago. They can't see the benefits of Java being a simpler version of C++, because they have not made an effort to do so. If you write some spec without regard to simplicity you are falling into a similiar model. "Namespaces in XML" is a pure example of simplicity falling to the wayside in favor of the attitude "well if I can understand it and no one else can, then the whole world is stupid". I think this will change in the next 10 years as people will become fed-up with any company or standards body that does not make a genuine effort at creating simple solutions from the get-go, especially since the trend in business these days is to be leaner and meaner. Microsoft has been eating up the small to medium sized business market with NT because they produce simpler solutions to SUN and IBM even though their OS's may crash all of the time. Even though their customer base is for the most part may be unhappy with their products, finding MS Solution Providers is a lot easier (and cheaper) than finding UNIX engineers. Recently companies like SUN and IBM may be getting the drift, but it may be too little too late. But then again, MS is seemingly doomed to fail big with NT 5.0 (managing 40 million LOC in one build is just plain mind-boggling) so who knows. I just know that my faith in the W3C would be seriously rekindled if "Namespaces in XML" were ripped off the W3C website right now and they started over with a more open-process to create a more well-thought out solution. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From skshirsa at nortelnetworks.com Wed Feb 3 19:17:22 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:08:30 2004 Subject: What is the purpose of ANY keyword ? Message-ID: <3.0.32.19990203141241.0073abb4@bl-mail2.corpeast.baynetworks.com> Hi, What's the purpose of ANY keyword in an otherwise strictly formed syntax of XML ? Also is this right if I say that : "If a top level element of a DTD has a content specifier - ANY, all the documents will be well-formed and VALID, as far as they contain the elements from that DTD in any order." Thanks & Regards, Shekhar Kshirsagar Nortel Networks. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 19:38:24 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:30 2004 Subject: Control Characters References: <v04020a04b2de1fe26493@[192.168.1.1]> Message-ID: <36B8A589.ECEF3D62@locke.ccil.org> Eric Hellman scripsit: > Why are the control characters x80-x9F allowed in XML character data, while > x0-x8,xB,xC,xE-x1F are illegal? No good reason. I think there was a desire to keep the SGML declaration short. > Has "BEL" been banished to a "Unisound" encoding ?;--} I think it would be most useful to replace it with an empty element <BEL/>. > I have a DTD in which some entities are given the default value xFFFD in > the external subset because they are placeholders for strings to be > supplied in an internal subset with the document. Is this an appropriate > use of Unicode's "replacement character"? It's unusual but not erroneous. -- 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 skshirsa at nortelnetworks.com Wed Feb 3 19:46:37 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:08:30 2004 Subject: What is the purpose of ANY keyword ? Message-ID: <3.0.32.19990203115642.00740234@bl-mail2.corpeast.baynetworks.com> Hi, What's the purpose of ANY keyword in a otherwise strictly formed syntax of XML ? Also is this right if I say that : "If a top level element of a DTD has a content specifier - ANY, all the documents will be well-formed and VALID, as far as they contain the elements from that DTD in any order." Thanks & Regards, Shekhar Kshirsagar Nortel Networks. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 19:49:33 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:30 2004 Subject: Fw: Namespaces Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054947@SOHOS002> Clark - hope you don't mind but I'm copying this to the group because it may be of interest. Clark Evans wrote: > Mark Birbeck wrote: > > Using the expanded syntax from A.3 in the spec (sorry James, > > yours is nice too), we get: > > Could you translate into the syntax James put forth, I think > it much more clearly illustrates what's going on and > thus better facilitates conversation. Having to mentally translate > what you wrote caused me to get a headache. *evil grin* > > :) Clark > Sorry about your head Clark, but you can't translate because they express two different things. James's syntax allows us to see what's going on in an XML document by spelling out the namespaces to which elements and attributes belong. So (from my email): <xml xmlns:n1="http://www.w3c.org" /> <n1:good a="1" /> <n1:good n1:a="1" /> <n1:better a="1" /> <n1:better n1:a="1" /> becomes: <{http://www.w3c.org}good a="1" /> <{http://www.w3c.org}good {http://www.w3c.org}a="1" /> <{http://www.w3c.org}better a="1" /> <{http://www.w3c.org}better {http://www.w3c.org}a="1" /> in James's syntax. However, I was expressing what position those elements and attributes occupy in the XML namespace (again, from my previous email): > Our complete expanded list becomes: > > <ExpEType name='good' ns="http://www.w3.org" /> > <ExpEType name='better' ns="http://www.w3.org" /> > <ExpAName name='a' eltype="good" elns="http://www.w3.org" /> > <ExpAName name='a' eltype="better" elns="http://www.w3.org" /> > <ExpAName name='a' ns="http://www.w3.org" /> Note that 'a' on 'good' has a unique entry, as does 'a' on 'better', but in James's syntax we have 'a="1"' for both - i.e. no differentiation. James's syntax is therefore a useful 'exploded XML' but has to be used 'in context' - because it is still expressing the original XML document. But it does not tell us everything about the namespace (within the XML namespace) that an element or attribute occupies. The expanded attribute/element syntax loses information about the original XML document, but *does* map the namespace structure. As a shorthand in a previous email I used '^' between the various parts that tell you where in the XML namespace structure an element or attribute appears. So I could have expressed the above using: AETP^http://www.w3.org^good AETP^http://www.w3.org^better PETP^http://www.w3.org^good^a PETP^http://www.w3.org^better^a GAP^http://www.w3.org^a where: AETP is the 'all element types' partition PETP is the 'per-element-type' partition GAP is the 'global attribute' partition Note that we have four namespaces (i.e. sets) within the greater XML namespace. These are: AETP PETP^http://www.w3.org^good PETP^http://www.w3.org^better GAP Not sure if that helps your headache, but it *is* a more accurate representation of what is happening! Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 clovett at microsoft.com Wed Feb 3 19:52:07 1999 From: clovett at microsoft.com (Chris Lovett) Date: Mon Jun 7 17:08:30 2004 Subject: how to browse xml files with xsl style sheet LOCALLY ? Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C0874477A@RED-MSG-56> 80070005 is "Access Denied" - probably trying to load the DTD. Make sure you really did copy down the DTD and that all the URL's are relative local file access. ie5b2 xml does have a rather over-paranoid security model which will be fixed in the next release. If you still can't get it to work you can tweak the following security settings: - "Initialize and script ActiveX controls not marked as safe" - "Access data sources across domains" -----Original Message----- From: Mathieu Mangeot Lerebours [mailto:Mathieu.Mangeot@xrce.xerox.com] Sent: Tuesday, February 02, 1999 8:43 AM To: xml-dev@ic.ac.uk Cc: mangeot@xrce.xerox.com Subject: how to browse xml files with xsl style sheet LOCALLY ? Hello, I'm trying to write a xsl for my xml documents. As I'm not an expert in xsl, I wanted to start from an example. I'm working with ie5b2. I found an example at this address : http://www.silab.dsi.unimi.it/~sz475745/etl/rivista/Sommario.xml I can browse it perfectly. Then I decided to copy this file on my local disk. I also copyed the dtd and the xsl files on my local disk. But when I browse the local copy, msxml generates an error : =================================================== The XML page cannot be displayed Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later. ---------------------------------------------------------------------------- ---- MSXML error detected: 80070005 Line 4, Position 1 <root> ^ ================================================= I tried with another example from www.microsoft.com and encountered the same problem. Next, there was the same example but with css. This time, I could browse my local copy without any problem. So : What can I do to browse xml files with xsl locally ? thank you for your answers Mathieu -- Mathieu MANGEOT-LEREBOURS | Phone : +33 4 76 61 51 32 Xerox Research Centre Europe | Fax : +33 4 76 61 50 99 6 chemin de Maupertuis | E-mail: Mathieu.Mangeot@imag.fr F-38240 Meylan FRANCE | http://www.xrce.xerox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe 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 eric at hellman.net Wed Feb 3 19:58:03 1999 From: eric at hellman.net (Eric Hellman) Date: Mon Jun 7 17:08:30 2004 Subject: Control Characters Message-ID: <v04020a04b2de1fe26493@[192.168.1.1]> Why are the control characters x80-x9F allowed in XML character data, while x0-x8,xB,xC,xE-x1F are illegal? Is it that the illegals have meanings that XML does not support? Just wondering. Has "BEL" been banished to a "Unisound" encoding ?;--} I have a DTD in which some entities are given the default value xFFFD in the external subset because they are placeholders for strings to be supplied in an internal subset with the document. Is this an appropriate use of Unicode's "replacement character"? Eric Eric Hellman Openly Informatics, Inc. http://www.openly.com/ Tools for 21st Century Scholarly Publishing xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 20:04:50 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:30 2004 Subject: Another errata? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D05494C@SOHOS002> Tyler Baker wrote: > Mark Birbeck wrote: > > It therefore needs a lot of them, and this is achieved by having > > effectively a 'namespace container' full of other (real) namespaces. > > That namespace container is an 'XML namespace' - which for > brevity, we > > call a 'namespace'. (Hey, I'm not disagreeing with you that it's > > tricky!!) > > Not only tricky, but unnecessarily tricky. I mean the words used are tricky, because namespace is used to mean 'real namespace' and 'XML namespace' interchangeably. But the context usually makes it clear which is implied. I'm *not* saying that using namespaces is tricky. Actually it's pretty easy. > XML should be a > tool for real-world business > solutions, not something that is more or less a puzzle some > CS professor designs for his > students. Yep. So how isn't it? Seems to be pretty real-world to me. > Namespaces is a pain to deal with no matter how > you look at it. Once you read a > document into memory and no longer preserve the original > prefixes (or rather the QName), when > you write the document back out (which has possibly been > mutated) where do you get these > prefixes? Why would you not preserve the prefixes? This is a bizarre point. If I delete the contents of my hard-drive shouldn't my word processor still open my letters? Of course not. As it happens, you couldn't delete the prefix anyway, because they are part of the names of the elements and attributes. Think of it like an XML 1.0 document - would you delete all characters before a colon in all names? Of course you wouldn't. Effectively you have an XML 1.0 document that conforms to the namespace spec if all 'Names' actually conform to 'QNames' (or in some cases NCNames). All that happens with namespaces is that you have an additional way of viewing your nodes over and above that defined in XML 1.0, and that is by namespace. > I suppose > the people in the "Namespaces in XML" feel that once you read > in a document, you throw it > away. They also believe the moon is made of cheese. > If people cannot understand what you write because the ideas > are too complex for the average > developer, then there is no real point in having a standard If all you ever develop is things that can be understood by the average developer then this discussion group would not exist since XML would not exist, and nor would space travel, electricity, and just about every philosophy ever invented. > > But if we're really honest here, if we were in a discussion group on > > compiler technology ten years ago, you would not have such > a wide range > > of people discussing these issues, and narrower range of > > misinterpretation (I'm not saying everyone understood > everything then > > either). That's not to say we shouldn't have more people > involved, but I > > That is because compiler technology is a totally different > field (and much more complex field) > than XML will ever be. If XML is to be used by only > developers and end-users who understand > compiler technology then it will fail miserably no matter how > much hype is in the presses > these days. Compiler technology is understandable today by most computer science graduates, as is XML. Yet does anyone remember trying to follow what the hell the guys at AT&T were up to with yacc (Yet Another Compiler-Compiler) and so forth. In fact teenage computer science students will be happily dealing in XML namespaces in two years time. And why should XML be understood by end users? Compiler technology isn't understood by most people who write C++ and Java programs. When my clients use Microsoft Office 97 they don't want to understand the file format. Why should that suddenly change when they use Office 2000? Sure, *I* want to understand the file format so I can do things with it, but that's my job. I also need to understand point-to-point tunnelling protocol, active directory services and domain name servers - unfortunately more than your 'average developer'. > > I disagree with this 'dumbing down' attitude that seems to > exist, where we > > must ensure that everyone can understand. If you want to > write a book > > making it clearer then do it - we'd all probably be > grateful - but the > > spec itself MUST be a formal document. > > I don't know what your definition of genius is, but mine is > simple "the ability to simplify > the complex". Quite plainly, if you can make reduce the > learning curve for our feeble human > minds to understand, it will take less time for people to > learn those concepts and they can > then take the time they have saved and work on new and > interesting tasks. Lovely. But I could equally say that the people who come up with the big stuff can obviously produce better things than those who have to be helped to understand what they've produced. They should therefore spend more time developing and less time explaining. Of course I wouldn't say that ... but by your criteria of efficiency I would be perfectly justified. In fact it has to be a bit of both - developing and educating - but my central point is that the standards writer is not responsible for take-up. It's great if they get involved - like some do on this list - but it's not an obligation. > If every generation > has to spend most of their adult life just learning > everything that the previous generation > created (but did not simplify) we will never have progress > because human beings will be very > old and very grey before they ever get the opportunity to > even think original thoughts. Seems to me that actually each generation simplifies what its ancestors produced. And then its the next generation who truly benefit from that. Nobody simplified (or complicated, depending on your standpoint (-:) Aristotle, Hegel, Marx, Einstein, Freud, and so on, in their own lifetimes. Yet today, most physics students can easily understand Einstein's theory of relativity. > > No! The job of the discussion *about* a spec is to find > agreement. Once > > that has been arrived at you need to codify that in a way that is > > unambiguous. It needs to be as formal as possible! > > If everyone told you to jump off a cliff would you do it? Very profound - but what are you on about? > Compromise on technical matters is > one of the worst things you can do. So why do you want understandable standards? Surely if you're against compromise you don't want *any* standards? > You think people read all of these books and take these > training courses because they want > to? They take them usually because the technologies they use > today are dictated to them. > Java's success is an example of people writing code in Java > because the "wanted to" because > Java took out 85% of the pain in C++. Nevertheless, I have > plenty of friends who still write > C++ code on new projects using MS Visual C++ because "old > grannies" at their institutions > think everyone should be doing things they way they did them > 10-15 years ago. They can't see > the benefits of Java being a simpler version of C++, because > they have not made an effort to > do so. An evangelical approach, I think. I know Java and C++, and many other languages. I think Java is great, and definitely one of the nicest languages yet to be devised, but still I don't use it. And that's after a great deal of evaluation. Essentially it promises what it can't deliver. Anyway, I think you have to allow people credit for coming to serious conclusions, even if, as may sometimes happen, they disagree with you. > If you write some spec without regard to simplicity > you are falling into a similar > model. "Namespaces in XML" is a pure example of simplicity > falling to the wayside in favor > of the attitude "well if I can understand it and no one else > can, then the whole world is > stupid". If someone wrote a book on namespaces and it was difficult to understand, then I would agree with you that it was a wasted effort. But a standard submitted to W3C? It *has* to be terse because it is being examined by numerous experts, who as far as I can see do *not* waste their time strutting around pretending the world is stupid. (Even if they did, I'd still thank them for XML, namespaces, XSL, XLink, HTML, HTTP, etc., etc.) I'm not quite sure why I'm getting so worked up about this, particularly given the lack of intervention by the standards writers themselves in their own defence! Maybe it's because over my 16 years in the business I've realised that the things that you learn yourself you *really* learn, and the people who are prepared to struggle to understand difficult concepts are the people you really want around you. We are lucky to be of the same generation as the innovators. *We* are getting the benefit of *their* developments, yet you are taking the attitude that you're doing *them* a favour by using their ideas! Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 amd0978 at acf3.nyu.edu Wed Feb 3 20:40:44 1999 From: amd0978 at acf3.nyu.edu (Adam M Donahue) Date: Mon Jun 7 17:08:30 2004 Subject: What is the purpose of ANY keyword ? In-Reply-To: <3.0.32.19990203141241.0073abb4@bl-mail2.corpeast.baynetworks.com> Message-ID: <Pine.OSF.3.95.990203153349.22493A-100000@acf3.nyu.edu> Not necessarily. <?xml version="1.0" ?> <!DOCTYPE example [ <!ELEMENT example ANY> <!ELEMENT foo (bar+)> <!ELEMENT bar (#PCDATA)> ]> <example> <foo></foo> <bar></bar> </example> Adam On Wed, 3 Feb 1999, Shekhar Kshirsagar wrote: > Hi, > > What's the purpose of ANY keyword in an otherwise strictly formed > syntax of XML ? > > Also is this right if I say that : > > "If a top level element of a DTD has a content specifier - > ANY, all the documents will be well-formed and VALID, > as far as they contain the elements from that DTD in any order." > > > Thanks & Regards, > Shekhar Kshirsagar > Nortel Networks. > > > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 clark.evans at manhattanproject.com Wed Feb 3 21:25:11 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:31 2004 Subject: Another errata? References: <A26F84C9D8EDD111A102006097C4CD0D054943@SOHOS002> <36B89820.18073A33@infinet.com> Message-ID: <36B8BDD6.E6FB2DCA@manhattanproject.com> <philosophy> Perhaps the role of namespaces is fundamentally different in the "stream processing" paradigm than it is in "object processing" paradigm? Could this be the issue underlying the current debate? I don't know enough on the topic to say. However, I feel I can help by explaining my observations about the differences between the paradigms. 1. A tenant of object oriented programming is encapsulation, data hiding. For stream processing it is the opposite, data exposure. 2. Objects are modified or undergo state change by invoking methods. Where streams are re-written or translated by transformations. 3. Ideally, an object retains it's identity. The entire goal of a stream is to merge it's information with each and every observer; this is equivalent to identity loss. 4. An object has a 1-1 correspondence between its data and its code. A stream has a 1-M correspondence between its data and its code. Where the document is the data, and the code is the observer's transformation system. 5. Objects are finite, they have a boundry. Streams may be effectively infinite. For example, a pressure transducer sending water level measurements may operate continuously for years! Thus, you can store an entire object in memory, you may not want to store an entire stream in memory. 6. An object's interface describes a block of functionality provided. A stream's interface describes the information conthat it carries. 7. An object has one type or class which is assigned to the data, where a stream can be classified differently by each and every observer. This is especially clear if you read about Arcetectures. etc. Anyway, I'm not saying that one is better than the other, just that they are different and subtly interwoven. For instance, Scenerios is the study of object interactions as a stream of events. And SAX is a wonderful event-driven stream observer object. I feel that the key to the success of XML is to recognize that it is part of a different paradigm --XML complements existing technology. As such, it is important to scrutinize the application of object-oriented idioms to the new paradigm. </philosophy> Hope this helps, Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Wed Feb 3 21:35:45 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:31 2004 Subject: Another errata? References: <A26F84C9D8EDD111A102006097C4CD0D05494C@SOHOS002> Message-ID: <36B8C0CC.9DF4541C@infinet.com> Mark Birbeck wrote: > Tyler Baker wrote: > > Mark Birbeck wrote: > > > It therefore needs a lot of them, and this is achieved by having > > > effectively a 'namespace container' full of other (real) namespaces. > > > That namespace container is an 'XML namespace' - which for > > brevity, we > > > call a 'namespace'. (Hey, I'm not disagreeing with you that it's > > > tricky!!) > > > > Not only tricky, but unnecessarily tricky. > > I mean the words used are tricky, because namespace is used to mean > 'real namespace' and 'XML namespace' interchangeably. But the context > usually makes it clear which is implied. I'm *not* saying that using > namespaces is tricky. Actually it's pretty easy. OK sorry for the misunderstanding here. I guess I took your words out of context... > > XML should be a > > tool for real-world business > > solutions, not something that is more or less a puzzle some > > CS professor designs for his > > students. > > Yep. So how isn't it? Seems to be pretty real-world to me. I guess this is less a matter of arguing objective facts anymore and more of a value-judgement now among people who find that "Namespaces in XML" is easy to understand for them and those who either find it hard to understand, or else feel it will be hard for novices to understand. It breaks down to a personal judgement call here. Nevertheless, I think it is clear that "Namespaces in XML" has not been a concensus building process. > > Namespaces is a pain to deal with no matter how > > you look at it. Once you read a > > document into memory and no longer preserve the original > > prefixes (or rather the QName), when > > you write the document back out (which has possibly been > > mutated) where do you get these > > prefixes? > > Why would you not preserve the prefixes? This is a bizarre point. If I > delete the contents of my hard-drive shouldn't my word processor still > open my letters? Of course not. As it happens, you couldn't delete the > prefix anyway, because they are part of the names of the elements and > attributes. Think of it like an XML 1.0 document - would you delete all > characters before a colon in all names? Of course you wouldn't. > Effectively you have an XML 1.0 document that conforms to the namespace > spec if all 'Names' actually conform to 'QNames' (or in some cases > NCNames). All that happens with namespaces is that you have an > additional way of viewing your nodes over and above that defined in XML > 1.0, and that is by namespace. Most DOM implementations that have namespaces support (Oracle's and SUN's are two that come to mind) do preserve the prefix information inherently (I am not sure whether QNames or expanded names are returned from calls to getNodeName() though). Some people here were arguing that in SAX 1.1 or whatever, that this prefix information should be lost because only the "namespace" should be relevant to the application. A lot of people seemed to agree with this point (I didn't as I favored parsers showing the application a Name type which could resolve prefixes and namespaces) that all you need to do is present the expanded name to the application. I am really confused here more than ever as to what on earth "Namespaces in XML" and those that support it are trying to accomplish with it more than ever. > > If people cannot understand what you write because the ideas > > are too complex for the average > > developer, then there is no real point in having a standard > > If all you ever develop is things that can be understood by the average > developer then this discussion group would not exist since XML would not > exist, and nor would space travel, electricity, and just about every > philosophy ever invented. There is a stark difference between research oriented development and business oriented development. In universities you will find that most CS professors are versed in all kinds of programming languages, some of them in-house ones they help to develop. They get paid to teach and do abstract research for the most part (sometimes they get grants from industry but even those grants deal a lot with abstract research). Whether anyone actually understands what they are doing is not relevant until they stumble onto something useful. Once they stumble onto something useful, then they may patent it or publish it or whatever they feel is appropriate. In the end, industry will take these ideas and try and apply this research to real-world problems. If things are too hot to handle and cost too much to develop, maintain, and support, any products resulting from this research will likely have a very small market. Is this what people want XML to be suited for: a very small market. I don't consider XML to be something that should be rocket science as its intended audience should be average developers. The number one goal I feel should be to have a simple markup language that more complex solutions can be built upon. "Namespaces in XML" makes building complex solutions harder because supporting all of the weird semantics of it is not easy to handle. > > > But if we're really honest here, if we were in a discussion group on > > > compiler technology ten years ago, you would not have such > > a wide range > > > of people discussing these issues, and narrower range of > > > misinterpretation (I'm not saying everyone understood > > everything then > > > either). That's not to say we shouldn't have more people > > involved, but I > > > > That is because compiler technology is a totally different > > field (and much more complex field) > > than XML will ever be. If XML is to be used by only > > developers and end-users who understand > > compiler technology then it will fail miserably no matter how > > much hype is in the presses > > these days. > > Compiler technology is understandable today by most computer science > graduates, as is XML. Yet does anyone remember trying to follow what the > hell the guys at AT&T were up to with yacc (Yet Another > Compiler-Compiler) and so forth. In fact teenage computer science > students will be happily dealing in XML namespaces in two years time. So should XML only be used by CS graduates? I sure hope not. Only about 10% or less of the entire IS industry is comprised of CS graduates. Should XML be relegated to geekdom or should it be something to bring the entire web together? I favor the latter as the web is made up of millions and millions of people, 99% or less of which have no programming experience, yet want to have control over the content they create. If the W3C screws up XML (like it seems to be doing with "Namespaces in XML", the entire web will be stuck in HTML land for the next 5 years. > And why should XML be understood by end users? Compiler technology isn't > understood by most people who write C++ and Java programs. When my > clients use Microsoft Office 97 they don't want to understand the file > format. Why should that suddenly change when they use Office 2000? Sure, > *I* want to understand the file format so I can do things with it, but > that's my job. I also need to understand point-to-point tunnelling > protocol, active directory services and domain name servers - > unfortunately more than your 'average developer'. Again XML is not rocket science. You can use it to do some very basic things or else you can get creative with it. Is the intention here to make XML as non-understandable by the masses as possible. This logic suggests this even though I am pretty sure that is not your intention here. > > > I disagree with this 'dumbing down' attitude that seems to > > exist, where we > > > must ensure that everyone can understand. If you want to > > write a book > > > making it clearer then do it - we'd all probably be > > grateful - but the > > > spec itself MUST be a formal document. > > > > I don't know what your definition of genius is, but mine is > > simple "the ability to simplify > > the complex". Quite plainly, if you can make reduce the > > learning curve for our feeble human > > minds to understand, it will take less time for people to > > learn those concepts and they can > > then take the time they have saved and work on new and > > interesting tasks. > > Lovely. But I could equally say that the people who come up with the big > stuff can obviously produce better things than those who have to be > helped to understand what they've produced. They should therefore spend > more time developing and less time explaining. Of course I wouldn't say > that ... but by your criteria of efficiency I would be perfectly > justified. In fact it has to be a bit of both - developing and educating > - but my central point is that the standards writer is not responsible > for take-up. It's great if they get involved - like some do on this list > - but it's not an obligation. Simpler specifications allow for less need for educating (because they are more direct and to the point) and more time others can devote to more creative endeavours. And on the flip-side if you have a great tool for doing all of the trivial tasks of the web, why screw it up? > > If every generation > > has to spend most of their adult life just learning > > everything that the previous generation > > created (but did not simplify) we will never have progress > > because human beings will be very > > old and very grey before they ever get the opportunity to > > even think original thoughts. > > Seems to me that actually each generation simplifies what its ancestors > produced. And then its the next generation who truly benefit from that. > Nobody simplified (or complicated, depending on your standpoint (-:) > Aristotle, Hegel, Marx, Einstein, Freud, and so on, in their own > lifetimes. Yet today, most physics students can easily understand > Einstein's theory of relativity. Understanding through dictation is far different than understanding something and being able to build on it. Some major advances in physics have come about since Einstein's death, but only a very small number of people on earth can do anything useful in terms of building upon Einstein's work. The last thing Einstein was working on was a simple formula for explaining in simple terms how the universe works. He never got that far, but even Einstein realized that > > > No! The job of the discussion *about* a spec is to find > > agreement. Once > > > that has been arrived at you need to codify that in a way that is > > > unambiguous. It needs to be as formal as possible! > > > > If everyone told you to jump off a cliff would you do it? > > Very profound - but what are you on about? > > > Compromise on technical matters is > > one of the worst things you can do. > > So why do you want understandable standards? Surely if you're against > compromise you don't want *any* standards? No I am saying that you either have concensus on what works the best and not try and just create something that makes everyone "feel good" but does not solve the ultimate problem. If you publish something called a standard, but it does not do the job, then you basically have nothing but a glorified piece of paper with a bunch of names on it. > > You think people read all of these books and take these > > training courses because they want > > to? They take them usually because the technologies they use > > today are dictated to them. > > Java's success is an example of people writing code in Java > > because the "wanted to" because > > Java took out 85% of the pain in C++. Nevertheless, I have > > plenty of friends who still write > > C++ code on new projects using MS Visual C++ because "old > > grannies" at their institutions > > think everyone should be doing things they way they did them > > 10-15 years ago. They can't see > > the benefits of Java being a simpler version of C++, because > > they have not made an effort to > > do so. > > An evangelical approach, I think. I know Java and C++, and many other > languages. I think Java is great, and definitely one of the nicest > languages yet to be devised, but still I don't use it. And that's after > a great deal of evaluation. Essentially it promises what it can't > deliver. Anyway, I think you have to allow people credit for coming to > serious conclusions, even if, as may sometimes happen, they disagree > with you. It depends on your problem domain I suppose. Millions use Visual Basic, even though some would hardly consider it a programming language. Yah Java does not do everything it promises, but I feel it does 95% of the stuff most developers need for most applications. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 3 22:08:25 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:31 2004 Subject: 'Strong' status for XML Message-ID: <199902032208.RAA29780@hesketh.net> I just visited the top W3C page. 'XML' is listed under the Architecture section, as usual, but it's bolded. I checked out the source, and it gets <strong> while nothing else does. Is this a promotion? An accident? It's kind of funny, anyway. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 Mark.Birbeck at iedigital.net Wed Feb 3 22:38:12 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:31 2004 Subject: Fw: Namespaces Message-ID: <A26F84C9D8EDD111A102006097C4CD0D05494F@SOHOS002> James, hope you don't mind me copying this to the group. I'd like to know what the other James thinks. James Anderson wrote: > James Clark's notation is readily extended to describe the same > things as you > desire. See my note in this thread. I suggest that it is to > be preferred to > the A.3 notation as it is compacter - it can, in a sense, be > expressed 'in > line'. > For reasons which I do not fathom, (see his reply to same) he > explicitly resists the extension and disregards the concepts > established in > appendix a. I don't follow you James. Where does he disregard appendix A? On the extension, I think he is right to resist it - although to be fair it is only a shorthand, not a new standard! If you think about what he is representing with his current stuff, he has devised a simple way of giving us clues as to how some post-parser software might be able to use the data. Given: <n1:good a="1" /> and mapping it via James's syntax to: <{http://www.w3c.org}good a="1" /> the post-parser can say that 'good' is part of the http://www.w3c.org namespace. Equally, given: <good n1:a="1" /> and mapping it to: <good {http://www.w3c.org}a="1" /> James has given us a further insight into the mind of the post-parser; it now knows that 'a' is part of the http://www.w3c.org namespace too. In other words, James's syntax is so far an accurate representation of what the post-parser knows. However, if we now 'extend' his syntax to map: <n1:good a="1" /> to: <{http://www.w3c.org}good {{http://www.w3c.org}good}a="1" /> as you seem to want (or at least Oren did, and I guess you are agreeing with him although I can't find your original message), we've now expressed something that is no longer consistent with what the post-parser knows. We are either saying that 'a' is a member of the namespace {http://www.w3c.org}good (if we treat the outer curly braces as representing a namespace name) but that is not a valid uri. Or we are saying that 'a' is a member of the namespace 'good' which is a member of the namespace http://www/w3c.org, which is (sort of) closer to what is going on in the intern representation of the XML namespace (according to appendix A) but is meaningless at this level, because James is talking about global namespaces, and so we need a uri. James did spell that out when he introduced his shorthand. (Even if we allowed this, I would have thought that the syntax {http://www.w3c.org}{good}a would be preferable.) In fact what the post-processor knows about the attribute 'a' is that it has no uri prefix and is part of the element 'good'. That *can be* expressed with James's syntax, provided that you keep 'a' with 'good' (as I said before, it is like an 'exploded' XML document): <{http://www.w3c.org}good a="1" /> but James's syntax cannot be used to express anything about 'a' outside of this, since you can't have: {{http://www.w3c.org}good}a as we've already said, and: a has lost all context. However, the extended attribute/element syntax I used - from Appendix A - at least *can* express something about 'a', without having to be in the original XML document: <ExpAName name='a' eltype="good" elns="http://www.w3.org" /> Personally, I prefer the latter method anyway, because it makes it clear that we are looking at a different view on the data. The XML 1.0 or parser 'view' of the data looks at elements and attributes, their values and their relationships to each other. The 'post-parser' view is of the same information but from the perspective of which namespace an element or attribute belongs to. It is possible that an element or attribute that has a direct relationship with an element in the first view has no relationship to that same element in the second view. Unfortunately, James's syntax mixes up these two 'views' of the data, by trying to superimpose the post-parser's view (of namespaces) onto the parser's view (of data). Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 peter at weblogic.com Thu Feb 4 00:54:01 1999 From: peter at weblogic.com (Peter Seibel) Date: Mon Jun 7 17:08:31 2004 Subject: XML parsing techniques Message-ID: <19990204010149913.AAA280@ashbury.weblogic.com@lawton> Is there anyone out there who can characterize the problems/challenges/best practices when it comes to parsing XML? Looking (briefly) at the source of a couple parsers (Lark, Microsoft's, and XP) it looks like the parsers are some flavor of hand written recursive descent. (Well, Lark has that funky hand-coded DFA thing which I didn't really spend much time trying to grok -- that's not really recursive descent as I understand things.) Is there a reason no one seems to be using parser generators (like ANTLR or JavaCC)? This may be more a question about the limitations of those tools which were designed for parsing things that look a lot more like Algol than XML does. -Peter P.S. Are there any parsers out there that actually return DOM objects? -- Peter Seibel Perl/Java/English Hacker peter@weblogic.com Is Windows98 Y2K compliant? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 01:15:32 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:08:31 2004 Subject: Since we're talking about databases... References: <000701be4f05$b9282800$5118a8c0@kuantech1.quokka.com> Message-ID: <36B8F407.5008@hiwaay.net> Jeffrey E. Sussna wrote: > > Please please please let this list not degenerate into a philosophical debate about the merits of various approaches to database design. I have been following the relational vs. object vs. object-relational debate for some ten years now, and the mere mention of Dr. Stonebraker's name still makes me shiver. :-) The papers referenced are not about the philosophy of database design, but the performance of different database implementations, particularly that affected by implementing object handling in the kernel vs the use of middleware. Len Bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 02:50:59 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:31 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <36B819D3.B65C07F3@prescod.net> Message-ID: <001801be4fe8$90127bd0$d3228018@jabr.ne.mediaone.net> Paul Prescod wrote: > If I am using a DOM interface, > it frankly > > doesn't matter what the serialization format is, I am > interacting directly > > with data through an interace. > > You are interacting with data through an interface that was designed to > provide access to the abstract data model of a *serialization*. In other > words you are treating your database as if it were the result of parsing > an XML document. You've put an "elements and attributes" interface on data > that is much more complex than elements and attributes. If it were not > more complex then elements and attributes we would not need stuff like > XLink, HyTime, Namespaces and RDF to even *attempt* (and fail) to > represent it. Really !? and I thought I was interacting with an interface designed to represent the abstract data model of XML. How could we have drawn such disparate conclusions. I *don't* care what the intention of creating the DOM interface was BTW just as I don't care what the intention of creating the C language was. I can use tools, interfaces as I see fit. Does the DOM represent XML data in full fidelity? If not, should it be extended? I'm not sure that the data is so much more complex than can be represented by the DOM interfaces. Perhaps I have a different view than you do. The way I see it, I can represent pretty much any piece of data using XML as I can with say an s-expr. The issue is only one of efficiency (as it has been with s-exprs). So, as I see it, if I put an efficient implementation behind an interface, it might work in ways you haven't imagined. > The XML data model, whether a grove or a DOM is the "Forrest > Gump" of representations for your data. Sending a dumbed-down message by > Forrest Gump is good: he will relate it faithfully. Installing him as the > only conduit for information is bad. You'll have to dumb down too much > information and spend too much energy re-assembling it on the other side. Really? And what is a more intelligent abstract data model? I'm not feeling too limited yet but perhaps I'm doing simplistic stuff. SGML has been around for years, but has never generated too much excitement. In contrast, XML. Sometimes simple is very very good. Sometimes, the simpler things get the more powerful they get. > > > I wouldn't suggest that the DOM replace ODBC, yet I'm > quite sure that those > > experienced using a variety of systems with disparate data > types and data > > usages will appreciate that certain types of data are best > expressed in tree > > format. Such data scenario's might best be interfaced with via the DOM. > > You just need an API for "tree formats". Just ask your DBMS vendor to > provide some tree-structured API. It doesn't matter if that API is the DOM > because making it the DOM does *not buy you anything* as a programmer. > From a programming point of view there is no benefit to working with a > consistent API where everything is dumbed-down to a textual model. You > might as well dumb everything down to an "object model." (see below) There exist dozens of proprietary database interfaces. Most people are willing to accept a common denominator which is mostly acceptable because the benefits gained by employing a widely accepted standard outweigh the benefits of a locally optimized proprietary interface. On the other hand if I want to create an optimized high performance system I already have lots of options. Most of these do use object oriented programming, not that I can't do it all in assembler, but rather because of the benefits of maintainability and the reasonable performance of modern compilers. The benefits of object oriented programming are orthogonal to object databases. > > If you buy this, then guess what the hype will be in three years: "These > new fangled data bases have this really cool feature, dude. You call it > with a SQL9X query and it can return like OBJECTS!. Everything in the > world can be expressed as objects! Lists of objects. Lists of objects. > Trees of objects. Directed graphs of objects. Arbitary graphs of objects. > It like unifies everything as objects. It's Zen, man. They call it 'JDBC' > and its totally wicked." What are you trying to say here? Are you criticizing objects? > > The *only benefit* of unifying things as DOMs is reusing software that was > originally supposed to work with XML (i.e. XSL implementations). If you > are writing new software it makes NO SENSE to do it through a DOM > interface unless your data source is *XML*. Suppose I want to process the data using XSL? Is this conceivably an acceptable reason to use a DOM interface (assuming I don't actually want to convert my database to serialized XML itself). > > Otherwise, you should just define a "tree node" interface and have your > various objects implement it. You will get all of the the benefits of the > DOM with none of the costs (i.e. how the hell do you represent complex > properties of objects???). If you want some good hints about what a "tree > node" interface looks like, take a look at the grove abstraction. > ... > > Second, Even *XSL* is not best served by a DOM representation. James Clark > wrote an xsl-list article about that but I can't find it now. Remember > that the DOM was invented as an extension of "DHTML." It's only half > "there." Certainly XSL is best served by a DOM representation if the data is presented via a DOM interface. The other option is to serialize everything. This makes no sense unless the DOM implemention is sub-optimal. > > But if I grant that some well-thought-through API for XSL trees could > exist (i.e. Jade's grove API) then I would propose that it only be used as > an optimization in a system where it would otherwise make sense to pass > around serializations of text documents. i.e. the DOM is okay for skipping > a layer of message passing. It is not okay as a "universal API" for "all > of the data in an organization." I never said this. There is a difference between saying that something is useful (i.e. placing a DOM interface on a database) and saying that this is the only way things ought to be done. > > To bastardize JWZ: "Sometimes people have a hard data unification problem. > One part of their organization speaks a very different language (at the > data model and object model level) than another part. They might think 'I > can unify these with XML or the DOM.' Now they have two problems." > > There second problem is that they didn't understand the really hard > problem in their organization. Data model unification is *easy* (cast to > java.lang.object or w3c.dom.node). Data model *rationalization* is very > difficult. And I don't think that there are many shortcuts. > > > Are the DOM interfaces the best for all situations, > clearly not. However if > > a significant percentage of people can agree to use them a significant > > percentage of the time, this is a big win. > > That's not going to happen. The DOM will NOT be a core tool for that > majority of OO programmers this year, next year, or ever. Programmers will > try it and increasingly find that if they are not doing XSL styling for > the Web or print that the DOM is not a core tool. "Old-fashioned" OO can > provide the same benefits. What I am saying is that if these interfaces are accepted as a standard mechanism for representing XML data, that this in and of itself is a big win. XML is not close to replacing OO in fact it seems to be struggling with OO concepts itself. It is a big mistake to assume that XSL is only to be used for 'styling for the Web or print'. DSSSL as we know is based upon or employs Scheme. Scheme is a full fledged programming language, a dialect of LISP. XSL does not have the Scheme counterpart to DSSSL, rather it is itself its own programming language (albeit currently simplistic). XSL is the first XML programming language and employs XML in a directly analagous way that LISP employs s-exprs. If I feel that I can express any data structure in XML that I can express as an s-expr, I see no good reason that, with proper extensions, XSL would not be able to handle tasks that Scheme, or Lisp have been applied toward. I believe XSL has a great future. If NN and IE contained native Lisp interpreters this might not be at all a big deal, what I find interesting is that a high percentage of desktops will, in the near future, gain the ability to run a data based transformation language. Perhaps the first use is an engine to display XML as HTML. I've developed a medical records system which employs XML and XSL to do relatively simple processing on the client (and have used the DOM interface for this BTW). As someone who has used many different programming languages and systems, I have found surprised at what can be done with the combination of XML, the DOM, XSL and JavaScript. The bottom line here is easy of development and deployment. This is my initial experience. Use your imagination. 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 Thu Feb 4 03:49:20 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:08:31 2004 Subject: Restricted Namespaces for XML Message-ID: <000d01be4ff1$286876c0$2ee044c6@arcot-main> This is not a proposal but a testing of the water to see if there is a wide enough need for a 'restricted' (some might call it constricted) version of the "Namespaces for XML" spec (lets call it RNX for now). Such a spec might dictate that all namespace declarations be at the root element (XML fragments are problematic but...). This restriction has the side effect of not allowing duplicate prefixes. Comments? 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 marcelo at mds.rmit.edu.au Thu Feb 4 03:51:26 1999 From: marcelo at mds.rmit.edu.au (Marcelo Cantos) Date: Mon Jun 7 17:08:31 2004 Subject: What is a good database for very large collections? In-Reply-To: <no.id>; from Borden, Jonathan on Mon, Feb 01, 1999 at 12:33:53PM -0500 Message-ID: <19990204144908.C20720@io.mds.rmit.edu.au> On Mon, Feb 01, 1999 at 12:33:53PM -0500, Borden, Jonathan wrote: > > > > Can I try to shift it back to a vital question asked earlier, but not > > answered? > > > > What is a good database for XML? SIM (http://www.simdb.com/sim_2.1/ > > The criteria are: > > * over 20, 000, 000 document fragments, each less than 256 > > characters, each with some flat metadata, able to be incrementally > > reloaded onto the live system > > * about simultaneous 30 users accessing about 10 fragments a minute > > each, grouped together (along with other dynamic data) and transformed, > > with a high need for immediate response We can load about 200 MB per hour while live (actually I think we can load 400-500 MB/hr but we claim 200 MB to add a safety factor). We handle small documents quite well through DTD caching techniques (we also plan to include expat in the near future for unvalidated XML. We do currently support unvalidated XML, but through SP, which is not as fast as we'd like). Queries are fast (we queried "to be or not to be" across 55 GB in 74 seconds on a 2x336 MHz UltraSPARC with 1 GB RAM--note that this was a word position query using several stop words). > How are the fragments selected? By query? If you can easily > represent the 20M fragments in tabular form, and if you can easily > represent the queries in SQL then a relational db is the way to go. > this is not a particularly large, nor high-volume application for > RDBMS. And if you can't represent them in tabular form, try SIM. > Ought you store the 20m fragments each in its own file ... probably > not (a big waste). Ought you employ an ODBMS? not unless SQL > wouldn't work well (you could always load it into say Oracle/SQL > Server/DB2 etc vs. ODI/Poet etc and test it out). My expectation > would be that if you need to run queries, the RDB will win. For content queries (e.g. summary CONTAINS "stock option*") SIM will easily outperform an RDBMS. Customers have chosen our product above RDBMS's for this very reason. > > * constant data-mining tools using various adhoc AI and linguitic > > retrieval software augmenting the metadata in the background. We support stored queries and scheduled queries with filters to exclude previously returned records. I'm not sure if this meets the above requirement. To say there are no scalable solutions (as someone did recently on xml-dev) is simply false. There may be no scalable solutions that do everything you want--and I'm certainly not touting SIM as the be-all and end-all (we have yet to support XQL, full path indexing, transactions, etc. all are pending with varying levels of priority)--but there are products available right now that scale and solve people's problems. SIM has been used in law (http://www.thelaw.tas.gov.au is the world's first legislation to officially go online), taxation (http://www.ato.gov.au/general/advanced/adv.htm), other government (libraries, NSA--no URL, sorry :-), aviation (Boeing), etc. Moreover, our customers don't go away dissatisfied. We are quite proud of the fact that every SIM site is a reference site. We are also pleased that in some instances, project managers have been promoted as a result of using SIM! Cheers, Marcelo Cantos SIM developer -- 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 mda at discerning.com Thu Feb 4 04:06:21 1999 From: mda at discerning.com (Mark D. Anderson) Date: Mon Jun 7 17:08:31 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) Message-ID: <03ae01be4ff3$772a4a20$0200a8c0@mdaxke.mediacity.com> Very interesting discussion. Let me try to "echo back" what I'm hearing. On one side, there are those who think of XML primarily as a serialized representation of The Real Thing. They decry notions of programming via the DOM for two reasons: - (eliot kimber) The XML data model that you would use programmatically may not actually match the the data model of The Real Thing. - (paul prescod) Using the DOM or other XML-level manipulation is a level of indirection from manipulating The Real Thing, and is hence more obscure and inefficient. Then on the other side (not that I'm trying to make this a battle), there are those who say: um, ok, but trust me, there are cases where I really don't want to deal with The Real Thing because in my application there are actually a lot of heterogenous Real Things. Or maybe just one, but it is unbelievably painful to deal with (say, IBM CICS). Or maybe some demented person is keeping the Real Thing itself in xml. And I would like to have a "standard" way to address that model -- meaning some way to read and possibly write it from a programming language. (Does this include simon sl, tim b, david m?) Then on the other side (I'm just reflecting how these discussions go :)) there are those who say well, ok, but it is futile to try to find such a mapping that works on all data models (including both tabular style and document style) from our many varied programming languages. And to the extent that it is possible, it already exists (list your favorite set of perl grove utilities here). Just to add my own $.02, I feel that it *is* possible to arrive at a common API, with automatic transformed equivalence among programming languages. It isn't the DOM, or just the DOM, because the DOM forces programming based on things like "getAttribute", not "employees.next().name". Sort of like doing lisp programming entirely with "car" and "cdr". However, I think that it can't be done until things like XLink and DCD-the-next-generation are squared away, and it will be mostly useful to scripted languages that can do such dynamic binding -- though i expect that a gen utility could make .h files to allow similar programming from C/C++, in much the same way that some object-relational gateway products work. -mda xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Thu Feb 4 04:13:25 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:31 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <001801be4fe8$90127bd0$d3228018@jabr.ne.mediaone.net> Message-ID: <36B91D93.83627AFE@manhattanproject.com> Jonathan Borden wrote: > What are you trying to say here? > Are you criticizing objects? You can't always treat a stream as object. If you do, you loose significant power. > Suppose I want to process the data using XSL? Is this conceivably an > acceptable reason to use a DOM interface (assuming I don't actually want to > convert my database to serialized XML itself). I would see this as the last thing you would want to do. However, I don't have XSL experience, so someone with real-world experience would be a better spokesperson. DOM requires the entire stream be read before the the document object is returned and processing can begin. Not only does this chew significant memory for very large streams, but it causes significant delay before output could be generated. In the worst case, it turns a perfectly simple problem into an "impossible" one where the memory requirements and time delay make the solution useless. If the stream is only going to be "filtered", why read the entire thing into memory before starting the transformation process (in this case filtering)? > Certainly XSL is best served by a DOM representation if > the data is presented via a DOM interface. I would speculate to the contrary, and would think that driving XSL with SAX would be a far better choice. > The other option is to serialize everything. No. The option is to move to Event based processing of streams. You can then model with "event objects" > This makes no sense unless the DOM implemention is sub-optimal. No. It's a computational complexity issue. For a decent size stream, with a transformation that can be done in a single-pass (XML->HTML), no DOM implementation will even come close to an implementation using SAX. Crunch some numbers. If your still not convinced, read Ableson, Structure and Interpretation of Computer Programs, ISBN 0-07-000484-6, Section 3.5.1, page 317. There he talks about: "severe inefficiency with respect to both time and space". Best, Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 04:39:29 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:32 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <36B91D93.83627AFE@manhattanproject.com> Message-ID: <001f01be4ff7$bbc30830$d3228018@jabr.ne.mediaone.net> Clark Evans wrote: > > DOM requires the entire stream be read before the > the document object is returned and processing can begin. > Not only does this chew significant memory for very large > streams, but it causes significant delay before output > could be generated. In the worst case, it turns a > perfectly simple problem into an "impossible" one > where the memory requirements and time delay make > the solution useless. You are missing the point. Since the data is already deserialized, there is no delay due to processing. The idea is that the data has already been entered into a database which implements a DOM interface (the database is free to implement other interfaces as well). I never claimed that the data was entered as XML or that a serialized XML document ever existed. Your entire argument assumes that there is a need to parse XML into an in-memory DOM during the processing phase. This is incorrect. 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 paul at prescod.net Thu Feb 4 04:54:43 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:32 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <001801be4fe8$90127bd0$d3228018@jabr.ne.mediaone.net> Message-ID: <36B92536.D5BF3AA0@prescod.net> "Borden, Jonathan" wrote: > > > You are interacting with data through an interface that was designed to > > provide access to the abstract data model of a *serialization*. > Really !? and I thought I was interacting with an interface designed to > represent the abstract data model of XML. Right. XML is a serialization. The DOM is an abstraction of a serialization. Not an abstraction over your data. If your "problem" is representing debit card bank accounts the proper abstraction over that is "bank account" or "currency account". The *wrong* abstraction is "elements and attributes." > How could we have drawn such > disparate conclusions. I *don't* care what the intention of creating the DOM > interface was BTW just as I don't care what the intention of creating the C > language was. I can use tools, interfaces as I see fit. Does the DOM > represent XML data in full fidelity? No. It isn't meant to. > If not, should it be extended? No. It isn't meant to. > I'm not sure that the data is so much more complex than can be represented > by the DOM interfaces. XML is very simple. "All the world's data" is very complex. That's why we need XLink, RDF, HyTime and a bunch of other stuff. If your API to "your data" is simply the DOM then you are temporarily hiding its complexity behind a simple layer that can *NOT* express its "linkedness", its complex class relationships, is geographical 2D-ness etc. I don't know your data. I don't know what makes it complex but if your job is interesting it IS complex and the DOM does not help you to manage that complexity. We have 20 years of software engineering that DOES help us to manage that complexity and its most recurring message is "abstraction, abstraction, abstraction." Dumbing data down to a DOM is the opposite. "If we make the trees large enough then a forest and an orchard will look the same." Too bad you still can't see the forest for the trees. > Perhaps I have a different view than you do. The way > I see it, I can represent pretty much any piece of data using XML as I can > with say an s-expr. I've never claimed otherwise. The question is whether XML presents a good *API* to that data. > Really? And what is a more intelligent abstract data model? Object orientation. > > If you buy this, then guess what the hype will be in three years: "These > > new fangled data bases have this really cool feature, dude. You call it > > with a SQL9X query and it can return like OBJECTS!. Everything in the > > world can be expressed as objects! Lists of objects. Lists of objects. > > Trees of objects. Directed graphs of objects. Arbitary graphs of objects. > > It like unifies everything as objects. It's Zen, man. They call it 'JDBC' > > and its totally wicked." > > What are you trying to say here? Are you criticizing objects? No. I am saying that the only "API" that can unify all of the complexity of all of the data in an enterprise is "object orientation" or perhaps something even more powerful. Dumbing everything down into elements and attributes is not a step forward, but a step backward. The DOM itself is evidence of this. Note that the DOM's creators did not make a CSS DOM by representing CSS in terms of elements and attributes. They made a whole new set of methods and properties. They used *object orientation* not XML. The CSS DOM has absolutely nothing to do with XML *as it should not*. > Certainly XSL is best served by a DOM representation if the data is > presented via a DOM interface. The other option is to serialize everything. > This makes no sense unless the DOM implemention is sub-optimal. No. The other option is to make an API that takes into account the needs of XSL implementation. > What I am saying is that if these interfaces are accepted as a standard > mechanism for representing XML data, that this in and of itself is a big > win. XML is not close to replacing OO in fact it seems to be struggling with > OO concepts itself. The DOM is pretty good at representing XML data. If that is all you want to say, fine. The point of this thread is that there are people who think that the DOM is great at representing data of all sorts. You should just throw a DOM interface over your database and all of your interoperability problems will go away. > It is a big mistake to assume that XSL is only to be used for 'styling for > the Web or print'. DSSSL as we know is based upon or employs Scheme. Scheme > is a full fledged programming language, a dialect of LISP. XSL does not have > the Scheme counterpart to DSSSL, rather it is itself its own programming > language (albeit currently simplistic). XSL is not a programming language according to the Turing/Church definition. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Feb 4 05:35:40 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:32 2004 Subject: Restricted Namespaces for XML References: <000d01be4ff1$286876c0$2ee044c6@arcot-main> Message-ID: <36B93164.5956509B@infinet.com> Don Park wrote: > This is not a proposal but a testing of the water to see if there is a wide > enough need for a 'restricted' (some might call it constricted) version of > the "Namespaces for XML" spec (lets call it RNX for now). > > Such a spec might dictate that all namespace declarations be at the root > element (XML fragments are problematic but...). This restriction has the > side effect of not allowing duplicate prefixes. > > Comments? Of course this is very much like the old PI approach will may have been brutally simple, but this I think was a good thing. There are many other ways of assuring that all Names in a document are unique that make much more sense than "Namespaces in XML", the simplest being that element types have some unique identifier prepended to your general name type. Perhaps this adds a bit to the total size of XML documents. For example if I wanted to represent some element that mapped to a java.awt.Rectangle class I might have something like: <java.awt.Rectangle x="0" y="0" width ="100" height="100"/> In this case the convention is package name + '.' + class name. With a DTD you are already there. It is really that simple. If you want to use a domain name plus some path, you could have something like: <www.amazon.com:books:history title="The History Of Europe"/> where you merely replace path separators with ':'. Of course namespaces (the old simple PI based approach) I think would help a lot in search engines as they would only have to scan the prolog of the document to see if any well-known namespace elements are used in the document. Perhaps we can take a vote on this list to see whether people like the old PI based namespaces proposal better than how things are currently defined. Nevertheless I really like this RNX idea you are proposing. I am not against namespaces per se (most XML applications I don't think will ever need any namespaces mechanism though), but I think that the final decision makers of "Namespaces in XML" somehow neglected the myriad of already noted problems with "Namespaces in XML" as things now stand. If they will ignore the total lack of concensus on this issue, then it is likely their efforts in the future will be ignored. Right now I have to spend a lot of otherwise unnecessary time dealing with implementing a very complex, somewhat inefficient hack to implement namespaces in an XSL Processor I have been working on so that I can have support for the DOM has well. The alternative is no DOM source tree support or else building a proprietary source tree structure as in the case with XT. Koala and LotusXSL have support for namespaces, but they have chosen an implementation path I chose to ignore a long time ago because it causes major performance problems. At this stage in the game with XSL, I doubt that Jeremy Calles or Scott Boag care much about performance. Most XSL users I feel now are very early adopters and are just getting familiar with stylesheets and the XSL processing model, so performance is not such a big issue to get all excited about at the moment. Right now XT is the only released XSL processor that has decent performance IMVHO, however since XT has no DOM support at all, I am not sure how useful it is in most production environments at this point (XSL is still in its infancy so a lot of things could change in the future that may cause all XSL Processor developers to totally change their design altogether). Since XSL still has 6 months before it will probably become a recommendation, none of these namespaces issues I feel matter too much right now, but if they are not addressed sometime soon, they will cause major problems down the road. Of course the DOM could change to provide native support for namespaces, but Level 1 is a recommendation now (i.e. immutable). My faith in the W3C right now is at an all-time low, so my guess is that the DOM will not change, "Namespaces in XML" will not change, and XSL plus the DOM will be a pain to deal with because of needing to support "Namespaces in XML" without incurring too much overhead. So in the end XSL users suffer by needing to throw extra hardware to use XSL to operate their web sites and that is a shame. A member on this list (I forget who) was talking about why they use expat and not XSL right now and their number one concern was performance (they basically said that they were getting 120X performance gains with the expat approach which no matter how you cut it is significant). I am not sure how much overhead namespaces support will add right now to my particular XSL implementation (it is hard to say because I am using a trick/hack that is hard to pin down in terms of O notation), but I would not even have to deal with this if the old PI based approach was used. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Thu Feb 4 05:46:04 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:08:32 2004 Subject: Fw: Namespaces References: <A26F84C9D8EDD111A102006097C4CD0D05494F@SOHOS002> Message-ID: <36B9302C.390A6F70@jclark.com> Mark Birbeck wrote: > The XML 1.0 or > parser 'view' of the data looks at elements and attributes, their values > and their relationships to each other. The 'post-parser' view is of the > same information but from the perspective of which namespace an element > or attribute belongs to. I would say that the difference between the view that the parser gives you and the view that the post-parser (namespace processor) gives you is simply that, in the post-parser view, element and attribute names can be qualified by a URI. There is no need to make it any more complex than that. All this stuff about namespaces is just unnecessary, confusing complexity that invites the over-analysis that is so prevalent in this forum. If the spec was called something like "XML Universal Names" and never mentioned the word "namespace" and didn't include Appendix A (which thankfully is not normative), absolutely no functionality would have been lost and I think there would have been far less confusion. I've updated my note http://www.jclark.com/xml/xmlns.htm to try to address some of the comments I've received. 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 tyler at infinet.com Thu Feb 4 06:00:15 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:32 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <001801be4fe8$90127bd0$d3228018@jabr.ne.mediaone.net> <36B91D93.83627AFE@manhattanproject.com> Message-ID: <36B936DF.495F9CAE@infinet.com> Clark Evans wrote: > Jonathan Borden wrote: > > What are you trying to say here? > > Are you criticizing objects? > > You can't always treat a stream as object. If you do, you > loose significant power. > > > Suppose I want to process the data using XSL? Is this conceivably an > > acceptable reason to use a DOM interface (assuming I don't actually want to > > convert my database to serialized XML itself). > > I would see this as the last thing you would want to do. > However, I don't have XSL experience, so someone > with real-world experience would be a better spokesperson. > > DOM requires the entire stream be read before the > the document object is returned and processing can begin. > Not only does this chew significant memory for very large > streams, but it causes significant delay before output > could be generated. In the worst case, it turns a > perfectly simple problem into an "impossible" one > where the memory requirements and time delay make > the solution useless. This is only true if you are building the DOM from a file. What if you are building up the DOM Document programmatically or else the DOM is merely an interface to structured data in a DBMS. > If the stream is only going to be "filtered", why read > the entire thing into memory before starting the > transformation process (in this case filtering)? In some cases, this is possible and even desirable. In this case of XSL the spec enforces constraints which make it impossible to be able to properly process an XML document unless it has been fully parsed into an in-memory tree structure (for most people this will be the DOM). > > Certainly XSL is best served by a DOM representation if > > the data is presented via a DOM interface. > > I would speculate to the contrary, and would think that > driving XSL with SAX would be a far better choice. No way. You are totally throwing out all of the applications that create a DOM document programmatically (such as through scripting). The alternative is to build a DOM document programmatically, write it out to XML, reparse it with an XML parser, and then process the document as SAX parsing events. This is an extra layer of indirection that is otherwise totally unnecessary if you use the DOM. The only other option is to take the DOM (an already parsed in-memory tree), parse it into SAX events using something like SAXON, and then reparse things back into another entire custom source tree. Again another layer of indirection which in languages like Java which that are particularly sensitive to unnecessary object allocation, a major cost in processing an XML document. > > The other option is to serialize everything. > > No. The option is to move to Event based processing > of streams. You can then model with "event objects" You still need to waste time recreating a source tree when you already have the DOM. Writing code to recursively spit out SAX parse events directly (instead of building a tree first) is not an easy chore and in many cases is totally impractical (you need to do everything sequentially in document order to make things work). > > This makes no sense unless the DOM implemention is sub-optimal. > > No. It's a computational complexity issue. For a > decent size stream, with a transformation that can > be done in a single-pass (XML->HTML), no DOM > implementation will even come close to an implementation > using SAX. Crunch some numbers. Already have. My results are quite the opposite. The most significant overhead to using the DOM is quite frankly dynamic method overhead for node iteration. With respect to Java and future optimizing compilers, this will become less and less of an issue. The costs for object allocation in one way or another will always be there. > If your still not convinced, read Ableson, Structure and > Interpretation of Computer Programs, ISBN 0-07-000484-6, > Section 3.5.1, page 317. There he talks about: > > "severe inefficiency with respect to both time and space". In general I would agree with your assertions, but it is an engineering fact that in languages like C++ and Java, object allocation tend to be in a lot of apps the number one performance bottleneck in applications which are not sensitive to reducing this overhead. One of the most famous examples in Java is in the Java AWT when calling getSize() over and over in paint methods. Doing this can bring some apps to a crawl as the code of java.awt.Component.getSize() looks something like this: public Dimension getSize() { return new Dimension(width, height); } java.awt.Component in JDK 2 now has getX(), getY(), getWidth(), and getHeight() methods to reduce unnecessary object allocation and which for some GUI apps has made a major difference in paint routines. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 06:13:48 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:32 2004 Subject: Another errata? Message-ID: <3.0.32.19990203220702.00b40a80@pop.intergate.bc.ca> At 01:40 PM 2/3/99 -0500, Tyler Baker wrote: >Once you read a >document into memory and no longer preserve the original prefixes (or >rather the QName), when >you write the document back out (which has possibly been mutated) where do >you get these >prefixes? Do you simply invent them in the form a, b, c, ..., aa, ab, ac, >... etc. Exactly. I can't imagine why you think this is hard. > I suppose >the people in the "Namespaces in XML" feel that once you read in a document, you throw it >away. When read something this ludicrous, I stop reading. -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 clark.evans at manhattanproject.com Thu Feb 4 06:17:30 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:32 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <001f01be4ff7$bbc30830$d3228018@jabr.ne.mediaone.net> Message-ID: <36B93A9A.EEC43FFB@manhattanproject.com> "Borden, Jonathan" wrote: > You are missing the point. Since the data is already deserialized, there is > no delay due to processing. The idea is that the data has already been > entered into a database which implements a DOM interface (the database is > free to implement other interfaces as well). I never claimed that the data > was entered as XML or that a serialized XML document ever existed. Oops! Sorry about not getting the context right. *blush* Let me try again. Anyway, I see one context where putting a DOM interface on a relational database would be great, and I see another context where I don't think it would be too hot. Interactive "generic" organizational navigator ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I did something like this at Ford. I found that organizational navigation has these characteristics: a. Only a small fraction of the information in the database is queried. b. It is interactive, the system is best modeled as a bunch of small queries rather than one big query. c. It is hierarchical in nature (Xrefs are rare) as the user goes down a branch, you store all of the primary keys on the stack. The big problem with the implementation was that the mapping from a custom relational-database model to the DOM model is, let's say, non-trivial. On the flip side, however, things are much more cheerful. A wonderful, re-usable CORBA/DOM client could be built (with very good market potential). This results in great re-use from not only a software, but also from a training perspective. Query Extraction Layer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I can also see an XML stream as the result from a query. In this case, the de-normalized, hierarchical view of the information resulting from a nested query is the stuff reports are made of. I picture the client using XSL on the resulting stream to generate a report. In effect, the XML output stream becomes what you would normally call a view. Then, each "user" can filter/format the information as they would like using a standardized XSL based client. I don't think this is new... and I'm looking forward to mature technology doing this. However, I'm not sure about using DOM as an interface to a relational database in this context. The way Oracle and other databases compute large queries with subordinate tables is, at its heart, stream-oriented. Many of these databases will "drive" off a single table sequentially, collecting the information from the subordinate tables as the query progresses. Therefore, I picture a DOM implementation using thousands of nested queries to generate the same tree that a few large queries would have handled nicely. In this case, the database engine would not be able to take advantage of aggregate indexing and elimination algorithems. In effect, negating the benifits of having corporate information in a relational database. *smile* Anyway, I just can't picture using DOM in this context as an interface to a relational database. For this case I feel using a stream-oriented solution on the server with an object-oriented event processing system on the client seems the better approach. :) Clark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Thu Feb 4 07:02:24 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:32 2004 Subject: A weaker XSL? (Was: Storing Lots of Fiddly Bits ) References: <001801be4fe8$90127bd0$d3228018@jabr.ne.mediaone.net> <36B91D93.83627AFE@manhattanproject.com> <36B936DF.495F9CAE@infinet.com> Message-ID: <36B94536.2E9272C8@manhattanproject.com> Tyler Baker wrote: > In this case of XSL the spec enforces constraints which make it impossible > to be able to properly process an XML document unless it has been fully > parsed into an in-memory tree structure (for most people this will be the DOM). Wow! Not what I had expected. I guess I have much to learn. *smile* Anyway, I have a negative-gut reaction to such a strong requirement. It comes from being burned on many occassions -- it is very easy to underestimate the memory size and processing time required to translate a stream into an object for further minipulation. Is there a possibility for creating a sub-set of XSL that would work on a stream instead of requiring a complete document object? I picture a database doing all of the sorting and other non-stream operations before/as the XML is created. Thus, the sub-set of XSL should be capable of being driven from a SAX equivalent stream event observer. :) Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Thu Feb 4 08:05:19 1999 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:08:32 2004 Subject: Control Characters Message-ID: <199902040804.AA03400@murata.apsdc.ksp.fujixerox.co.jp> >Why are the control characters x80-x9F allowed in XML character data, while >x0-x8,xB,xC,xE-x1F are illegal? Is it that the illegals have meanings that >XML does not support? Just wondering. I am afraid that you are right. XML should have disallowed C0 control codes and C1 control codes except CR, LF, and HT, since the Unicode standard does not define semantics of these control codes. U+007F should have been disallowed as well. However, I do not think that this causes practical problems. Cheers, Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Thu Feb 4 08:08:30 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:32 2004 Subject: Another errata? References: <3.0.32.19990203220702.00b40a80@pop.intergate.bc.ca> Message-ID: <36B9551D.5974523F@infinet.com> Tim Bray wrote: > At 01:40 PM 2/3/99 -0500, Tyler Baker wrote: > >Once you read a > >document into memory and no longer preserve the original prefixes (or > >rather the QName), when > >you write the document back out (which has possibly been mutated) where do > >you get these > >prefixes? Do you simply invent them in the form a, b, c, ..., aa, ab, ac, > >... etc. > > Exactly. I can't imagine why you think this is hard. But then the XML output is not what I would call readable anymore which violates goal number 6 in the XSL draft: "XML documents should be human-legible and reasonably clear." Once a document has been read into memory it may lose all of the original structure (maybe transformed is not the right word here). You no longer preserve the prefix names that the original author of the content (or even DTD) had intended. What you write out to XML may no longer conform to any DTD. > > I suppose > >the people in the "Namespaces in XML" feel that once you read in a document, you throw it > >away. > > When read something this ludicrous, I stop reading. -Tim What I mean is simply, once you read in a document, you process it and then you are done with it. I suppose "throwing it away" was a little inaccurate. Sorry for the misunderstanding here, Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matt at veosystems.com Thu Feb 4 08:09:50 1999 From: matt at veosystems.com (matt@veosystems.com) Date: Mon Jun 7 17:08:32 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <36B92536.D5BF3AA0@prescod.net> from "Paul Prescod" at Feb 3, 99 10:42:30 pm Message-ID: <19990204080821.21049.qmail@veosystems.com> A non-text attachment was scrubbed... Name: not available Type: text Size: 3698 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990204/2d7f48ef/attachment.bat From donpark at quake.net Thu Feb 4 08:17:42 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:08:32 2004 Subject: Restricted Namespaces for XML Message-ID: <003101be5016$ad13c850$2ee044c6@arcot-main> If I read James Clark's message correctly, I believe he is in favor of chopping out some features out of the "Namespaces for XML" as well as some sections so I believe we might be on a good track. Another crazy idea I had was to remove the use of URI while keeping the basic style. The idea is to just use prefixes as the qualifier. I don't think the need for universally unique names is paramount. Default namespace can be defined by stating what the default prefix is. For example, <html xmlns="html" xmlns:html="html" xmlns:ck="ck"> <head> <ck:cookie>some cookie info</ck:cookie> </head> </html> All the namespace declarations must be at the root element and prefixes are global to the document (well, within the root element). The result is something that conforms to the "Namespaces for XML" yet easy to understand and use although some flexibilities are lost. [snip] >that is a shame. Lets try to make some drinkable wine out of sour grapes. I am the sort of guy whose adrenaline kicks in when everything seems to go wrong. It doesn't matter if the result sucks as long as you do your best and not get sidetracked by useless negative emotions. 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 spreitze at parc.xerox.com Thu Feb 4 08:33:16 1999 From: spreitze at parc.xerox.com (spreitze@parc.xerox.com) Date: Mon Jun 7 17:08:32 2004 Subject: A New Hope (was Re: Storing Lots of Fiddly Bits (was Re: What is XML for?)) In-Reply-To: <19990204080821.21049.qmail@veosystems.com> Message-ID: <99Feb4.003256pst."834439"@idea.parc.xerox.com> Right! I think a significant part of the problem here is that people are realizing that XML's data model is not as expressive as they'd like. For example, XML's entity structure looks like a semi-labelled graph (vertices are labelled (with entity tags) but edges are not labelled), whereas many other data models (e.g., RDF) let you label both the edges and the vertices. Sure, you can encode any other data model into XML, and we'll probably have to as long as we're dealing with XML 1.0. In fact, I've already seen strong proponents of multiple, different ways of encoding fully labelled graphs into XML. But programmers would rather deal with application-domain constructions in more expressive data modelling systems (e.g., one that supports fully labelled graphs). No amount of XML-to-XML transformation and/or efficiency hacking is going to change this. It seems to me that one plausible way out of this conundrum is for the XML Schema WG to recognize (1) the need for schemas to be written in terms of more expressive data modelling systems, (2) the need to support a variety of encodings of those data models into XML, and (3) the need for a schema to describe a particular encoding (the one desired for the schema at hand) of the schema's data model into XML. 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 oren at capella.co.il Thu Feb 4 09:50:30 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:08:32 2004 Subject: Fw: Namespaces Message-ID: <007f01be5023$1a9d33a0$5402a8c0@oren.capella.co.il> OK, I see I'm totally lost here. Question: Is it possible to recast the namespace recommendation as a transformation from an XML tree with 'xmlns' attributes and '...:' prefixes into a tree which doesn't have them, but with modified element and attribute names, such that the semantics of the resulting tree under the rest of the relevant recommendations (ignoring namespaces) is preserved? One would of course have to pass the DTDs (or other schema files) through the same transformation. Note that this may require defining a textual form for the transformed tree (using "...^...", or "{..}..", or whatever). If so, then we'll have a clear definition of just how to add a namespace processor on top of a normal XML processor. The reverse transformation could be used for emitting XML trees. The rest of the XML standards could pretty much ignore namespaces altogether. The endless threads of "what are namespaces this week" would go away. Yes, I know, I'm dreaming (or raving :-) If this isn't possible, and from what I'm reading this seems a real possibility, then I'd like to know the details - in particular, I want to hear the advantages gained by this decision. Is it some attempt to mix together namespaces and other issues - such as mixed content, combining documents, extending DTDs, etc.? MVHO is that such issues should be solved separately of the unique naming issue, but I realize that the W3C has a tradition of mixing together issues which seem separate to me :-) James' document uses the transformation approach. It stops short of claiming the preservation of semantics. When I asked about a particular equivalence issue (relationship between an attribute name and an element name, given that none/one/both of them are expanded), he said: > I would prefer not to answer this since I don't think the XML Namespaces > Recommendation needs to take a position on this. All the Namespaces > Recommendation does is provide a mechanism which allows element type > names and attribute names to be qualified with a URI. How other > applications or specifications (such as RDF or XML Schemas) choose to > exploit this mechanism is up to them. > > However, if I was forced to answer, I would say that the relationship > was not the same. These two statements seem contradictory to me - if "all" the namespaces do is prefix the names with a URI, why should the relationship between expanded names be different then that between "normal" names? If this relationship is "application defined" for normal names (as James implies), then doesn't it remain "application defined" when the names are expanded? Anyway, how come it is "application dependent" - don't DTDs and schema language have a lot to say about it? My head is starting to ache. Way in over my head, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nate at valleytel.net Thu Feb 4 10:17:19 1999 From: nate at valleytel.net (Nathan Kurz) Date: Mon Jun 7 17:08:33 2004 Subject: A weaker XSL? In-Reply-To: <36B94536.2E9272C8@manhattanproject.com> from "Clark Evans" at Feb 04, 1999 06:59:02 AM Message-ID: <199902041016.EAA06857@trinkpad.valleytel.net> Clark Evans wrote: > DOM requires the entire stream be read before the > the document object is returned and processing can begin. > Not only does this chew significant memory for very large > streams, but it causes significant delay before output > could be generated. In the worst case, it turns a > perfectly simple problem into an "impossible" one > where the memory requirements and time delay make > the solution useless. Tyler Baker wrote: > In this case of XSL the spec enforces constraints which make it > impossible to be able to properly process an XML document unless it > has been fully parsed into an in-memory tree structure (for most > people this will be the DOM). I apologize for jumping into this so late, but these two statements have me a bit worried. Are the both true? I'm still in the XML fiddling around stage, but I've read both of the specs and didn't draw the same conclusions. I was hoping these specs allowed for more wriggle room than this. The first statement regarding the DOM model seems true word by word, but seems a bit misleading. First, couldn't a bit of judicious preprocessing allow some of those very large streams to be made into very small streams before the DOM model is built? The spec says that the DOM structure model is 'structurally isomorphic' to the document, but surely this document doesn't have to be a pre-existing XML file? Also, while the entire stream has to have been read, does it have to have already been processed? The way I was interpretting the spec, the DOM model didn't exclude a lazy processing method. So long as an implementation provides a compliant interface, can't it do anything it wants with the data, even so far as to put off processing information until it is requested? I had hoped for an extremely lazy DOM implementation that would maintain information about all but the root level nodes in a 'flat' unprocessed state a request for that information is made. For many cases (well, at least the ones I'm envisioning) such an implemention would be much more efficient than an entirely pre-processed one. Is this sort of implemention just right out of the question? As for the second statement (regarding XSL), could these constraints be more explicitly laid out? While I can see that arbitrary XSL might require a fully constructed tree, couldn't one come up with many cases where a partially constructed tree would be sufficient? For example, what if your style sheet had only the following template: <xsl:template match="/match"> Found a match! </xsl:template> Would one still have to fully construct your tree ahead of time? Hoping I'm not too far off base but half-expecting that I must be, nathan kurz nate@valleytel.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 Thu Feb 4 11:03:02 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:08:33 2004 Subject: A weaker XSL? Message-ID: <002401be502d$c0c1cf70$2ee044c6@arcot-main> >> DOM requires the entire stream be read before the >> the document object is returned and processing can begin. The DOM spec does NOT require the entire stream to be read before the document object is returned. Some of the DOM implementations available today does indeed process the entire stream before returning but that is a quality of implementation issue. 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 jjc at jclark.com Thu Feb 4 11:10:27 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:08:33 2004 Subject: Restricted Namespaces for XML References: <003101be5016$ad13c850$2ee044c6@arcot-main> Message-ID: <36B97B5E.9FF8B012@jclark.com> Don Park wrote: > If I read James Clark's message correctly, I believe he is in favor of > chopping out some features out of the "Namespaces for XML" I am in favour of chopping out some of the conceptual apparatus used to explain the features of "Namespaces for XML" not chopping out the features themselves. > All the namespace declarations must be at the root element and prefixes are > global to the document (well, within the root element). Although restricting namespace declarations to the root element makes it a little easier to do namespace processing on input, it makes things much harder on output if you want to generate a document that combines multiple XML input documents. For example, consider an XLink filter that resolves transclusions. This restriction would require that it read all the input XML documents completely before it could produce any output, because it would need to move the declarations of the prefixes on the transcluded document roots up to the root of the generated output document. I also doubt it would be any easier to understand: you're making a special case of the root element rather than treating all elements uniformly. I can't think of any feature in XML Namespaces that isn't really important for some significant application of XML Namespaces. I recommend reading http://www.w3.org/TR/NOTE-webarch-extlang for some background on the requirements that motivated the design of XML Namespaces. 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 rbourret at ito.tu-darmstadt.de Thu Feb 4 11:12:01 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:33 2004 Subject: Namespaces Message-ID: <01BE5036.8F0220D0@grappa.ito.tu-darmstadt.de> Oren Ben-Kiki wrote: > Is it possible to recast the namespace recommendation as a transformation > from an XML tree with 'xmlns' attributes and '...:' prefixes into a tree > which doesn't have them, but with modified element and attribute names, such > that the semantics of the resulting tree under the rest of the relevant > recommendations (ignoring namespaces) is preserved? One would of course have > to pass the DTDs (or other schema files) through the same transformation. This transformation is possible, but I don't think it buys you anything. If the transformation results in locally unique names, you break applications, since these can no longer recognize the locally unique names, which potentially change each time a document is processed. If it results in globally unique names, you could rewrite the applications to recognize these names, but you aren't really gaining anything over current namespace processing. > If this isn't possible, and from what I'm reading this seems a real > possibility, then I'd like to know the details - in particular, I want to > hear the advantages gained by this decision. Is it some attempt to mix > together namespaces and other issues - such as mixed content, combining > documents, extending DTDs, etc.? MVHO is that such issues should be solved > separately of the unique naming issue, but I realize that the W3C has a > tradition of mixing together issues which seem separate to me :-) Mixed content, combining documents, extending DTDs, etc. are not directly addressed by the namespaces spec, nor does the spec claim to solve them. They are closely tied because all of these need namespaces in order to be solved. This is generally where confusion in the namespaces spec comes from -- the hope that the namespaces spec directly addresses these issues and the confusion when the reader finally realizes that in "only" gives a syntax for a two-part naming system. > > However, if I was forced to answer, I would say that the relationship > > was not the same. For those of you who have forgotten the original question (I had to look it up), it essentially asks: Is the relationship between "good" and "a" the same in <good a="1"/> and <good foo:a="1"/>? > These two statements seem contradictory to me - if "all" the namespaces do > is prefix the names with a URI, why should the relationship between expanded > names be different then that between "normal" names? If this relationship is > "application defined" for normal names (as James implies), then doesn't it > remain "application defined" when the names are expanded? Anyway, how come > it is "application dependent" - don't DTDs and schema language have a lot to > say about it? Expansion has nothing to do with it. The namespaces spec introduces the concept of a "global" attribute, which doesn't exist in XML 1.0. (For a discussion of global attributes, see Andrew Layman's summary at http://www.lists.ic.ac.uk/hypermail/xml-dev/9902/0027.html.) You can tell which attributes are global and which are local by looking for prefixes: global attributes have a prefix and local attributes don't. Another characteristic is that global attributes are in a different (traditional) namespace than local attributes. That is, global attribute names must be unique among all global attribute names in the document, while local attribute names must be unique among all local attributes in each element. Because the (traditional) namespaces of local and global attributes do not overlap, so you can have a global attribute that has the same name as a local attribute. That is, the following is legal: <good a="1" foo:a="1"/> So, your question boils down to: "Is the relationship of good to a the same as the relationship of good to foo:a?" James rightly side-steps the question, because you are asking about the relationship between an element and two *different* attributes which *happen* to have the same name. This question has nothing to do with the namespaces spec (how the names of these attributes are expressed -- prefix form, Clark notation, etc. -- is irrelevant), but with the actual, application-defined semantics of the attributes. James then guesses that they are probably different and goes on to explain why. Does your head hurt any less now? -- 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 James.Anderson at mecomnet.de Thu Feb 4 11:15:28 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:33 2004 Subject: Fw: Namespaces References: <A26F84C9D8EDD111A102006097C4CD0D05494F@SOHOS002> <36B9302C.390A6F70@jclark.com> Message-ID: <36B981F0.D5546156@mecomnet.de> The confusion issues from the spec itself. In order to eliminate the origin of the problem, either (A) 1. the definition in section 1 is editied to delete the text: "XML namespaces differ from the "namespaces" conventionally used in computing disciplines in that the XML version has internal structure and is not, mathematically speaking, a set. These issues are discussed in 'A. The Internal Structure of XML Namespaces'. " 2. the first paragraph in 5.2 is modified to say "unprefixed attributes are in no namespace", or "unprefixed attributes are in the null namespace", or something of that order instead of (to the effect) merely "unprefixed attributes are not in the default namespace" 3. the caption to the second exmple in 5.3 is modified to make an analogous positive assertion rather than merely "the default namespace does not apply to attribute names". 4. appendix A is eliminated. or (B) 5. the passages noted in 2 and 3 above are edited to incorporate the "per element partition" terminology. 6. claims, that "in the sense the spec uses the word namespace, an unprefixed attribute is NOT IN ANY NAMESPACE", are abandoned. It simply doesn't work to have the text referred to in items 1 through 4 above present in the same specification. James Clark wrote: > > All this stuff about namespaces is just unnecessary, confusing > complexity that invites the over-analysis that is so prevalent in this > forum. If the spec was called something like "XML Universal Names" and > never mentioned the word "namespace" and didn't include Appendix A > (which thankfully is not normative), absolutely no functionality would > have been lost and I think there would have been far less confusion. We do agree on this last point. My very first notes about namespaces (I think it was likely almost a year ago) included a query as to why "per element partitions" for *names* were even necessary. We agree. They are not. It appears to the uninitiated, however, that the authors had cause to make distinctions among the *names* of unqualified attributes themselves. Which distinction the Appendix A text very clearly makes, and which the spec supports by reference. There have even been notes posted which led me to believe that this was intended to support certain XSL expressions. Which leads the uninitiated to believe there is cause to support this distinction in an implemented DOM. Should this not be the case, then the option (A) above should be pursued. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 11:56:46 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:33 2004 Subject: Fw: Namespaces In-Reply-To: <007f01be5023$1a9d33a0$5402a8c0@oren.capella.co.il> References: <007f01be5023$1a9d33a0$5402a8c0@oren.capella.co.il> Message-ID: <14009.34222.566591.606284@localhost.localdomain> Oren Ben-Kiki writes: > Question: > > Is it possible to recast the namespace recommendation as a > transformation from an XML tree with 'xmlns' attributes and '...:' > prefixes into a tree which doesn't have them, but with modified > element and attribute names, such that the semantics of the > resulting tree under the rest of the relevant recommendations > (ignoring namespaces) is preserved? Yes -- this is exactly how most people are already working with namespaces. It's a well-proven technique for working with architectural forms in SGML (except that architectural forms allow 0-n while namespaces allow exactly 1). > One would of course have to pass the DTDs (or other schema files) > through the same transformation. No -- the DTD disappears after the initial parse; it is used to validate the surface structure of the original document, but is not part of the transformation. The point, though, is that this transformation occurs only in memory (or in database) -- if you write it back out as XML, you have to shove prefixes back on again (they don't have to be the same, since the prefix is just fluff). > Note that this may require defining a textual form for the > transformed tree (using "...^...", or "{..}..", or whatever). That's one alternative; the other is to make names into the equivalent of public interface Name { public abstract String getURIPart (); public abstract String getLocalPart (); } Personally, I'm partial to using a simple string with the space character, as in "http://www.megginson.com/ns/ foo" Others have different preferences. Simple concatentation will not work, because {http://www.foo.com/foo}bar and {http://www.foo.com/}foobar would not be properly distinguished. > If so, then we'll have a clear definition of just how to add a > namespace processor on top of a normal XML processor. The reverse > transformation could be used for emitting XML trees. The rest of > the XML standards could pretty much ignore namespaces > altogether. The endless threads of "what are namespaces this week" > would go away. Yes, I know, I'm dreaming (or raving :-) No, you're awake, and you're right -- it's *really* that easy. I imagine that Tim Bray is probably slapping his forehead right now yelling "DUH!", and that James Clark is probably doing whatever the polite English equivalent is. 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 jjc at jclark.com Thu Feb 4 12:21:28 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:08:33 2004 Subject: Fw: Namespaces References: <007f01be5023$1a9d33a0$5402a8c0@oren.capella.co.il> Message-ID: <36B987C3.D79BEFF1@jclark.com> Oren Ben-Kiki wrote: > Is it possible to recast the namespace recommendation as a transformation > from an XML tree with 'xmlns' attributes and '...:' prefixes into a tree > which doesn't have them, but with modified element and attribute names, Yes. The transformation changes some element type names and attribute names from strings to structured objects that contain a URI and a string. There are some subtleties (an XML editor would probably want to be able to preserve prefixes; some applications need to now what namespace prefix bindings are in effect on a particular element) but these can be handled within this approach. > such > that the semantics of the resulting tree under the rest of the relevant > recommendations (ignoring namespaces) is preserved? I don't understand what you mean by "preserving semantics". > One would of course have > to pass the DTDs (or other schema files) through the same transformation. Why? DTDs are used only at the pre-transformation stage. I would expect a future XML Schema language to operate purely on the post-transformation tree. > if "all" the namespaces do > is prefix the names with a URI, Qualify not prefix. A URI-qualified name is not a string but a URI/string pair. > why should the relationship between expanded > names be different then that between "normal" names? Because it's URI-qualified and therefore capable of independent interpretation. A URI-qualified name is a different kind of object from a "normal" name. > Anyway, how come > it is "application dependent" I said it was dependent on other applications *or other specifications*. > don't DTDs and schema language have a lot to > say about it? DTDs don't have anything to say about it because they don't know about namespaces. I would expect a namespace-aware Schema language to have a lot to say about it. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 12:21:35 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:33 2004 Subject: Restricted Namespaces for XML Message-ID: <01BE5040.5CB976A0@grappa.ito.tu-darmstadt.de> Don Park wrote: > Such a spec might dictate that all namespace declarations be at the root > element (XML fragments are problematic but...). This restriction has the > side effect of not allowing duplicate prefixes. The major benefit of this proposal is that it reduces the number of checks for xmlns attributes. This savings is minimal in small documents or documents with few attributes, but it would be interesting to know how much xmlns attribute processing costs in a large, attribute-intensive document. I think readability is a wash, as you can't do anything more with this than you can with the current proposal and you lose the ability to have multiple default namespaces, which are useful in documents that have long sections alternating between two or more namespaces. I think the biggest problem is, as James Clark noted elsewhere, complication of fragmentation. Since I believe fragments to be a big part of the future, I don't like anything that will make them harder. That said, if anybody had some real numbers about what xmlns attribute processing costs in the worst case and this turned out to be significant, it might be useful to have a PI that tells the namespace processor whether it needs to look beyond the root element. -- 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 donpark at quake.net Thu Feb 4 13:10:32 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:08:33 2004 Subject: Restricted Namespaces for XML Message-ID: <003d01be503f$5448ee20$2ee044c6@arcot-main> >I am in favour of chopping out some of the conceptual apparatus used to >explain the features of "Namespaces for XML" not chopping out the >features themselves. I appologize for misrepresenting your position. >Although restricting namespace declarations to the root element makes it >a little easier to do namespace processing on input, it makes things >much harder on output if you want to generate a document that combines >multiple XML input documents. For example, consider an XLink filter >that resolves transclusions. This restriction would require that it >read all the input XML documents completely before it could produce any >output, because it would need to move the declarations of the prefixes >on the transcluded document roots up to the root of the generated output >document. I also doubt it would be any easier to understand: you're >making a special case of the root element rather than treating all >elements uniformly. You are right, of course, if usage of well-formed external entity is not allowed. I was not proposing that RNX replace the Namespace spec. I was trying to see there was a need for a strict subset of the Namespace spec which can not handle some of the problems but is functional enough for most problems. RNX software is easier to write because there is not much to get confused about. >I can't think of any feature in XML Namespaces that isn't really >important for some significant application of XML Namespaces. > >I recommend reading > > http://www.w3.org/TR/NOTE-webarch-extlang > >for some background on the requirements that motivated the design of XML >Namespaces. Thanks for the link. Thanks, 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 shecter at darmstadt.gmd.de Thu Feb 4 13:27:31 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:33 2004 Subject: Component Markup Language Message-ID: <4EB3E7E7.1B5AD737@darmstadt.gmd.de> Hi, Has anyone thought about or worked on an markup language to describe a User Interface in a platform independent way? I'd think that this would language would describe: instantiating components, adding them to containers, and configuring interactions between them. Thanks, - 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 Matthew.Sergeant at eml.ericsson.se Thu Feb 4 13:36:33 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:33 2004 Subject: Component Markup Language Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AF0@eukbant101.ericsson.se> > -----Original Message----- > From: Robb Shecter [SMTP:shecter@darmstadt.gmd.de] > > Hi, > > Has anyone thought about or worked on an markup language to describe a > User Interface in a platform independent way? > > I'd think that this would language would describe: instantiating > components, adding them to containers, and configuring interactions > between them. > Two projects I know of: XUL from mozilla.org - lots of details on their web site, and XGTK - an XML interface definition for GTK that uses Perl to create applications. The latter is in alpha stage and only available via CVS from gnome.org, but looks like an interesting project for perl developers. XUL looks like it will be very powerful too, and allows the control of events in Javascript. 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 prb at uic.edu Thu Feb 4 13:43:50 1999 From: prb at uic.edu (Paul R. Brown) Date: Mon Jun 7 17:08:33 2004 Subject: Component Markup Language Message-ID: <010101be5043$b5c24030$9209f880@razzmatazz.math.uic.edu> >Has anyone thought about or worked on an markup language to describe a >User Interface in a platform independent way? It's not a markup language (or a subset of SGML), but python does a reasonably good job of providing platform-independent UI. - Paul xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From AOgan at us.lhsgroup.com Thu Feb 4 13:50:58 1999 From: AOgan at us.lhsgroup.com (Ogan, Arif) Date: Mon Jun 7 17:08:33 2004 Subject: Component Markup Language Message-ID: <6030DEFB8E88D211903300805F57D1463F8B60@excatl01.us.lhsgroup.com> Check out http://www.bluestone.com/xml/XwingML/ Arif ---------- From: Robb Shecter [SMTP:shecter@darmstadt.gmd.de] Sent: Friday, November 04, 2011 8:26 AM To: xml-dev@ic.ac.uk Subject: Component Markup Language Hi, Has anyone thought about or worked on an markup language to describe a User Interface in a platform independent way? I'd think that this would language would describe: instantiating components, adding them to containers, and configuring interactions between them. Thanks, - Robb xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Thu Feb 4 14:08:51 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:33 2004 Subject: Component Markup Language In-Reply-To: <6030DEFB8E88D211903300805F57D1463F8B60@excatl01.us.lhsgrou p.com> Message-ID: <3.0.6.32.19990204061222.00f1de60@scripting.com> http://www.bluestone.com/xml/XwingML/ Yes, that is very interesting. But if anyone from Bluestone is listening, it would be great to have a page that shows XML code and a screen shot of the interface it generates. Four or five such examples, visible to someone who doesn't use their tool, would be very instructive and would help their cause immeasurably. 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.Kay at icl.com Thu Feb 4 14:14:22 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:33 2004 Subject: A weaker XSL? Message-ID: <93CB64052F94D211BC5D0010A80013310EB2D8@WWMESS3> > Is there a possibility for creating a sub-set of > XSL that would work on a stream instead of > requiring a complete document object? Funny you should ask that, I've been experimenting over the last few days to see whether I could build such a thing on top of SAXON. Not actually easy to do as a pure subset, but I think one can do something that feels quite XSL-like. 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 bckman at ix.netcom.com Thu Feb 4 14:14:32 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:33 2004 Subject: Component Markup Language Message-ID: <009001be5048$3508f740$a7addccf@ix.netcom.com> The W3C HTML WG is currently working on converting HTML from an SGML application to an XML based application, and will be redesigning the DTD's so that they can be modularized. These modules can then be combined into various profiles which can include user-defined modules. Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (March) ----- Original Message ----- From: Robb Shecter <shecter@darmstadt.gmd.de> To: <xml-dev@ic.ac.uk> Sent: Friday, November 04, 2011 8:25 AM Subject: Component Markup Language >Hi, > >Has anyone thought about or worked on an markup language to describe a >User Interface in a platform independent way? > >I'd think that this would language would describe: instantiating >components, adding them to containers, and configuring interactions >between them. > >Thanks, >- Robb > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Feb 4 14:15:07 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:34 2004 Subject: COBOL XML parser? Message-ID: <199902041412.JAA10888@hesketh.net> Every month or so I get a ping from a reader asking about parsers in various languages outside the holy quadrilateral of Java, C/C++, Perl, and Python. So far I've had three COBOLs and a FORTRAN. Does anyone know of parsers (or parser-like projects) in these languages? I know there's a Delphi parser out there, so my old friend Pascal is in the loop, as well as JavaScript and I think even VB, but how about: * COBOL * FORTRAN * Ada * Lisp * Smalltalk I know Unicode and other issues may cause some big problems for the construction of a 'true' parser in most of these, but I'd love to hear it if anyone's tried. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 pierlou at CAM.ORG Thu Feb 4 14:30:33 1999 From: pierlou at CAM.ORG (Pierre Morel) Date: Mon Jun 7 17:08:34 2004 Subject: Component Markup Language Message-ID: <003c01be504a$702864d0$02dcdcdc@pierre> Hi, I work on a project like that for a while, look at : http://www.pierlou.com/prototype Pierre Morel ----- Original Message ----- From: Robb Shecter <shecter@darmstadt.gmd.de> To: <xml-dev@ic.ac.uk> Sent: 4 novembre, 2011 08:25 Subject: Component Markup Language >Hi, > >Has anyone thought about or worked on an markup language to describe a >User Interface in a platform independent way? > >I'd think that this would language would describe: instantiating >components, adding them to containers, and configuring interactions >between them. > >Thanks, >- 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 Mark.Birbeck at iedigital.net Thu Feb 4 14:47:38 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:34 2004 Subject: Component Markup Language Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054959@SOHOS002> > >Has anyone thought about or worked on an markup language to > describe a > >User Interface in a platform independent way? I had this idea for one called HTML but abandoned it because I thought it probably wouldn't catch on. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 shecter at darmstadt.gmd.de Thu Feb 4 14:49:04 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:34 2004 Subject: COBOL XML parser? References: <199902041412.JAA10888@hesketh.net> Message-ID: <4EB3FABA.80F5A127@darmstadt.gmd.de> "Simon St.Laurent" wrote: > > > * Smalltalk > I've been looking for Smalltalk parsers for a while, and the only one I've ever seen a pointer to is at: http://www.indelv.com/ Some caveats: Not validating. Nowhere near as well documented as something like Java ProjectX or IBM's Parser. The company itself seems to advise using their Java parser instead of the Smalltalk version. Only works in two Smalltalk vendors' platforms: VW and IBM. This is too bad - I'd think that doing something like manipulating a DOM could be much more pleasant in Smalltalk than in Java. I still haven't seen any pointers for anything like an XSL parser for Smalltalk. - 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 oren at capella.co.il Thu Feb 4 15:13:18 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:08:34 2004 Subject: Fw: Namespaces Message-ID: <002701be5050$1b09deb0$5402a8c0@oren.capella.co.il> I asked: >> Is it possible to recast the namespace recommendation as a transformation >> from an XML tree with 'xmlns' attributes and '...:' prefixes into a tree >> which doesn't have them, but with modified element and attribute names, >such >> that the semantics of the resulting tree under the rest of the relevant >> recommendations (ignoring namespaces) is preserved? One would of course >have >> to pass the DTDs (or other schema files) through the same transformation. And got - self contradictory responeses! For example: Ronald Bourret <rbourret@ito.tu-darmstadt.de> wrote: > This transformation is possible, but I don't think it buys you anything. Except compatibility with current APIs - the ability to add a namespace processor on top of SAX, say, _without changing the interface_. But let this slide... >For those of you who have forgotten the original question (I had to look it >up), it essentially asks: > >Is the relationship between "good" and "a" the same in <good a="1"/> and ><good foo:a="1"/>? > >Expansion has nothing to do with it. Which is contradicted by the very next sentence: >The namespaces spec introduces the >concept of a "global" attribute, which doesn't exist in XML 1.0. AHA! So the namespaces proposal _DOES_ go beyond simply qualifying names with URIs! Which means I _CAN NOT_ transform an XML document with namespaces into a document without namespaces (but with extended names) and achieve the same semantics. Let me clarify what I mean by that: Suppose I have an XML processing system, with some XML input files (including DTDs, schema definition files, input files, stylesheet files, whatever). Let us assume that they (or some of them) use namespaces as per the current draft. I run the system and get certain effects, including possibly some output files which again may use namespaces. Now, I transform all the input files to stop using namespaces. Instead I transform them to something like James' extended names format. I hack the XML system to _not_ do namespace processing, if necessary, and re-run it on the input files. I'd expect the effects to be identical and the XML output files to be the same the original run's output files, after compatible name extension. If this were to hold, namespaces would have been simple, and truly orthogonal to all the other standards. "This turns out not to be the case", but I can't get anyone to admit it - so I can't get a straight answer to _why_ this isn't the case. Why is this impossible? Because "prefixed attributes are global". The XML system handles them differently based on the fact they are _prefixed by a namespace_. In the second run _no_ attribute is prefixed. Note that the _uniqueness_ of the names wan't hurt; "foo:a", "a" and "bar:a" are still different. It is just that none of them are "namespaced". >(For a >discussion of global attributes, see Andrew Layman's summary at >http://www.lists.ic.ac.uk/hypermail/xml-dev/9902/0027.html.) I re-checked this and as far as I understand Andrew makes a pretty good case that there is no such thing as a global attribute - at least, in DTDs there isn't. Now, if global attributes are necessary, or all attributes should be global, or whatever, is something I'd be happy to see discussed. But why does this have to be dragged into the namespace issue? Why isn't it defined so it would survive the transformation I described above? Move this "global attribute" business to the DTD or Schema WG where it belongs! >You can tell which attributes are global and which are local by looking for >prefixes: global attributes have a prefix and local attributes don't. That's one answer - a way to know which is which without looking at a DTD. IMVHO, this isn't worth the price. Look at the amount of misunderstanding this caused! Not to mention the implementation issues - without being able to do the transformation I described above, all the XML APIs have to be reworked, and so on... No namespace unaware application will be able to survive the transfer to the namespace-aware world. Surely there's a better reason for such a profound decision? >So, your question boils down to: "Is the relationship of good to a the same >as the relationship of good to foo:a?" James rightly side-steps the >question, because you are asking about the relationship between an element >and two *different* attributes which *happen* to have the same name. No. First, "a" and "foo:a" are _not_ the same name. Second, it would have been the same question if I used "a" and "foo:b". I now understand that the latter is "global" and therefore these relationships are _not_ identical. I still reeling from the shock. > This question has nothing to do with the namespaces spec (how the names of these >attributes are expressed -- prefix form, Clark notation, etc. -- is >irrelevant) <censored/> How can you say that this has nothing to do with the namespaces spec when it is (i) introduced in this very spec and (ii) relies on the attribute having a namespace prefix in order to declare it as global? >Does your head hurt any less now? Just about to bust at the seams, thanks :-) Even James, which normally admirably clears things up in one or two well-designed sentences, left me confused. To my original question (is it possible to do a transformation...) he answered: > Yes. The transformation changes some element type names and attribute > names from strings to structured objects that contain a URI and a > string. Which is _not_ what I had in mind - I was specifically referring to a _textual representation valid under the non-namespaced XML-1.0 spec_. But since one can convert qualified names to text - he has given a sample in his paper, after all - lets continue... >> such >> that the semantics of the resulting tree under the rest of the relevant >> recommendations (ignoring namespaces) is preserved? >I don't understand what you mean by "preserving semantics". In the sense of equivalence I defined above. That is, namespace-semantics(XML) == non-namespace-semantics(extended-names(XML)). >> One would of course have >> to pass the DTDs (or other schema files) through the same transformation. > Why? DTDs are used only at the pre-transformation stage. WHAT? How can DTDs be pre-transformation? If a DTD refers to 'foo:a', where 'xmlns:foo="my:uri"', and my document contains 'bar:a', where 'xmlns:bar="my:uri"', it won't match since 'foo' != 'bar'? Surely I misunderstand? >I would expect >a future XML Schema language to operate purely on the >post-transformation tree. Well, that helps a bit, though I don't see why existing languages can't share the privilege... >> if "all" the namespaces do >> is prefix the names with a URI, >Qualify not prefix. A URI-qualified name is not a string but a >URI/string pair. Fine. I'm still trying to see how can one say that "all" namespaces do is "qualify names" - which with appropriate textual representation can become "prefix the names" - and still say that they introduce global attributes: >> why should the relationship between expanded >> names be different then that between "normal" names? >Because it's URI-qualified and therefore capable of independent >interpretation. A URI-qualified name is a different kind of object from >a "normal" name. Hardly a sufficient answer. What is the _benefit_ of distinguishing between the two? As opposed of declaring global attributes in a DTD, or whatever? >> Anyway, how come >> it is "application dependent" >I said it was dependent on other applications *or other specifications*. Whatever. I still don't see what applications have to do with it. _From the XML standard point of view_, there's a certain relationship between attributes and elements. This relationship might well be "the application may do anything it wants". With regard to URI-prefixed attributes, the namespaces XML makes it clear that this relationship is _not_ the same as that for unprefixed attributes. Now how much sense is in that, if both relationships are "the application can do whatever it wants"? >> don't DTDs and schema language have a lot to >> say about it? >DTDs don't have anything to say about it because they don't know about >namespaces. I would expect a namespace-aware Schema language to have a >lot to say about it. Why should the DTD spec be "namespace aware" if the transformation I asked about exists? Shouldn't I simply transform both the DTD and the document, then check validity? For that matter, why should _any_ XML standard be "namespace aware" - couldn't the same apply to them all? I can see how namespace patterns might be useful in XSL, but that's a rather exceptional case. Why wasn't the DTD spec extended to handle global attributes (regardless of namespace issues) instead of sneaking them in the namespace spec? Global attributes make the same amount of sense for non-prefixed attributes within a single XML language. This is the root of the problems here - _what is the benefit gained from placing this in the namespace spec_? Is there one? Is it worth it? Can we revoke it? Again, I could be very wrong here - when it seems to me everyone else is contradicting himself, it is high time for a reality check. Help? Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Feb 4 15:15:07 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:34 2004 Subject: Schema Processing (was Re: Fw: Namespaces) In-Reply-To: <36B987C3.D79BEFF1@jclark.com> References: <007f01be5023$1a9d33a0$5402a8c0@oren.capella.co.il> Message-ID: <199902041514.KAA11880@hesketh.net> At 06:42 PM 2/4/99 +0700, James Clark wrote: >> One would of course have >> to pass the DTDs (or other schema files) through the same transformation. > >Why? DTDs are used only at the pre-transformation stage. I would expect >a future XML Schema language to operate purely on the >post-transformation tree. This opens up a new can of worms, one we discussed during the creation of XSchema (now DDML), but potentially an ugly one long term. This paragraph suggests a process like: 1. Process document against DTD. 2. Resolve namespaces. 3. Process document against schema. Which is fine, in some ways - I'd prefer to see schemas just define structures, not content substitution (i.e., entities) - but opens up potentially potent new layers of complexity that make the current mire of well-formed and valid documents seem quite friendly. Is the W3C ever going to take a look at making its specs into neat layers instead of octopuses that sprawl across multiple levels of processing? Namespaces wraps its tentacles around several parts of XML 1.0, and duplication between schemas and DTDs may leave another generation of would-be XML-ers scratching their heads at the odd ways of those sophisticated folks writing the specs. Linking and styling present similar delightful conundrums, and there's a fairly large group of voices (mine included) on the XSL list calling for that spec to be cleanly split into two pieces: transformation and formatting. I'd rather have more small clean pieces that fit together neatly than large chunks that need to wrap around each other to work properly. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 shecter at darmstadt.gmd.de Thu Feb 4 15:30:52 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:34 2004 Subject: Component Markup Language References: <3.0.6.32.19990204061222.00f1de60@scripting.com> Message-ID: <4EB404D1.E327D32F@darmstadt.gmd.de> Dave Winer wrote: > http://www.bluestone.com/xml/XwingML/ > > Yes, that is very interesting. But if anyone from Bluestone is listening, > it would be great to have a page that shows XML code and a screen shot of > the interface it generates. Well, I just downloaded it and checked it out, and I don't think this could really be used as a way to describe platform-independent UI's. (Can I attach a copy of an XML here w/out violating some copyright? Hmm...maybe a piece of it... :) <JFrame name="MainFrame" title="Bluestone XML Notepad" image="icon.gif" x="20%" y="20%" width="60%" height="60%"> <JMenuBar> <JMenu text="File" mnemonic="F"> <JMenuItem icon="open.gif" text="Open..." mnemonic="O" accelerator="VK_O,CTRL_MASK" actionListener="OpenFile"/> etc... This looks basically like Java code with an XML syntax. It doesn't abstract at the nature of components, or interactions. I guess what it is, is one way to get a scripting functionality in Java; a competitor to projects like the BeanShell. - 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 shecter at darmstadt.gmd.de Thu Feb 4 15:39:42 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:34 2004 Subject: Component Markup Language References: <010101be5043$b5c24030$9209f880@razzmatazz.math.uic.edu> Message-ID: <4EB406E9.D2D8D084@darmstadt.gmd.de> "Paul R. Brown" wrote: > >Has anyone thought about or worked on an markup language to describe a > >User Interface in a platform independent way? > > It's not a markup language (or a subset of SGML), but python does a > reasonably good job of providing platform-independent UI. > Hi, Yes, that's definitely something else that I'm checking out: Several languages have abstracted ui widgets and interactions in platform independent ways: Java, Smalltalk, Python and tcl/tk come to mind. I can imagine using one of these either directly, or more likely, basing an XML language on a model that one of these languages have developed. For example, a piece of XML that uses the Java-style interaction model could look like: <UI> <BasicWidget id="1" x="100" y="100" height="50" width="50" type="TextEntryField"> <KeyPressListener name="2"> <KeyPressListener name="3"> <KeyPressListener name="4"> </BasicWidget> etc... - Robb xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Feb 4 15:47:45 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:34 2004 Subject: Namespaces does *not* formally introduce "global attributes" In-Reply-To: <002701be5050$1b09deb0$5402a8c0@oren.capella.co.il> References: <002701be5050$1b09deb0$5402a8c0@oren.capella.co.il> Message-ID: <14009.48512.126069.745770@localhost.localdomain> Oren Ben-Kiki writes: > >The namespaces spec introduces the concept of a "global" > >attribute, which doesn't exist in XML 1.0. > > AHA! So the namespaces proposal _DOES_ go beyond simply qualifying > names with URIs! No it doesn't. The comment to which Oren is replying contains a common (but understandable) mistake. The normative part of the Namespaces spec does *not* mention global attributes at all, so formally, they are not part of the namespaces specification. Non-normative appendix A.1 mentions "global attributes" descriptively, as a commonly-observed design pattern in SGML/XML documents. It's up to the Schema WG (and other schema standard creators) to decide whether there is such a thing as formal global attributes and if so, how they should work. The source of the misreading is the unfortunately obfuscatory appendix A.2, which in general has caused an immense amount of unnecessary confusion among implementors -- fortunately, A.2 is also non-normative, so you're free to ignore it (I always have, and I highly recommend doing so). I will recommend dropping A.2 in future drafts. In any case, what does all this have to do with transformation? 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 peter at weblogic.com Thu Feb 4 16:08:50 1999 From: peter at weblogic.com (Peter Seibel) Date: Mon Jun 7 17:08:34 2004 Subject: A weaker XSL? In-Reply-To: <93CB64052F94D211BC5D0010A80013310EB2D8@WWMESS3> Message-ID: <19990204161626993.AAA218@ashbury.weblogic.com@lawton> At 05:17 AM 2/4/99 , Michael.Kay@icl.com wrote: >> Is there a possibility for creating a sub-set of >> XSL that would work on a stream instead of >> requiring a complete document object? > >Funny you should ask that, I've been experimenting over the last few days to >see whether I could build such a thing on top of SAXON. Not actually easy to >do as a pure subset, but I think one can do something that feels quite >XSL-like. So I obviously lack imagination or understanding of all the intricacies of XSL -- what can you express in XSL that you couldn't implement on top of SAX? -Peter -- Peter Seibel Perl/Java/English Hacker peter@weblogic.com Is Windows98 Y2K compliant? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nwoh at software-ag.de Thu Feb 4 16:27:57 1999 From: nwoh at software-ag.de (Nigel Hutchison) Date: Mon Jun 7 17:08:34 2004 Subject: Component Markup Language In-Reply-To: <4EB404D1.E327D32F@darmstadt.gmd.de> References: <3.0.6.32.19990204061222.00f1de60@scripting.com> Message-ID: <3.0.6.32.19990204172738.00bfbec0@daemsg01> At 04:29 PM 11/4/11 +0100, Robb Shecter wrote: >Dave Winer wrote: > >> http://www.bluestone.com/xml/XwingML/ >> >> Yes, that is very interesting. But if anyone from Bluestone is listening, >> it would be great to have a page that shows XML code and a screen shot of >> the interface it generates. > >Well, I just downloaded it and checked it out, and I don't think this could really be used as >a way to describe platform-independent UI's. (Can I attach a copy of an XML here w/out >violating some copyright? Hmm...maybe a piece of it... :) > > <JFrame name="MainFrame" title="Bluestone XML Notepad" image="icon.gif" x="20%" y="20%" >width="60%" height="60%"> > <JMenuBar> > <JMenu text="File" mnemonic="F"> > <JMenuItem icon="open.gif" text="Open..." mnemonic="O" >accelerator="VK_O,CTRL_MASK" actionListener="OpenFile"/> > >etc... > >This looks basically like Java code with an XML syntax. It doesn't abstract at the nature of >components, or interactions. I guess what it is, is one way to get a scripting functionality >in Java; a competitor to projects like the BeanShell. If there was a set of C++ classes that interpreted it and built up a GUI with the same look and feel, that might be useful. Then a server could project its own GUI api and leave it to the client side to choose C++, Java etc to build the interface at run time. I suspect that in most cases the bandwidth required to shift the XML GUI description would be quite a bit less than the compiled java classes. If this is so than "Even Cooler" would be XML GUI interpreter built into a Internet Browser. But am I running too far with this one? Nigel Hutchison Nigel W. O. Hutchison Technical Consultant Software AG Germany mailto:nwoh@software-ag.de Tel +49 (0)6151 92 1207 * xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 16:39:14 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:34 2004 Subject: Component Markup Language Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AF3@eukbant101.ericsson.se> > -----Original Message----- > From: Nigel Hutchison [SMTP:nwoh@software-ag.de] > [snip] > Then a server could project its own GUI api and leave it to the client > side > to choose C++, Java etc to build the interface at run time. I suspect > that > in most cases the bandwidth required to shift the XML GUI description > would > be quite a bit less than the > compiled java classes. If this is so than "Even Cooler" would be XML GUI > interpreter built into a Internet Browser. > > But am I running too far with this one? > Not at all - that's exactly the aim of XUL, part of the Mozilla project. I suspect that once mozilla is stable and released we are going to see some really awsome GUI's built using XUL. As a proof of concept, the UI for mozilla is now built using XUL. 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 CBenedet at Bluestone.com Thu Feb 4 16:45:02 1999 From: CBenedet at Bluestone.com (Benedetto, Christopher) Date: Mon Jun 7 17:08:34 2004 Subject: Component Markup Language Message-ID: <9A4DF69E3C5ED211B86400A0C9D1776084720D@thor.operations.bluestone.com> Dave - Thanks for the feedback on XwingML. We are in the process of posting screen grabs to the XwingML website located at (http://www.bluestone.com/xml/XwingML/); these should be available tomorrow. We are also working on more demos that we will post to the XwingML talk list (see below). If you want to see and share more code examples than are included withthe download please register to participate on our XwingML listserv by sending a message to listserv@bluestone.com with the following message in the body of the email "subscribe xwingml-talk". Since XwingML is open-source we would encourage you to make appropriate changes and additions - and submit it back to the xwingml-talk list. In addition to XwingML, we have announced Bluestone's XML-Server, the first generally available Dynamic XML Server and Bluestone Visual-XML, a developer's toolkit (Beta available March, 1999) to help companies build XML-based applications. Information about these (commercially available) tools can be found at (http://www.bluestone.com/xml). ============================================ Christopher Benedetto Product Manager Phone: (609) 727-4600 ext. 3024 Fax: (609) 727-5077 Bluestone Software, Inc. 1000 Briggs Road Mt. Laurel, NJ 08054 mailto:cbenedet@bluestone.com http://www.bluestone.com ============================================ -----Original Message----- From: Dave Winer [mailto:dave@userland.com] Sent: Thursday, February 04, 1999 9:12 AM To: xml-dev@ic.ac.uk Subject: RE: Component Markup Language http://www.bluestone.com/xml/XwingML/ Yes, that is very interesting. But if anyone from Bluestone is listening, it would be great to have a page that shows XML code and a screen shot of the interface it generates. Four or five such examples, visible to someone who doesn't use their tool, would be very instructive and would help their cause immeasurably. 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 b.laforge at jxml.com Thu Feb 4 16:46:23 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:35 2004 Subject: Component Markup Language Message-ID: <000f01be505d$1c834c60$c9a8a8c0@thing2> This all makes me wish I were working on Coins instead of MDSAX. I really think what we want is a meta language (in XML, of course!) which governs the mapping between an application document and the GUI components. This is what the spec for coins 4 was all about. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Thu Feb 4 16:53:26 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:35 2004 Subject: Namespaces does *not* formally introduce "global attributes" Message-ID: <01BE5066.010F2A90@grappa.ito.tu-darmstadt.de> David Megginson wrote: > > AHA! So the namespaces proposal _DOES_ go beyond simply qualifying > > names with URIs! > > No it doesn't. Mea culpa. David is right. Global attributes are no longer a normative part of the spec. The namespaces spec says the following about non-xmlns attributes: a) They can be prefixed or unprefixed b) The default namespace does not apply to unprefixed attributes c) Applications should use the namespace name, not the prefix, in constructing qualified names d) No tag can contain two attributes whose names are identical or whose names resolve to the same qualified name; this clarifies what is meant by "name" in the Unique Att Spec validity constraint in XML It does not tell us: e) What the difference is between prefixed and unprefixed attribute names (other than the existence of the prefix) -- that is, the semantic difference (if any) between prefixed and unprefixed attributes f) How to process prefixed or unprefixed attributes, except as noted in (c) Two further comments: 1) Tim Bray's statement that unprefixed attributes do not belong to an XML namespace derives from (b). Since there is no prefix to associate them with an XML namespace, and we can't the default XML namespace doesn't apply, there is simply no association. However, as A.2 points out, many applications are likely to use traditional, per-element namespaces for unprefixed attributes. Note that these are a consequence of the Unique Att Spec validity constraint in the XML spec, not anything in the namespaces spec. 2) As far as I can tell, there is nothing in the normative part of the spec that would lead us to conclude the existence of a global attribute partition that is separate from the per-element-type partitions, as is described in A.2. That is, the namespaces spec gives us no reason to believe that ns:a attributes in the following elements are in any way related, any more than the b attributes are related: <foo ns:a="1" b="1"/> <bar ns:a="1" b="1"/> Is this correct? -- 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 shecter at darmstadt.gmd.de Thu Feb 4 16:56:09 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:35 2004 Subject: Component Markup Language References: <3.0.6.32.19990204061222.00f1de60@scripting.com> <3.0.6.32.19990204172738.00bfbec0@daemsg01> Message-ID: <4EB4181A.99BB7C0@darmstadt.gmd.de> Nigel Hutchison wrote: > Then a server could project its own GUI api and leave it to the client side > to choose C++, Java etc to build the interface at run time. Yes. > I suspect that > in most cases the bandwidth required to shift the XML GUI description would > be quite a bit less than the > compiled java classes. If this is so than "Even Cooler" would be XML GUI > interpreter built into a Internet Browser. How about this: Have one XSL document per client side scripting language. That is, different XSL documents could implement: Component-XML->DHTML (This particular one would give you your "Even Cooler" idea.) Component-XML->Java BeanShell Component-XML->Smalltalk etc... ...then, a client side browser applies whatever XSL template is best for it, gets the the resulting kind of script it understands, and on the fly generates a UI. - 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 Mark.Birbeck at iedigital.net Thu Feb 4 16:57:13 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:35 2004 Subject: Component Markup Language Message-ID: <A26F84C9D8EDD111A102006097C4CD0D05495C@SOHOS002> Nigel Hutchison wrote: > If there was a set of C++ classes that interpreted it and > built up a GUI > with the same look and feel, that might be useful. > Then a server could project its own GUI api and leave it to > the client side > to choose C++, Java etc to build the interface at run time. > I suspect that > in most cases the bandwidth required to shift the XML GUI > description would > be quite a bit less than the > compiled java classes. If this is so than "Even Cooler" would > be XML GUI > interpreter built into a Internet Browser. > > But am I running too far with this one? Great idea. Can I suggest we call it HTML? (OK I know I've cracked that one already - it's the end of the week. But really, if you want an XML specification for a user interface, surely HTML 4.0 is the one to choose. Then you could use a 'cool browser' that has an "XML GUI Interpreter" built in - like, well, IE4 and Netscape 4.) Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 dave at userland.com Thu Feb 4 17:12:31 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:35 2004 Subject: Component Markup Language In-Reply-To: <9A4DF69E3C5ED211B86400A0C9D1776084720D@thor.operations.blu estone.com> Message-ID: <3.0.6.32.19990204091358.00f17c10@scripting.com> >>In addition to XwingML, we have announced Bluestone's XML-Server, the first generally available Dynamic XML Server I would like to know what this means. I am concerned that you're blowing right by our product, and that would not be appreciated. How is your XML server different from Frontier 5.1? 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 Matthew.Sergeant at eml.ericsson.se Thu Feb 4 17:20:12 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:35 2004 Subject: Component Markup Language Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AF4@eukbant101.ericsson.se> > -----Original Message----- > From: Mark Birbeck [SMTP:Mark.Birbeck@iedigital.net] > > Great idea. Can I suggest we call it HTML? > > (OK I know I've cracked that one already - it's the end of the week. But > really, if you want an XML specification for a user interface, surely > HTML 4.0 is the one to choose. Then you could use a 'cool browser' that > has an "XML GUI Interpreter" built in - like, well, IE4 and Netscape 4.) > HTML 4 isn't quite up to providing a full GUI, even with the DOM. For example you can't do menu's. You can't do buttons with images on them (I'm not talking about images that are buttons), you can't do tabbed dialogs (well, you can, but it's non-trivial), I'm sure there are other things. Of course you could add these things into HTML 5, but I don't think it's worth going down that road. Matt. -- http://come.to/fastnet Perl on Win32, PerlScript, ASP, Database, XML GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V !PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ 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 shecter at darmstadt.gmd.de Thu Feb 4 17:29:16 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:35 2004 Subject: Component Markup Language References: <A26F84C9D8EDD111A102006097C4CD0D05495C@SOHOS002> Message-ID: <4EB4208B.E26E66ED@darmstadt.gmd.de> Mark Birbeck wrote: > (OK I know I've cracked that one already - it's the end of the week. But > really, if you want an XML specification for a user interface, surely > HTML 4.0 is the one to choose. Then you could use a 'cool browser' that > has an "XML GUI Interpreter" built in - like, well, IE4 and Netscape 4.) Hi, (I found the "HTML" comment very funny, btw. :) I'm thinking of something much more heavy-duty. Like, I want to support a complex user interface that has many complex widgets, with flexible event wiring, that must make accesses to back end data. Something like the UI for a Bloomberg Box, or Microsoft Encarta. This in itself is "easy", and typically done by having a platform-specific UI that retrieves domain objects from a datastore/business logic middle tier. More interesting and challenging would be to make the UI/backend split "higher up". Do all the layout work on the backend, and just send a platform-independent description of the UI over the wire. And -that- is what's led me to look for a Component Markup Language. - 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 nwoh at software-ag.de Thu Feb 4 17:31:17 1999 From: nwoh at software-ag.de (Nigel Hutchison) Date: Mon Jun 7 17:08:35 2004 Subject: Component Markup Language In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D05495C@SOHOS002> Message-ID: <3.0.6.32.19990204182918.00929ec0@daemsg01> At 04:47 PM 2/4/99 -0000, Mark Birbeck wrote: >Nigel Hutchison wrote: >> If there was a set of C++ classes that interpreted it and >> built up a GUI >> with the same look and feel, that might be useful. >> Then a server could project its own GUI api and leave it to >> the client side >> to choose C++, Java etc to build the interface at run time. >> I suspect that >> in most cases the bandwidth required to shift the XML GUI >> description would >> be quite a bit less than the >> compiled java classes. If this is so than "Even Cooler" would >> be XML GUI >> interpreter built into a Internet Browser. >> >> But am I running too far with this one? > >Great idea. Can I suggest we call it HTML? I knew you would say that. :-) > >(OK I know I've cracked that one already - it's the end of the week. But >really, if you want an XML specification for a user interface, surely >HTML 4.0 is the one to choose. Then you could use a 'cool browser' that >has an "XML GUI Interpreter" built in - like, well, IE4 and Netscape 4.) > The trouble is that HTML 4.0 + Dynamic HTML + IE4 + Netscape (with back buttons etc) still doesn't quite cut the mustard as far as GUI interfaces are concerned. You can get some good effects if you put a lot of work in but is not very portable or robust. I would also like my GUI interface to have reasonable session control as well. Current browsers are very dodgy when it comes to sessions. I do get SSL for free. But if I use Java applets I get the other extreme. I have to code the GUI in Java, and upload the GUI code, and the security and encryption classes etc and hope it will work on Netscape and Microsoft browsers. regards Nigel Hutchison Nigel W. O. Hutchison Technical Consultant Software AG Germany mailto:nwoh@software-ag.de Tel +49 (0)6151 92 1207 * xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 17:35:52 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:35 2004 Subject: Namespaces does *not* formally introduce "global attributes" In-Reply-To: <01BE5066.010F2A90@grappa.ito.tu-darmstadt.de> References: <01BE5066.010F2A90@grappa.ito.tu-darmstadt.de> Message-ID: <14009.55296.506692.837082@localhost.localdomain> <summary> <em>Please</em>, everyone, stop worrying about <socalled>partitions</socalled>! </summary> Ronald Bourret writes: > 1) Tim Bray's statement that unprefixed attributes do not belong to > an XML namespace derives from (b). Since there is no prefix to > associate them with an XML namespace, and we can't the default XML > namespace doesn't apply, there is simply no association. XML attributes have an automatic association with the element on which they appear, so you have that to fall back on (is that what you were getting at in the text I snipped out?). > 2) As far as I can tell, there is nothing in the normative part of > the spec that would lead us to conclude the existence of a global > attribute partition that is separate from the per-element-type > partitions, as is described in A.2. The reason that partitions are not mentioned in the normative part of the spec is that they haven't really been thought out yet -- that's really part of the schema work. Think of appendix A.2 as "here are some of our preliminary speculations to show you what we were talking about when we designed namespaces". The Namespaces spec just lets you construct globally-unique names; it does not tell you anything about how to interpret those names. 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 nikita.ogievetsky at csfb.com Thu Feb 4 17:45:12 1999 From: nikita.ogievetsky at csfb.com (Ogievetsky, Nikita) Date: Mon Jun 7 17:08:35 2004 Subject: Namespace clashes? Message-ID: <9C998CDFE027D211B61300A0C9CF9AB44246E7@SNYC11309> I thought of namespace prefixes as aliases. If parser is capable to resolve alias <=> alias definition than it should not matter which alias one uses to define the same namespace? Nikita Ronald Bourret wrote: >> Imagine A, B, C, D and E and all users of some XML data. A and B exchange >> data and agree to use A's namespace and that "<an:t>title</an:t>" is a >> book title (among other things). >> >> Elsewhere, C and D also exchange data and agree to use D's namespace and >> that "<dn:t>title</dn:t>" is a book title. >> >> 1. E comes along and wants to create data and exchange data with A, B, C >> and D. What does E use? If E creates a new NS "<en:t>title</en:t>" then >> A, B, C and D have to update there procedures to cater for this? >E should use <an:t> to exchange data with A and B and <dn:t> to exchange >data with C and D. If E creates their own DTD, then everybody who wants to >exchange data with E needs to update their software, which is unlikely to >make E very popular. A much better solution is to get everybody (A-E) to >agree on a single set of tags in the first place. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Feb 4 18:01:21 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:35 2004 Subject: CORBA's not boring yet. / XML in an OS? Message-ID: <4EB4281B.662222A5@darmstadt.gmd.de> Hi, A little while ago on this list someone said they hope that XML wasn't going to have the fate of CORBA ... a standard that people asked too much of, and that is now relegated to the world of boring, overhyped and underused technologies. Well, I was reminded about it when I read this month's Linux Journal - it describes how -both- up and coming desktop environments are basing major parts of their architectures on CORBA. KDE's so cool it makes me want to learn C++. :) Prediction: In 3 years, half the people on this list will be using a corba-based desktop environment. Anyhow, this naturally makes me wonder - could XML and related ideas like XSL have a place in an operating system? Where would they fit in? KDE and Gnome could be great playgrounds for trying something like this out. - 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 paul at prescod.net Thu Feb 4 18:05:00 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:35 2004 Subject: A weaker XSL? References: <19990204162131Z366980-4903+14@calum.csclub.uwaterloo.ca> Message-ID: <36B9D8AA.7B2CFB4B@prescod.net> Peter Seibel wrote: > > At 05:17 AM 2/4/99 , Michael.Kay@icl.com wrote: > >> Is there a possibility for creating a sub-set of > >> XSL that would work on a stream instead of > >> requiring a complete document object? > > > >Funny you should ask that, I've been experimenting over the last few days to > >see whether I could build such a thing on top of SAXON. Not actually easy to > >do as a pure subset, but I think one can do something that feels quite > >XSL-like. > > So I obviously lack imagination or understanding of all the intricacies of > XSL -- what can you express in XSL that you couldn't implement on top of SAX? How do I build a table of contents that is output BEFORE the document without reading the whole input before I start to output? -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 18:34:34 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:35 2004 Subject: Restricted Namespaces for XML Message-ID: <3.0.32.19990204095507.00bb99c0@pop.intergate.bc.ca> At 12:16 AM 2/4/99 -0800, Don Park wrote: >If I read James Clark's message correctly, I believe he is in favor of >chopping out some features out of the "Namespaces for XML" as well as some >sections so I believe we might be on a good track. > >Another crazy idea I had was to remove the use of URI while keeping the >basic style. Urgh. I think that loses 95% of the benefit. My idea had always been that with namespaces, I'd be able to write a little SAX or DOM code that could reliably pick "my" elements and attributes out of the middle of anybody's document, anywhere, and do "my" stuff on them; simply by keying off the namespace URI. -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 Thu Feb 4 18:34:33 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:35 2004 Subject: Component Markup Language Message-ID: <3.0.32.19990204102409.00b73e10@pop.intergate.bc.ca> At 09:13 AM 2/4/99 -0800, Dave Winer wrote: >>>In addition to XwingML, we have announced Bluestone's XML-Server, the first >generally available Dynamic XML Server > >I would like to know what this means. It means nothing, like most windy marketing BS. There have now been half a dozen announcements of "The First XML Server/Repository/" or permutations of that name. -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 tyler at infinet.com Thu Feb 4 18:57:42 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:35 2004 Subject: A weaker XSL? References: <199902041016.EAA06857@trinkpad.valleytel.net> Message-ID: <36B9ECED.38BE05E9@infinet.com> Nathan Kurz wrote: > Also, while the entire stream has to have been read, does it have to > have already been processed? The way I was interpretting the spec, > the DOM model didn't exclude a lazy processing method. So long as an > implementation provides a compliant interface, can't it do anything it > wants with the data, even so far as to put off processing information > until it is requested? Actually this is legal, just that when over you iterate over nodes, a Node needs to return the expected data. If you are reading things from a stream, then you obviously cannot just make random accesses throughout the stream to lazily evaluate your data because streams are inherently sequential. For a DOM document that is merely an interface to a DBMS, this lazy data model approach you suggest may indeed be the optimal solution for that particular implementation. > I had hoped for an extremely lazy DOM implementation that would > maintain information about all but the root level nodes in a 'flat' > unprocessed state a request for that information is made. For many > cases (well, at least the ones I'm envisioning) such an implemention > would be much more efficient than an entirely pre-processed one. Is > this sort of implemention just right out of the question? No. Sorry if I confused you. > > As for the second statement (regarding XSL), could these constraints > be more explicitly laid out? While I can see that arbitrary XSL might > require a fully constructed tree, couldn't one come up with many cases > where a partially constructed tree would be sufficient? For example, > what if your style sheet had only the following template: > > <xsl:template match="/match"> > Found a match! > </xsl:template> > > Would one still have to fully construct your tree ahead of time? > > Hoping I'm not too far off base but half-expecting that I must be, > > nathan kurz > nate@valleytel.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 cowan at locke.ccil.org Thu Feb 4 19:01:21 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:35 2004 Subject: Fw: Namespaces References: <007f01be5023$1a9d33a0$5402a8c0@oren.capella.co.il> Message-ID: <36B9EE58.E4CD419F@locke.ccil.org> Oren Ben-Kiki scripsit: > Is it possible to recast the namespace recommendation as a transformation > from an XML tree with 'xmlns' attributes and '...:' prefixes into a tree > which doesn't have them, but with modified element and attribute names, such > that the semantics of the resulting tree under the rest of the relevant > recommendations (ignoring namespaces) is preserved? Of course. Furthermore, it is possible in one pass. Check my namespace filter at http://www.ccil.org/~cowan/XML/NamespaceFilter.java . > Note that this may require defining a textual form for the transformed tree > (using "...^...", or "{..}..", or whatever). And so I do. > If so, then we'll have a clear definition of just how to add a namespace > processor on top of a normal XML processor. Proof by example. > These two statements seem contradictory to me - if "all" the namespaces do > is prefix the names with a URI [...]. More accurately: it shows how to map names that contain a colon to URI-prefixed form; some colon-free element names are also given URI-prefixed equivalents, but some are not; attribute names without colons are not given URI-prefixed forms. -- 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 CBenedet at Bluestone.com Thu Feb 4 19:04:16 1999 From: CBenedet at Bluestone.com (Benedetto, Christopher) Date: Mon Jun 7 17:08:35 2004 Subject: Component Markup Language Message-ID: <9A4DF69E3C5ED211B86400A0C9D17760847220@thor.operations.bluestone.com> The Bluestone XML-Server can dynamically generate and receive XML documents. It can also enable legacy integration for the enterprise very cost-effectively. The reason why we make the distinction of the dynamic XML server is that it's not like other products out there. There are a lot of XML servers that are focused on being repositories and content managers. Dynamic XML servers generate XML documents that are very short-lived - they get sent to a browser for display, or to another application to be used, or to another XML server to do enterprise application integration. Specifically, the Bluestone XML-Server connects to any DB via JDBC, supports RMI, IIOP, SSL and HTTP protocols, can be exposed as an EJB, runs in any JVM, and in conjunction with Bluestone's Sapphire/Web application server, can dynamically scale to 100 million interactions and integrate with nearly a dozen back-end business data objects (SAP, Peoplesoft, CICS, MQSeries, etc). -----Original Message----- From: Tim Bray [mailto:tbray@textuality.com] Sent: Thursday, February 04, 1999 1:34 PM To: Dave Winer; xml-dev@ic.ac.uk Subject: RE: Component Markup Language At 09:13 AM 2/4/99 -0800, Dave Winer wrote: >>>In addition to XwingML, we have announced Bluestone's XML-Server, the first >generally available Dynamic XML Server > >I would like to know what this means. It means nothing, like most windy marketing BS. There have now been half a dozen announcements of "The First XML Server/Repository/" or permutations of that name. -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) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Thu Feb 4 19:10:31 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:36 2004 Subject: A weaker XSL? References: <19990204162131Z366980-4903+14@calum.csclub.uwaterloo.ca> <36B9D8AA.7B2CFB4B@prescod.net> Message-ID: <36B9EFD2.62A42FA@manhattanproject.com> Paul Prescod wrote: > Peter Seibel wrote: > > >> Is there a possibility for creating a sub-set of > > >> XSL that would work on a stream instead of > > >> requiring a complete document object? > > >Funny you should ask that, I've been experimenting over the last few days to > > >see whether I could build such a thing on top of SAXON. Not actually easy to > > >do as a pure subset, but I think one can do something that feels quite > > >XSL-like. > > So I obviously lack imagination or understanding of all the intricacies of > > XSL -- what can you express in XSL that you couldn't implement on top of SAX? > > How do I build a table of contents that is output BEFORE the document > without reading the whole input before I start to output? > Exactly :) With a weak-XSL you coudn't build the table of contents BEFORE the entire stream is read, the same with sorting, you can't do it before the entire stream is read. However, it can do other things, like turning a <catalog> into a <table>, building a index or trailing table of contents, etc. Thus it still has use for translating XML into HTML and other output forms, while not requiring the memory and processing overhead. Also, if you really needed the stream sorted or a table of contents first, there is nothing preventing the producer of the stream (a database?) from doing this. Don Park wrote: > > The DOM spec does NOT require the entire stream to be read before the > document object is returned. Some of the DOM implementations available > today does indeed process the entire stream before returning but that is a > quality of implementation issue. Really? DOM specification: > > interface Node { > readonly attribute NodeList childNodes; > readonly attribute Node lastChild; > }; > > interface NodeList { > Node item(in unsigned long index); > readonly attribute unsigned long length; > }; It seems that these two in combination would make a recursion that would require the entire stream to be read before the object would be useable. I guess you _could_ make these attributes smart methods that would BLOCK if the information required to satisfy the request was not yet available. But then, anyone using the DOM would have to use these attributes understanding that any one of them may block for a minute or more while the stream "catches up"... I'm not sure that this is valueable, especially when SAX provides such a nice stream-oriented interface to XML documents. :) Clark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ti64877 at imcnam.sbi.com Thu Feb 4 19:12:19 1999 From: ti64877 at imcnam.sbi.com (Ingargiola, Tito) Date: Mon Jun 7 17:08:36 2004 Subject: CORBA's not boring yet. / XML in an OS? Message-ID: <3994C79D0211D211A99F00805FE6DEE249BF77@exchny15.corp.smb.com> Hi, I'm certainly not ready to condemn CORBA to the realm of "boring, overhyped and underused technologies" (though I do have my moments...), and I don't know too much about GNOME and KDE specifically, but I certainly think that there is a great deal of potential synergy between CORBA and XML/DOM in the "application server" space. I believe that many of the people looking at XML (and the alphabet soup of related technologies...) are looking to implement systems which: o deal with databases of various sorts o present UIs via the web o provide programmatic/non-web interfaces to external systems and XML (and friends) promise to help in each of these areas. Database vendors are (talking about) providing an XML layer on their DBMSs, web browser and server vendors are driving many of these standards efforts, and XML's applicability to workflow-type problems is possibly its key selling attraction. This, to me, all points to the fact that XML is going to become a key element in the "application server" space. I don't think there are any surprises here. The fact that the DOM provides IDL mappings (albeit barely workable ones :-/), *combined* with the fact that application servers have obvious scalability problems without some means of distribution (e.g., CORBA, DCOM, &tc) tells me that this space is the key area in which we'll see CORBA and XML (&tc) playing together. Another area (where these families of technologies meet) which has generated a lot of attention is as one of the mechanisms used to provide a "metadata" description of a software component (e.g., a javaBean or a (D)COM object), but this seems to me rather less generally interesting for people looking to implement systems in the short term with characteristics like those described above. (For component tools vendors, however ...) What is more interesting (to me, at least ;-) is trying to envision what our XML-friendly, distributed application server is going to look like. What kinds of services do we need to provide in our distributed environment to best leverage these technologies? I certainly imagine that we'll have some means of querying a DB and receiving a Document, DocumentFragment, or (shudder) NodeList as a result of this query. Further, we'll be able to "push" this object up onto our distribution mechanisms "bus" (to use a CORBAism). I also imagine that we'll have a set of services for manipulating these objects available on our bus: transformations (for sorting, searching, retargeting to a different DOM model (e.g., HTML), &tc), formatting (think the formatting side of XSL), reference resolution (e.g., get the appropriate stylesheet, DTD or XLink-ed element in this document), and undoubtedly others. Our application server will clearly have one or more gateways from/to (e.g., through) a Web Server, and may well provide tools to help automate the development of non web-oriented interfaces to the system. Naturally, there are a lot of question marks remaining here (performance looms large in my mind), but I feel pretty safe saying this is one of the key places we're going with XML, and CORBA and other distribution technologies share a pretty prominent role in this space. I'd be interested to hear how others envision this hypothetical (for now) application server. Regards, Tito. > ---------- > Subject: CORBA's not boring yet. / XML in an OS? > > Hi, > > A little while ago on this list someone said they hope that XML wasn't > going to have the fate of CORBA ... a standard that people asked too > much of, and that is now relegated to the world of boring, overhyped and > underused technologies. > > Well, I was reminded about it when I read this month's Linux Journal - > it describes how -both- up and coming desktop environments are basing > major parts of their architectures on CORBA. KDE's so cool it makes me > want to learn C++. :) > > Prediction: In 3 years, half the people on this list will be using a > corba-based desktop environment. > > Anyhow, this naturally makes me wonder - could XML and related ideas > like XSL have a place in an operating system? Where would they fit in? > KDE and Gnome could be great playgrounds for trying something like this > out. > > - 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 dave at userland.com Thu Feb 4 19:16:37 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:36 2004 Subject: Component Markup Language In-Reply-To: <9A4DF69E3C5ED211B86400A0C9D17760847220@thor.operations.blu estone.com> Message-ID: <3.0.6.32.19990204111937.00f439b0@scripting.com> >Dynamic XML servers generate XML documents that are very short-lived - they get sent to a browser for display, or to another application to be used, or to another XML server to do enterprise application integration. After Tim Bray's response, I'm not sure much more needs to be said, other than we've been doing that, starting in late 1997. We've not been shy about our accomplishments, a simple search of the XML-DEV list or AltaVista would have revealed that you were not first, not by a long shot. One other thing, XML, in my view, is about compatibility, so being first is worse than meaningless, it says you have nothing to offer in the way of compatibility. 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 simonstl at simonstl.com Thu Feb 4 19:17:44 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:36 2004 Subject: MS patents style sheets Message-ID: <199902041916.OAA17422@hesketh.net> I just heard about this on another list; info came from the Seybold Report. Elliotte Rusty Harold's Cafe Con Leche (http://metalab.unc.edu/xml/) picked it up, and has a pointer to the patent: http://www.patents.ibm.com/details?pn=US05860073__&language=en Interesting times, interesting times... Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 tyler at infinet.com Thu Feb 4 19:20:28 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:36 2004 Subject: Restricted Namespaces for XML References: <01BE5040.5CB976A0@grappa.ito.tu-darmstadt.de> Message-ID: <36B9F233.8B193A44@infinet.com> Ronald Bourret wrote: > Don Park wrote: > > > Such a spec might dictate that all namespace declarations be at the root > > element (XML fragments are problematic but...). This restriction has the > > side effect of not allowing duplicate prefixes. > > The major benefit of this proposal is that it reduces the number of checks > for xmlns attributes. This savings is minimal in small documents or > documents with few attributes, but it would be interesting to know how much > xmlns attribute processing costs in a large, attribute-intensive document. > > I think readability is a wash, as you can't do anything more with this than > you can with the current proposal and you lose the ability to have multiple > default namespaces, which are useful in documents that have long sections > alternating between two or more namespaces. > > I think the biggest problem is, as James Clark noted elsewhere, > complication of fragmentation. Since I believe fragments to be a big part > of the future, I don't like anything that will make them harder. > > That said, if anybody had some real numbers about what xmlns attribute > processing costs in the worst case and this turned out to be significant, > it might be useful to have a PI that tells the namespace processor whether > it needs to look beyond the root element. At the parser level, things are not very expensive if you check each attribute name you parse to see if it is of the string "xmlns" or else starts with the string "xmlns:". However, directly on top of SAX (or done as a filter on top of an XML Parser) you need to in effect for every element: Search the entire attribute list for attributes with the name "xmlns" or else something that starts with "xmlns:". You in effect need to do something like: public void startElement(String name, AttributeList attributes) throws SAXException { int length = attributes.getLength(); String name; for (int i = 0; i < length; i++) { attributeName = attributes.getName(i); if (attributeName.equals("xmlns")) { // Do default namespace processing } else if (attributeName.startsWith("xmlns:")) { // Do namespace processing } } } If you have documents which have very few attributes in the elements, then this is not too expensive. If you have documents (like HTML literal result elements in XSL) then things can get pretty harry. If SAX were to make a simple requirement that all strings that represent symbols (like names) were to be interned then things would be a lot cheaper. The same can be said of the DOM as well. Even though there is a relatively small cost to interning all Names in the DOM, being able to test for identity instead of equality for operations like namespace processing are not as big a performance problem anymore (plus it can help out in performance areas for a lot of applications in the general case). Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 19:22:08 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:36 2004 Subject: Fw: Namespaces Message-ID: <3.0.32.19990204111758.00b71980@pop.intergate.bc.ca> At 02:00 PM 2/4/99 -0500, John Cowan wrote: >> These two statements seem contradictory to me - if "all" the namespaces do >> is prefix the names with a URI [...]. > >More accurately: it shows how to map names that contain a colon >to URI-prefixed form; some colon-free element names are also >given URI-prefixed equivalents, but some are not; attribute names >without colons are not given URI-prefixed forms. Thank you, John. Will those full of namespace angst please study John's paragraph closely; some pedants might want to say "qualified" rather than "prefixed", but prefix will do. I guess I'm too close to the problem now to be able to explain how little the namespace spec does. Or at least be believed when I do. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Thu Feb 4 19:30:32 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:36 2004 Subject: A weaker XSL? References: <199902041016.EAA06857@trinkpad.valleytel.net> <36B9ECED.38BE05E9@infinet.com> Message-ID: <36B9F44D.69B65B4@manhattanproject.com> Tyler Baker wrote: > > Nathan Kurz wrote: > > > Also, while the entire stream has to have been read, does it have to > > have already been processed? The way I was interpretting the spec, > > the DOM model didn't exclude a lazy processing method. So long as an > > implementation provides a compliant interface, can't it do anything it > > wants with the data, even so far as to put off processing information > > until it is requested? > > Actually this is legal, just that when over you iterate over nodes, > a Node needs to return the expected data. > If you are reading things from a stream, then you obviously cannot > just make random accesses throughout the stream to lazily evaluate > your data because streams are inherently sequential. Yep. Perhaps the weak-XSL could be based upon SAX instead, then you won't be suprized. In this case, the XSL processor would contain both a DOM and SAX implementation. If the XSL sheet was "weak", then the processor could implement it's processing from the SAX output. Otherwise, if it is the "strong" variant, with sorting and table of contents, etc, then it would use the DOM implementation. Also, if the processor was built upon a memory image, then SAX becomes an Iterator over the DOM object. If the processor was built upon a stream input, then the DOM object is constructed from the SAX output. This seems like it would be a really nice ballence. > For a DOM document that is merely an interface to a DBMS, this lazy > data model approach you suggest may indeed be the optimal solution > for that particular implementation. Perhaps. However, many relational databases use a "stream" based approach internally, expecially in cases with large merge/joins. The result set is definately returned in a stream, having a bunch of small queries would bring performance to a crawl since set operations could not be used effectively. This behavior definately depends upon the query and how it is optimized. Thus, you may find that a SAX-like stream based interface on top of a relational database may perform much better than an DOM-like object based interface! Perhaps a hybrid object/stream solution would work the best when a relational database is a primary data source... :) Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 19:39:08 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:36 2004 Subject: Fw: Namespaces References: <002701be5050$1b09deb0$5402a8c0@oren.capella.co.il> Message-ID: <36B9F6FE.124BCDE8@locke.ccil.org> Oren Ben-Kiki wrote: > Why wasn't the DTD spec extended to handle global attributes (regardless of > namespace issues) instead of sneaking them in the namespace spec? Global > attributes make the same amount of sense for non-prefixed attributes within > a single XML language. This is the root of the problems here - _what is the > benefit gained from placing this in the namespace spec_? Is there one? Is it > worth it? Can we revoke it? I think that some of your problems come from misunderstanding the term "global attribute": unfortunately, the examples in REC-xml-names don't help. A "global attribute" is *not* an attribute that can be placed on every element in a document, or at least it need not be. A global attribute is simply one which has by intention the same meaning in all elements in which it appears. To reuse my earlier example, given an appropriate binding for the "iso4217" prefix, one might have a global attribute "iso4217:currency" which applies to only the PRICE element in a supply catalog. The "iso4217" prefix signals the application that it can use a *global* understanding of currency --- namely, that the value of this attribute is an ISO 4217 currency code (USD, GBP, EUR, etc.). The example of html:class is unfortunately "global" in both the intended sense (its meaning is independent of the element on which it appears) and the unintended sense (it may appear on any element). So it is a bad example for explaining global attributes. >From a DTD viewpoint, global attributes are just ordinary attributes, valid only where an ATTLIST declaration allows them. -- 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 tyler at infinet.com Thu Feb 4 19:52:21 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:36 2004 Subject: CORBA's not boring yet. / XML in an OS? References: <4EB4281B.662222A5@darmstadt.gmd.de> Message-ID: <36B9FA0C.11FBFBC@infinet.com> Robb Shecter wrote: > Hi, > > A little while ago on this list someone said they hope that XML wasn't > going to have the fate of CORBA ... a standard that people asked too > much of, and that is now relegated to the world of boring, overhyped and > underused technologies. That was me... > Well, I was reminded about it when I read this month's Linux Journal - > it describes how -both- up and coming desktop environments are basing > major parts of their architectures on CORBA. KDE's so cool it makes me > want to learn C++. :) I think this may end up being a major mistake. IIOP is a nice protocol, but other than that, CORBA is really only useful for integrating client/servers of differing operating environments and hardware. > Prediction: In 3 years, half the people on this list will be using a > corba-based desktop environment. Not likely. My biggest problem with CORBA was that it was too huge for the client and consumed too many resources. Maybe it was just the Visigenic implementation I was using at the time, but plain and simple CORBA is not lightweight. CORBA is one of those things which I feel could be made better by stripping a lot of the rarely used stuff out. This is not a CORBA list so I will pretty much end this here... > Anyhow, this naturally makes me wonder - could XML and related ideas > like XSL have a place in an operating system? Where would they fit in? > KDE and Gnome could be great playgrounds for trying something like this > out. They already do if you consider Internet Explorer a fundamental part of the Windows Operating System (-: Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 20:21:45 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:36 2004 Subject: Component Markup Language Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054960@SOHOS002> Robb Shecter wrote: > How about this: Have one XSL document per client side > scripting language. That is, different > XSL documents could implement: > > Component-XML->DHTML (This particular one would > give you your "Even Cooler" idea.) > > Component-XML->Java BeanShell > Component-XML->Smalltalk > etc... > > ...then, a client side browser applies whatever XSL template > is best for it, gets the the > resulting kind of script it understands, and on the fly > generates a UI. We do something similar for browser types, by generating all XSL documents through an ASP page. In our case, we detect the browser type, and change the rules in the stylesheet dynamically. Your scenario would benefit too, because you wouldn't need to send loads of sylesheets to the client - just one, but one that has been dynamically created. (I don't know why I'm responding because I still disagree with whole idea of a component XML! By the time anyone has come up with a useful standard that *does* cope with the minor inefficiencies that have been mentioned, HTML 5 will have been along and will have resolved it. If it really is necessary then I would use HTML 4.0 as the base for the component-XML syntax, and then map *that* to Java interfaces, or whatever. In other words, write a Java (or whatever) interface that understands HTML, plus your few extensions.) Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 eliot at dns.isogen.com Thu Feb 4 20:24:26 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:36 2004 Subject: Proposal: New Syntax for DSSSL (was Re: MS patents style sheets) In-Reply-To: <199902041916.OAA17422@hesketh.net> Message-ID: <3.0.5.32.19990204142337.00a40100@amati.techno.com> At 02:19 PM 2/4/99 -0500, Simon St.Laurent wrote: >I just heard about this on another list; info came from the Seybold Report. > >Elliotte Rusty Harold's Cafe Con Leche (http://metalab.unc.edu/xml/) picked >it up, and has a pointer to the patent: This sounds like the infamous "multimedia" patent that someone tried to get a few years back (don't remember the details). This thread triggered me to propose something that I'd been tossing around in my head for a while: Why not define a new syntax for DSSSL as a public, open-source activity? In particular, why not define a Python-based expression syntax? Why: 1. DSSSL is very powerful. DSSSL is well thought out. DSSSL is an established and stable international standard. DSSSL is implemented (jade, <www.jclark.com/jade>, and HyBrick <http://www.fsc.fujitsu.com/hybrick/>). 2. DSSSL's expression syntax, which is scheme-based, is a serious barrier to acceptance and use. While the use of scheme makes perfect sense from a "what language best fits list processing", it is a non-starter from a "who can I hire that can write this stuff?" standpoint. If you can program in Java or VB or Perl, you can learn Python in about an hour. Learning the scheme-based language is much more difficult, because it asks you to move from a procedural-based approach to a functional approach. This seems to be a fairly high barrier for a lot of programmers (it was for me). 3. Python combines a fundamental list awareness with a familiar and easy-to-learn syntax. It provides true, easy-to-use (and learn) object orientation. You can do functional or procedural programming as you prefer. >From a programming standpoint, it wouldn't be very hard to implement the DSSSL semantics in Python. I think it would require the following: 1. Development of a rule-firing layer (the part of a DSSSL engine that applies rules to grove nodes) 2. Implementation of at least the core DSSSL-defined functions 3. Generation of flow object trees Of these, the last is probably the hardest, but should be able to re-use existing code (e.g., Jade). A Python-based syntax for DSSSL, once implemented and proven, could be quickly standardized because it would simply be an alternative syntax for an existing standard--no need to define new semantics. The only barrier to doing this is resources. We already have Python-accessible grove constructors for SGML and XML (Jade itself and TechnoTeacher's GroveMinder). In addition, any DOM implementation can be made to emulate a grove, so all the Jave-based DOM's are immediately available. [Note that I don't think using XML syntax for DSSSL expressions is very interesting given that the Python syntax is already well defined, stable, and has public and free parsers.] In any case, having a style language that has no vendor intellectual property encombrances suddenly seems a lot more compelling than perhaps it did yesterday. Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 20:54:02 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:36 2004 Subject: Component Markup Language Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054961@SOHOS002> > One cannot rely on "HTML 5" as a solution to this problem. The next > generation of HTML will not provide any such facilities. Information > about the nature of the next generation HTML can be obtained > by reading > current Working Draft: > http://www.w3.org/TR/1998/WD-html-in-xml-19981205/ Can people please be specific, so I can see if I have lost the plot here: If I was to propose a component-XML DTD that began with a tag called HTML, then others called HEAD and BODY, and it had definitions for text fields, buttons, drop-boxes, images, tables and more, as well as being able to call up external programs and all the rest of it; what ADDITIONAL features is everyone saying they would want to be present in *their* component-XML that are not in 'mine' (and I really think the lack of graphics on a button is insufficient justification for spending the next year writing an entire XHTML!) I'm not saying that the user-interface has to then be a web browser - make it Java if you want. All I'm saying is there is a very good syntax in place for defining user interfaces - why not use it? Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 Ed at dega.com Thu Feb 4 21:11:20 1999 From: Ed at dega.com (Ed Howland) Date: Mon Jun 7 17:08:36 2004 Subject: CORBA's not boring yet. / XML in an OS? Message-ID: <30649320C177D111ADEC00A024E9F297169F33@exchange-server.dega.com> This brings up a related question regarding XML and interchanging data between web servers. Is there something like IIOP for this? I mean an overlaying protocol to establish, manage and break bi-direction XML traffic. In my scenario, I want to develop a published specification (read DTD) to provide all the details of accomplishing an order in an e-commerce environment. In this case, business #1 (B1) wants to order material from business #2 (B2). The web server at B1 uses some middle tier logic (Java) to determine how to get to the right B2. B2 has a web site for individual orders but can also take a standard order in XML (again, in my published DTD). But how does it do that? In other words how do I push XML down the server's throat? I know that a form could be used on B2 that had a field that could be filled in with a hlink back to the XML file on B1. Or the URL of B1's XML file could be placed in some CGI parameter. Or some combination of FTP and CGI could be used (in cases where the requirements of B1's server prohibit retrieval of files this way (perhaps because of security.)) But it seems to me that this approach just utilizes normal HTTP, which seems to be ill-designed in the way of bi-directional data flow. Is someone working on an more elborate mechanism for this? Do we need a XIOP? Just rambling.... Ed Ed Howland ed@dega.com http://www.dega.com "As your attorney, I advise you to take some adrenalchrome" -------------- next part -------------- A non-text attachment was scrubbed... Name: Ed Howland (E-mail).vcf Type: application/octet-stream Size: 157 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990204/035fe786/EdHowlandE-mail.obj From oren at capella.co.il Thu Feb 4 22:10:14 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:08:37 2004 Subject: Fw: Namespaces does *not* formally introduce "global attributes" Message-ID: <000e01be508a$67213110$5402a8c0@oren.capella.co.il> >Oren Ben-Kiki writes: > > AHA! So the namespaces proposal _DOES_ go beyond simply qualifying > > names with URIs! David Megginson <david@megginson.com> wrote: >No it doesn't. Well it certainly got a lot of people confused about it. Luckly we are only wasting bandwidth as a result, instead of rain forest products :-) >The comment to which Oren is replying contains a common (but >understandable) mistake. ... > The source of the misreading is the unfortunately obfuscatory appendix >A.2, ... >I will recommend dropping A.2 in future drafts. That would be a relief :-) >In any case, what does all this have to do with transformation? Simple - if the XML namespaces recommendation was defined by an equivalence to a well defined textual transformation, then much confusion would have been avoided. For example, how namespaces interact with the other XML standards - just extend the names first, then apply the other standards (with a very small number of exceptions, such as namespace patterns in XSL). Additionally, implementers would have been able to easily add a namespace processing module on top of their current XML parsers (a SAX namespace expansion filter, for example, is trivial when implemented this way), _without changing the interfaces_. Future implementations might use better interfaces - such as APIs for accessing just the "namespace part" or the "local part" of an expanded name - but the point is every XML application would go on working as it is, without any changes. James has mentioned in his paper the WG has deliberately decided not to go this way. Could you tell us why this decision was made? An obvious consequence of this decision is that implementers were hesitant to implement namespaces this way. I hope this wasn't the reason :-) This happened because first, it wasn't clear that this approach is in fact conformant. Well, we got this out of the way - James says it is and you explained why (ignore the non-normative Appendix A). Second, because competing textual forms were suggested (the '^' notation, the '{}' notation). Since the WG wasn't kind enough to give us a standard notation, why can't we just pick one on our own and go with it? I'm partial to the '^' notation, myself, since it is (i) shorter, (ii) easier to read, (iii) slightly easier to process, and (iv) more in tune with the conventional hierarchy naming schemes (using a separator instead of parenthesis). Actually, has anyone already written a SAX filter which implements namespaces this way? Is anyone interested? Let's settle this once and for all - "proof by implementation" :-) Have fun, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Thu Feb 4 22:26:10 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:37 2004 Subject: Namespaces does *not* formally introduce "global attributes" Message-ID: <007501be508c$b728cae0$c9a8a8c0@thing2> >Actually, has anyone already written a SAX filter which implements >namespaces this way? Is anyone interested? Let's settle this once and for >all - "proof by implementation" :-) Well, there's John Cowan's filter: http://www.ccil.org/~cowan/XML/NamespaceFilter.java Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at weblogic.com Thu Feb 4 22:39:12 1999 From: peter at weblogic.com (Peter Seibel) Date: Mon Jun 7 17:08:37 2004 Subject: A weaker XSL? In-Reply-To: <36B9D8AA.7B2CFB4B@prescod.net> References: <19990204162131Z366980-4903+14@calum.csclub.uwaterloo.ca> Message-ID: <19990204224703222.AAA277@ashbury.weblogic.com@lawton> At 09:28 AM 2/4/99 , Paul Prescod wrote: >Peter Seibel wrote: >> >> At 05:17 AM 2/4/99 , Michael.Kay@icl.com wrote: >> >> Is there a possibility for creating a sub-set of >> >> XSL that would work on a stream instead of >> >> requiring a complete document object? >> > >> >Funny you should ask that, I've been experimenting over the last few days to >> >see whether I could build such a thing on top of SAXON. Not actually easy to >> >do as a pure subset, but I think one can do something that feels quite >> >XSL-like. >> >> So I obviously lack imagination or understanding of all the intricacies of >> XSL -- what can you express in XSL that you couldn't implement on top of SAX? > >How do I build a table of contents that is output BEFORE the document >without reading the whole input before I start to output? Buffer the rest of the document. Or make two passes. Presumably your XSL processor can figure out what things need that sort of buffering or multi-pass treatment. Of course I'm building some stuff in memory but it could be a lot less than the whole document as a DOM tree. For example if my document is the Encylopaedia Britanica and I want to output a (strange) document consisting of a list of all the articles followed by the full text of all the articles containing the word pink I only have to buffer the articles with the word pink which is presumably a lot less than the whole encyclopedia. Another way to look at things is to implement your XSL engine so it builds a complete tree of the *output* before it writes anything out. I'm not arguing that you can implement XSL so it uses no heap, just that you could implement it on top of SAX rather than DOM. Or am I still missing something? -Peter -- Peter Seibel Perl/Java/English Hacker peter@weblogic.com Is Windows98 Y2K compliant? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Thu Feb 4 22:57:23 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:37 2004 Subject: A weaker XSL? References: <19990204162131Z366980-4903+14@calum.csclub.uwaterloo.ca> <19990204224703222.AAA277@ashbury.weblogic.com@lawton> Message-ID: <36BA2516.204F50F9@manhattanproject.com> Peter Seibel wrote: > > I'm not arguing that you can implement XSL so it uses no heap, just that > you could implement it on top of SAX rather than DOM. Or am I still missing > something? I think you are echoing my belief. Question: Is XSL defining "style" instructions or "composition" instructions. Things like sorting, re-arranging, table-of-contents generation, etc. are really large processing instructions that are more along the line of *what* to process, rather than *how* the information should be presented. Things like this could be moved into XQL or some other transformation language, leaving XSL a more pure "style" oriented specification. Thus XSL wouldn't be *generating* a table of contents, it would only let you choose if you want to display it, and if it is displayed, how it is displayed, in green ink or red, bold or itallic, Aa1i style or 1.1.1.1 style, etc. By doing this, a weaker XSL would have a much more clearly defined role, would be less subject to "feature creep", and could be implemented on top of SAX instead of assuming (and requiring) a full DOM implelementation. Just $.02 ;) Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu Feb 4 23:35:26 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:37 2004 Subject: A weaker XSL? References: <19990204162131Z366980-4903+14@calum.csclub.uwaterloo.ca> <19990204224703222.AAA277@ashbury.weblogic.com@lawton> <36BA2516.204F50F9@manhattanproject.com> Message-ID: <36BA282D.5545637F@prescod.net> Clark Evans wrote: > > Things like sorting, re-arranging, table-of-contents > generation, etc. are really large processing instructions > that are more along the line of *what* to process, rather > than *how* the information should be presented. Things like > this could be moved into XQL or some other transformation > language, leaving XSL a more pure "style" oriented > specification. XSL is the dominant transformation language for XML content. As far as standardization goes, XQL doesn't even exist. > Thus XSL wouldn't be *generating* a table of contents, > it would only let you choose if you want to display it, > and if it is displayed, how it is displayed, in green > ink or red, bold or itallic, Aa1i style or 1.1.1.1 > style, etc. You are describing CSS. The Web community decided that we needed XSL because CSS does NOT do sorting, re-arranging, TOC generation, cross referencing, etc. Your "weaker XSL" already exists and is called CSS. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu Feb 4 23:37:54 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:37 2004 Subject: A weaker XSL? References: <19990204162131Z366980-4903+14@calum.csclub.uwaterloo.ca> <19990204223858Z367814-4906+21@calum.csclub.uwaterloo.ca> Message-ID: <36BA2770.9B7A1BFF@prescod.net> Peter Seibel wrote: > > Buffer the rest of the document. Or make two passes. You would have to make n-passes where n depends on the XSL stylesheet. As an existence proof of a non-tree implementation, you could avoid implementing a DOM if you re-parsed the document every time you needed to find some query result. But to get any kind of efficiency you need to do some darn sophisticated static analysis. > Presumably your XSL > processor can figure out what things need that sort of buffering or > multi-pass treatment. I have some ideas about how you would do it, but the market does not seem to be willing to pay as much for XSL implementations as it does optimizing C++ compilers so I'm not going to try an implementation. Furthermore you would need to statically analyze the document AND the stylesheet because links will affect what you need to keep in memory. Some people want to allow arbitrary JavaScript code inline so it would be interesting to see you try static analysis if THAT gets added. > Of course I'm building some stuff in memory but it > could be a lot less than the whole document as a DOM tree. For example if > my document is the Encylopaedia Britanica and I want to output a (strange) > document consisting of a list of all the articles followed by the full text > of all the articles containing the word pink I only have to buffer the > articles with the word pink which is presumably a lot less than the whole > encyclopedia. Certainly. But statically analyzing a stylesheet to figure out what to buffer is very tricky. It probably isn't as hard as the halting problem but it is on the level of an optimizing compiler. > Another way to look at things is to implement your XSL engine > so it builds a complete tree of the *output* before it writes anything out. Most of the time XSL's output is larger than the input. > I'm not arguing that you can implement XSL so it uses no heap, just that > you could implement it on top of SAX rather than DOM. Or am I still missing > something? Sure, you can implement it on top of SAX. It will probably run too slowly for most common cases of documents to be useful, but you could do it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 4 23:56:16 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:37 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces for XML) In-Reply-To: <36B9F233.8B193A44@infinet.com> References: <01BE5040.5CB976A0@grappa.ito.tu-darmstadt.de> <36B9F233.8B193A44@infinet.com> Message-ID: <14010.12971.863429.822758@localhost.localdomain> Tyler Baker writes: > If SAX were to make a simple requirement that all strings that > represent symbols (like names) were to be interned then things > would be a lot cheaper. The same can be said of the DOM as well. The problem is that Java's own intern is so terribly inefficient that no serious parser writer will use it (most of them have their own, custom interns). Even then, you wouldn't get any help with the "xmlns:" prefix matching, which is the costliest part. The most efficient way to do namespace processing is directly in the parser (which has to look at every attribute name anyway), but my own tests have shown that filter layer on top of SAX isn't too bad. 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 Feb 5 00:18:07 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:37 2004 Subject: Fw: Namespaces does *not* formally introduce "global attributes" In-Reply-To: <000e01be508a$67213110$5402a8c0@oren.capella.co.il> References: <000e01be508a$67213110$5402a8c0@oren.capella.co.il> Message-ID: <14010.14227.857639.249199@localhost.localdomain> Oren Ben-Kiki writes: [snip] > Additionally, implementers would have been able to easily add a > namespace processing module on top of their current XML parsers (a > SAX namespace expansion filter, for example, is trivial when > implemented this way), _without changing the interfaces_. Future > implementations might use better interfaces - such as APIs for > accessing just the "namespace part" or the "local part" of an > expanded name - but the point is every XML application would go on > working as it is, without any changes. [snip] > An obvious consequence of this decision is that implementers were > hesitant to implement namespaces this way. Actually, so far, pretty much everyone seems to have implemented namespaces this way, and it's working like a charm: it's standard in the very popular Perl XML:Parser module (which uses Expat), I wrote my own SAX filter (unreleased) which works this way, John Cowan has released a SAX filter that works this way, and I assume that all RDF and XSL tools built on top of SAX work this way. I rely quite heavily on the namespace processing in XML::Parser for some of my production-grade deliverables to customers. 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 Feb 5 00:21:24 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:37 2004 Subject: A weaker XSL? In-Reply-To: <19990204224703222.AAA277@ashbury.weblogic.com@lawton> References: <19990204162131Z366980-4903+14@calum.csclub.uwaterloo.ca> <36B9D8AA.7B2CFB4B@prescod.net> <19990204224703222.AAA277@ashbury.weblogic.com@lawton> Message-ID: <14010.14447.929939.629443@localhost.localdomain> Peter Seibel writes: > >How do I build a table of contents that is output BEFORE the > >document without reading the whole input before I start to output? > > Buffer the rest of the document. Or make two passes. In general, however, you cannot know how many passes you need to make, since one query might depend on the results of another. 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 spreitze at parc.xerox.com Fri Feb 5 00:21:30 1999 From: spreitze at parc.xerox.com (spreitze@parc.xerox.com) Date: Mon Jun 7 17:08:37 2004 Subject: CORBA's not boring yet. / XML in an OS? In-Reply-To: <30649320C177D111ADEC00A024E9F297169F33@exchange-server.dega.com> Message-ID: <99Feb4.161915pst."834439"@idea.parc.xerox.com> > This brings up a related question regarding XML and interchanging data > between web servers. Is there something like IIOP for this? I mean an > overlaying protocol to establish, manage and break bi-direction XML traffic. > ... > I know that ... > But it seems to me that this approach just utilizes normal HTTP, which seems > to be ill-designed in the way of bi-directional data flow. Is someone > working on an more elborate mechanism for this? Do we need a XIOP? The HTTP-NG effort (http://www.w3.org/Protocols/HTTP-NG/) is working on factoring HTTP-NG into three layers, the lower two of which seem to be what you're asking for. I think you should be asking for something less elaborate, rather than more elaborate, than HTTP/1 --- and the lower two layers of HTTP-NG should give you that. 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 pvelikho at cs.ucsd.edu Fri Feb 5 00:21:34 1999 From: pvelikho at cs.ucsd.edu (Pavel Velikhov) Date: Mon Jun 7 17:08:37 2004 Subject: A weaker XSL? References: <19990204162131Z366980-4903+14@calum.csclub.uwaterloo.ca> <19990204224703222.AAA277@ashbury.weblogic.com@lawton> <36BA2516.204F50F9@manhattanproject.com> Message-ID: <36BA32FD.85F2D000@cs.ucsd.edu> Clark Evans wrote: > > Peter Seibel wrote: > > > > I'm not arguing that you can implement XSL so it uses no heap, just that > > you could implement it on top of SAX rather than DOM. Or am I still missing > > something? > > I think you are echoing my belief. > > Question: Is XSL defining "style" instructions > or "composition" instructions. > > Things like sorting, re-arranging, table-of-contents > generation, etc. are really large processing instructions > that are more along the line of *what* to process, rather > than *how* the information should be presented. Things like > this could be moved into XQL or some other transformation > language, leaving XSL a more pure "style" oriented > specification. But XSL is really turning into a query language for XML, not just a stylesheet language. I completely agree that some lightweight language is needed to do the basic presentation-oriented things. Then the implementation could be made efficient, such things as intelligent buffering of the input, lazy evaluation of the output document, optimization are really hard to do for a full blown query language, but are doable for a simple one. > Thus XSL wouldn't be *generating* a table of contents, > it would only let you choose if you want to display it, > and if it is displayed, how it is displayed, in green > ink or red, bold or itallic, Aa1i style or 1.1.1.1 > style, etc. > > By doing this, a weaker XSL would have a much more > clearly defined role, would be less subject to > "feature creep", and could be implemented on top > of SAX instead of assuming (and requiring) a full > DOM implelementation. It will probably be orders of magnitude more efficient too. And it will have a more clear and understandable role. IMHO nobody wants to learn a bunch of highly expressive and pretty much general purpose languages for XML processing. > Just $.02 > ;) Clark Evans Pavel Velikhov xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Feb 5 00:25:04 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:37 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces for XML) References: <01BE5040.5CB976A0@grappa.ito.tu-darmstadt.de> <36B9F233.8B193A44@infinet.com> <14010.12971.863429.822758@localhost.localdomain> Message-ID: <36BA39DE.761F3281@infinet.com> David Megginson wrote: > Tyler Baker writes: > > > If SAX were to make a simple requirement that all strings that > > represent symbols (like names) were to be interned then things > > would be a lot cheaper. The same can be said of the DOM as well. > > The problem is that Java's own intern is so terribly inefficient that > no serious parser writer will use it (most of them have their own, > custom interns). As of JDK 1.1.6 things are not so bad and Java 2 is a bit better as interned Strings are under the hood managed using Weak References. It could be made better in the JDK though. I suspect if they made a real effort in the Java 2 JVM they could make string interns at least twice as fast as things currently are. Nevertheless, string interning is a one time cost so lets put that in perspective here. > Even then, you wouldn't get any help with the "xmlns:" prefix > matching, which is the costliest part. The most efficient way to do Very true (ouch, ouch, ouch)... > namespace processing is directly in the parser (which has to look at > every attribute name anyway), but my own tests have shown that filter > layer on top of SAX isn't too bad. Unfortunately as in the case with all XML or XSL benchmarks, the test data can vary enormously. If you have documents that have few elements with attributes (except of course namespace attributes), then things probable will not be so bad. However, if you have lots of attributes in elements, then you need to check every single attribute to see if it starts with "xmlns:" (ouch, ouch, ouch). So I suppose we should no encourage document designers to model data only as character content in elements and only use attributes for ID's and namespaces declarations. For types like a rectangle, I think using attributes makes a lot more sense in the general case, but in the presence of "Namespaces in XML" I would change things from: <Rectangle x="0" y="1" width="59" height="23"> to: <myprefix:Rectangle xmlns:myprefix="YabbaDabbaDoo"> <myprefix:x> 0 </myprefix:x> <myprefix:y> 1 </myprefix:y> <myprefix:width> 59 </myprefix:width> <myprefix:height> 23 </myprefix:height> </myprefix:Rectangle> The really sad thing about this is that there tends to be a feeling among a lot of people that meaningful prefixes do not matter at all. If XML is ever going to be editable by an average internet user for some common tasks, meaningful prefixes do matter. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 00:34:44 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:37 2004 Subject: Fw: Namespaces does *not* formally introduce "global attributes" Message-ID: <3.0.32.19990204162458.00b5d650@pop.intergate.bc.ca> At 07:16 PM 2/4/99 -0500, David Megginson wrote: >Actually, so far, pretty much everyone seems to have implemented >namespaces this way, and it's working like a charm: it's standard in >the very popular Perl XML:Parser module (which uses Expat) Seconded. Here's the example I use to teach namespaces to perl programmers; they get it instantly use XML::Parser; $xml = "<z xmlns='http://one.org' xmlns:two='http://two.org'><y1 /><two:y2 /></z>"; $p = new XML::Parser(Namespaces => 1, Handlers => { Start => \&STag }); $p->parse($xml); sub STag { my ($expat, $type) = @_; my $ns = $expat->namespace($type); print "Element type $type is from namespace $ns\n"; } =========output========================================== Element type z is from namespace http://one.org Element type y1 is from namespace http://one.org Element type y2 is from namespace http://two.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Feb 5 00:34:45 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:37 2004 Subject: CORBA's not boring yet. / XML in an OS? In-Reply-To: <99Feb4.161915pst."834439"@idea.parc.xerox.com> References: <30649320C177D111ADEC00A024E9F297169F33@exchange-server.dega.com> Message-ID: <3.0.6.32.19990204163649.00f40e20@scripting.com> Gotta check it out! XML-RPC.. What CORBA wants to be. ;-> http://www.xmlrpc.com/ Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Feb 5 00:38:10 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:37 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces for XML) In-Reply-To: <36BA39DE.761F3281@infinet.com> References: <01BE5040.5CB976A0@grappa.ito.tu-darmstadt.de> <36B9F233.8B193A44@infinet.com> <14010.12971.863429.822758@localhost.localdomain> <36BA39DE.761F3281@infinet.com> Message-ID: <14010.15436.198339.22480@localhost.localdomain> Tyler Baker writes: > As of JDK 1.1.6 things are not so bad and Java 2 is a bit better as > interned Strings are under the hood managed using Weak References. > It could be made better in the JDK though. I suspect if they made > a real effort in the Java 2 JVM they could make string interns at > least twice as fast as things currently are. Nevertheless, string > interning is a one time cost so lets put that in perspective here. No, unfortunately it's much worse -- the parser has to re-intern *every* element name and attribute name during the parse, so if I have 6,000 attributes named 'foo', I have to invoke intern 6,000 times (just for those attributes). When I was writing AElfred, I got something between a 10-30% speedup (I cannot remember the number) by dropping Java's intern and writing my own. A bad intern is a killer for an XML parser. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Feb 5 00:59:40 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:38 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces for XML) Message-ID: <3.0.32.19990204165540.00b57da0@pop.intergate.bc.ca> At 07:35 PM 2/4/99 -0500, David Megginson wrote: >Tyler Baker writes: > > > As of JDK 1.1.6 things are not so bad and Java 2 is a bit better > >No, unfortunately it's much worse -- the parser has to re-intern >*every* element name and attribute name during the parse, so if I have >6,000 attributes named 'foo', I have to invoke intern 6,000 times >(just for those attributes). When I was writing AElfred, I got >something between a 10-30% speedup Lark too; and I just do lookup with binary search, nothing fancy, and the difference was huge. What is Java actually doing I wonder? -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 tyler at infinet.com Fri Feb 5 01:39:10 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:38 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces for XML) References: <01BE5040.5CB976A0@grappa.ito.tu-darmstadt.de> <36B9F233.8B193A44@infinet.com> <14010.12971.863429.822758@localhost.localdomain> <36BA39DE.761F3281@infinet.com> <14010.15436.198339.22480@localhost.localdomain> Message-ID: <36BA4B75.2034265D@infinet.com> David Megginson wrote: > Tyler Baker writes: > > > As of JDK 1.1.6 things are not so bad and Java 2 is a bit better as > > interned Strings are under the hood managed using Weak References. > > It could be made better in the JDK though. I suspect if they made > > a real effort in the Java 2 JVM they could make string interns at > > least twice as fast as things currently are. Nevertheless, string > > interning is a one time cost so lets put that in perspective here. > > No, unfortunately it's much worse -- the parser has to re-intern > *every* element name and attribute name during the parse, so if I have > 6,000 attributes named 'foo', I have to invoke intern 6,000 times The implementation I have in an XML Parser I wrote only calls intern on strings which are not cached. I do this mostly to reduce calls to new String().intern(). It sure would of been nice if there was a static intern method in the String class that accepted a character array and used the contents to fetch an interned string (or else create a new one if the string is not present in the VM). > (just for those attributes). When I was writing AElfred, I got > something between a 10-30% speedup (I cannot remember the number) by > dropping Java's intern and writing my own. A bad intern is a killer > for an XML parser. Yah, it is really bad if you don't do any sort of String caching as well. Sorry to confuse you here with what I meant by interning strings... Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Feb 5 01:46:56 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:38 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespacesfor XML) References: <3.0.32.19990204165540.00b57da0@pop.intergate.bc.ca> Message-ID: <36BA4D4E.1E8B1A10@infinet.com> Tim Bray wrote: > At 07:35 PM 2/4/99 -0500, David Megginson wrote: > >Tyler Baker writes: > > > > > As of JDK 1.1.6 things are not so bad and Java 2 is a bit better > > > >No, unfortunately it's much worse -- the parser has to re-intern > >*every* element name and attribute name during the parse, so if I have > >6,000 attributes named 'foo', I have to invoke intern 6,000 times > >(just for those attributes). When I was writing AElfred, I got > >something between a 10-30% speedup > > Lark too; and I just do lookup with binary search, nothing fancy, > and the difference was huge. What is Java actually doing I wonder? -T. As I said before things have improved. intern() is now native so there is really no excuse that I can think of why it should still be slow (it is not as slow as it used to be but calling it has roughly half the cost of calling new() now). Nevertheless, the String class should of had a static intern() method a long time ago that accepts a character array. Boy would it have been convenient... Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Fri Feb 5 02:07:15 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:38 2004 Subject: Component Markup Language Message-ID: <000f01be50ac$0c544980$04addccf@ix.netcom.com> >> One cannot rely on "HTML 5" as a solution to this problem >> by reading >> current Working Draft: >> http://www.w3.org/TR/1998/WD-html-in-xml-19981205/ The current working draft, as it makes clear is just part of a series of documents. This WD will lead to a simple document providing XML namespaces, and XML DTD's for XHTML. I believe the current working group will be also looking at the whole of forms and interfaces, so if people have any requirements for an HTML interface now is the time to make them known. I know that many members of the current W3C HTML WG monitor this list, and as XHTML is XML I would hope that such discusion would be proper on this list. Discussion of of HTML can also be carried out on the W3C publiic mailing lists. Frank ----- Original Message ----- From: Mark Birbeck <Mark.Birbeck@iedigital.net> To: <master@rosethorns.com>; Mark Birbeck <Mark.Birbeck@iedigital.net>; <xml-dev@ic.ac.uk> Sent: Thursday, February 04, 1999 4:01 PM Subject: RE: Component Markup Language . The next >> generation of HTML will not provide any such facilities. Information >> about the nature of the next generation HTML can be obtained >> by reading >> current Working Draft: >> http://www.w3.org/TR/1998/WD-html-in-xml-19981205/ > >Can people please be specific, so I can see if I have lost the plot >here: > >If I was to propose a component-XML DTD that began with a tag called >HTML, then others called HEAD and BODY, and it had definitions for text >fields, buttons, drop-boxes, images, tables and more, as well as being >able to call up external programs and all the rest of it; what >ADDITIONAL features is everyone saying they would want to be present in >*their* component-XML that are not in 'mine' (and I really think the >lack of graphics on a button is insufficient justification for spending >the next year writing an entire XHTML!) > >I'm not saying that the user-interface has to then be a web browser - >make it Java if you want. All I'm saying is there is a very good syntax >in place for defining user interfaces - why not use it? > >Mark Birbeck >Managing Director >Intra Extra Digital Ltd. >39 Whitfield Street >London >W1P 5RE >w: http://www.iedigital.net/ >t: 0171 681 4135 >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 bckman at ix.netcom.com Fri Feb 5 02:11:04 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:38 2004 Subject: Component Markup Language Message-ID: <000d01be50ac$07f13d80$04addccf@ix.netcom.com> >HTML 4 isn't quite up to providing a full GUI, even with the DOM. For >example you can't do menu's. Thats news to me! You can't do buttons with images on them (I'm >not talking about images that are buttons), What about the <button> element? <button> <img src="stop.gif"> <br>Stop!! </button> willl give as good a button with an image as VB or C++ you can't do tabbed dialogs >(well, you can, but it's non-trivial), It's almost trivial using CSS. Use the z layer property. I'm sure there are other things. Of >course you could add these things into HTML 5, but I don't think it's worth >going down that road. X HTML, (I don't think that I am selling any state secrets here) will include a complete rewrite of 'forms', including new interfaces. I for one, and I'm sure that other members of the HTML WG would be very interested in learning what extra needs people have for the GUI, or for information handling on the client side. Frank (speaking on my own behalf) ----- Original Message ----- From: Matthew Sergeant (EML) <Matthew.Sergeant@eml.ericsson.se> To: <xml-dev@ic.ac.uk> Sent: Thursday, February 04, 1999 12:18 PM Subject: RE: Component Markup Language >> -----Original Message----- >> From: Mark Birbeck [SMTP:Mark.Birbeck@iedigital.net] >> >> Great idea. Can I suggest we call it HTML? >> >> (OK I know I've cracked that one already - it's the end of the week. But >> really, if you want an XML specification for a user interface, surely >> HTML 4.0 is the one to choose. Then you could use a 'cool browser' that >> has an "XML GUI Interpreter" built in - like, well, IE4 and Netscape 4.) >> >HTML 4 isn't quite up to providing a full GUI, even with the DOM. For >example you can't do menu's. You can't do buttons with images on them (I'm >not talking about images that are buttons), you can't do tabbed dialogs >(well, you can, but it's non-trivial), I'm sure there are other things. Of >course you could add these things into HTML 5, but I don't think it's worth >going down that road. > >Matt. >-- >http://come.to/fastnet >Perl on Win32, PerlScript, ASP, Database, XML >GCS(GAT) d+ s:+ a-- C++ UL++>UL+++$ P++++$ E- W+++ N++ w--@$ O- M-- !V >!PS !PE Y+ PGP- t+ 5 R tv+ X++ b+ DI++ D G-- e++ h--->z+++ 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) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Fri Feb 5 02:43:40 1999 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:08:38 2004 Subject: Component Markup Language References: <A26F84C9D8EDD111A102006097C4CD0D054961@SOHOS002> Message-ID: <36BA5A3F.180A@hiwaay.net> Mark Birbeck wrote: > > If I was to propose a component-XML DTD that began with a tag called > HTML, then others called HEAD and BODY, and it had definitions for text > fields, buttons, drop-boxes, images, tables and more, as well as being > able to call up external programs and all the rest of it; what > ADDITIONAL features is everyone saying they would want to be present in > *their* component-XML that are not in 'mine' (and I really think the > lack of graphics on a button is insufficient justification for spending > the next year writing an entire XHTML!) Been there. Done that. Got the T-shirt (says, "More Meta Than Thou!") See the US Navy MID (Metafile for Interactive Documents) project. There are probably references to it from the OASIS page. I don't know if the original designs are still out there. I believe parts of it mutated into the ISMID which is an ISO project. Check with Dave Cooper and Mike Anderson. When I last looked, there wasn't much left of the original MID, but as a design project, it occupied some serious people for a few years. It was implemented several times by different teams, worked fine, and basically was condemmed as clunky and "not the way I would do it". OTOH, it met the requirements and did the job. IOW, what you want to do works fine but you have to find a market for it. len bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 02:46:04 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:38 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <36B92536.D5BF3AA0@prescod.net> Message-ID: <003701be50b0$f80fe510$d3228018@jabr.ne.mediaone.net> What I am talking about is an interface to a database. The question is: should we use an interface such as ODBC, JDBC or a proprietary interface (each vendor has one), and/or the DOM. It has been suggested that when the database is to represent an XML repository of some sort, the DOM may be one appropriate interface onto this repository. In particular object database vendors such as ODI and Poet who are offering XML databases may choose to offer a DOM interface onto the database. Relational database vendors such as Oracle may also choose to offer DOM interfaces onto the database. It has been stated that this is a misguided approach, and that what is needed is object orientation. My response is that this is comparing apples to motorcycles. Modern systems are described at different levels and this is a useful way to organize this discussion which is in danger of becoming incoherent. Many current systems are described in terms of three broad tiers: a client tier, a middleware tier and a server/database tier. When these systems are designed, there exists a need to interface the tiers. When business rules exist on a middleware tier, and these rules are designed as a set of components or objects, these 'high level' objects which contain domain specific knowledge, have a need to communicate with the database tier. Frequently a set of data access objects is defined to facilitate interface with the database. We are talking about different levels. Not for a moment am I arguing with the need for business rules. The question is how these object rules should access the database. In modern middleware/transaction processing systems, the idea is to 'dumb down' the database and place the knowledge in the business rule layer (which is above the data access layer). Two tier systems mix the business rules with the data, this leads to inefficiency. A three tier system separates the business rules from the data. Yet low level API's such as ODBC or vendor specific API's tie the business rules to the particular database engine. With proper object orientation, and use of encapsulation, it is best to uncouple the business rules from the particular database. In other cases, a data access object layer is used to couple a 'high level' or scripting language to a low level binary wire protocol. For example, Microsoft offers ADO with its Recordset. I suggest that the DOM is no less capable of modelling data than a Recordset, where a Recordset is optimized to deliver tabular data, the DOM is optimized to deliver tree data. Perhaps you don't like the DOM and have a better tree API ... great! let's see it and then if everyone agrees that it is indeed better, it can be DOM 2. The concept of the 'object repository' or 'enterprise repository' includes the idea that code and data can be mixed together in a large bucket. These systems tend to have difficulties in high transaction volume applications. They have tended to be overly complex and hence overly expensive for this reason. At the same time the proper 3 tier web application (browser client, HTTP server/middleware, back-end database) has really taken off in the last couple of years (ask Dell :-) By maintaining a distinct business rules layer from the data access layer, the system can be more easily organized and more easily modified. This leads to higher reliability and lower cost. These are good things. So lets compare apples to apples. Which data access API do you wish to use? This API is specifically required to be used by business rules to access data stores. Paul Prescod wrote: > > Right. XML is a serialization. The DOM is an abstraction of a > serialization. Not an abstraction over your data. With objects, the data and code are tied together, we have the idea of a 'live' object and a persisted object. The idea of activating a persisted object means that the persistant object data (e.g. a file) is parsed to restore object state. A DOM object isn't so much an abstraction of a serialization as it is a live 'bucket' of XML data (it is a simple data access object). Business rules operate on data objects in the same way that a JavaScript program can use a DOM object to process some information. If your "problem" is > representing debit card bank accounts the proper abstraction over that is > "bank account" or "currency account". The *wrong* abstraction is "elements > and attributes." Comparing apples to apples, the DOM has elements and attributes, and a Recordset has rows and columns. Most bank accounts in the world today are well represented as rows and columns. There are times when the slightly more complex concept of elements and attributes has a better impedance match to the data being modelled than rows and columns. > > XML is very simple. "All the world's data" is very complex. That's why we > need XLink, RDF, HyTime and a bunch of other stuff. If your API to "your > data" is simply the DOM then you are temporarily hiding its complexity > behind a simple layer that can *NOT* express its "linkedness", its complex > class relationships, is geographical 2D-ness etc. I don't know your data. > I don't know what makes it complex but if your job is interesting it IS > complex and the DOM does not help you to manage that complexity. That's right, that's why *I* need to model my domain using *my* business rules. And assuming I don't want to code my own database, I need an API that allows me to store my stuff. > > > It is a big mistake to assume that XSL is only to be > used for 'styling for > > the Web or print'. DSSSL as we know is based upon or employs > Scheme. Scheme > > is a full fledged programming language, a dialect of LISP. XSL > does not have > > the Scheme counterpart to DSSSL, rather it is itself its own programming > > language (albeit currently simplistic). > > XSL is not a programming language according to the Turing/Church > definition. Perhaps not yet, but if I want to automate transforms, XSL or the transformation language subset 'XTL' is a leap in the right direction. A large part of computer programming consists of interfacing one API to another. I'm not saying that XSL helps with this at all but pointing out that transformations and impedance matching is an important task. If we have the ability to express transforms directly this greatly reduces the need to do traditional coding and bit twiddling. 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 clark.evans at manhattanproject.com Fri Feb 5 03:27:26 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:38 2004 Subject: HDBMS vs RDBMS (Was: Re: Storing Lots of Fiddly Bits (was Re: What is XML for?)) References: <003701be50b0$f80fe510$d3228018@jabr.ne.mediaone.net> Message-ID: <36BA643D.BC1AA23A@manhattanproject.com> Jonathan, First, I like what you wrote. It makes sense to me. :) "Borden, Jonathan" wrote: > > Comparing apples to apples, the DOM has elements and attributes, and a > Recordset has rows and columns. Most bank accounts in the world today are > well represented as rows and columns. There are times when the slightly more > complex concept of elements and attributes has a better impedance match to > the data being modelled than rows and columns. This is, in essence, the debate of the 70's between the hierarchical model (HDBMS) and the relational model (RDBMS). The relational people "won", in part, beacuse they had a mathematical theory which formally defined how their database works. I see MURATA Makoto's work as being the mathematical formalism required to explain how a hierarchical database would work. This to me is exciting. If anything, I would say that any *reasonable* database in the future must handle both and what would be wonderful to see is a mathematical formalism that allowed both perspectives to work in a complementary fashon. Already, relational databases are adding hierarchical features, witness the "CONNECT BY" clause in Oracle. And, the hierarchical people are busily adding relational features (XML Link). I think the problem is that the data needs to be both viewed as a set of relations _and_ as a hierarchy. I feel that it will be tempting to "toss out" relational theory in favor of hierarchial databases. I think the true solution will involve some sort of "DUAL" which allows for a gateway between the "world of sets" and the "world of trees". Perhaps objects provide the language necessary to unify these two different pictures of information. > Perhaps not yet, but if I want to automate transforms, XSL or the > transformation language subset 'XTL' is a leap in the right direction. A > large part of computer programming consists of interfacing one API to > another. I'm not saying that XSL helps with this at all but pointing out > that transformations and impedance matching is an important task. If we have > the ability to express transforms directly this greatly reduces the need to > do traditional coding and bit twiddling. The XTL is, in effect, the equivalent of SQL for a relational database. An SQL statement takes one or more relations and produces another relation. So true that XTL will do a similar thing to trees. This is indeed very exciting. After XTL is worked out, then we only have two more transformations left, RDBMS->HDBMS and HDBMS->RDBMS. And neither of these is trivial. Thoughts? Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 04:09:53 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:38 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <36B93A9A.EEC43FFB@manhattanproject.com> Message-ID: <000101be50bc$bc0d8930$d3228018@jabr.ne.mediaone.net> Clark Evans wrote: > Therefore, I picture a DOM implementation > using thousands of nested queries to generate > the same tree that a few large queries would have > handled nicely. In this case, the database > engine would not be able to take advantage > of aggregate indexing and elimination > algorithems. In effect, negating the benifits > of having corporate information in a relational > database. *smile* This is a good point, the problem with the relational model is that the few large queries flatten the hierarchy into a table. Another approach is to use data shaping to create hierarchical recordsets. A third approach is to let the database vendors optimize the queries internally when XML is to be returned. This would seem to be the optimal situation and data shaping/OLAP techniques fit here ... remember "Arbor Software" is an OLAP vendor. > > Anyway, I just can't picture using DOM in this > context as an interface to a relational database. > For this case I feel using a stream-oriented solution > on the server with an object-oriented event processing > system on the client seems the better approach. > > Again, the db/OLAP vendors might be able to squeeze some performance out of the interface that we couldn't once the data has left the engine. just a thought. 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 clark.evans at manhattanproject.com Fri Feb 5 05:02:36 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:38 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <000101be50bc$bc0d8930$d3228018@jabr.ne.mediaone.net> Message-ID: <36BA7AAB.160E9065@manhattanproject.com> Jonathan Borden wrote: > Another approach is to use data shaping to create hierarchical recordsets. This is what I did at Ford Motor Co., it gets messy quick. Even when the table is a snapshot. Nothing like a big hierarchical table with 400 columns. *evil grin* > A third approach is to let the database vendors optimize the queries > internally when XML is to be returned. This would seem to be the > optimal situation and data shaping/OLAP techniques fit here ... > remember "Arbor Software" is an OLAP vendor. Nice. This could be the beginnings of a HDBMS/RDBMS blend. That'd be cool. The danger is thinking that OLAP (HDBMS) is the total answer. It is almost impossible to avoid duplication in a hierarchical database. For transaction processing, I bet that a relational database will still be the best solution. Ballance, Clark ----------------------------------------------------- software n : 1. written programs or procedures or rules and associated documentation pertaining to the operation of a computer system. 2. applied philosophy xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Feb 5 05:22:06 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:38 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <003701be50b0$f80fe510$d3228018@jabr.ne.mediaone.net> Message-ID: <36BA7E38.D2B7E33B@prescod.net> "Borden, Jonathan" wrote: > ...[lots and lots] ... and then ... > So lets compare apples to apples. Which data access API do you wish to use? I don't want an API. I want layers of objects. At the bottom level I have either storage objects or records in a table. At the higher layers I have abstractions over those objects. Using objects I can build a 1-tier, 2-tier, 3-tier or n-tier system. I can have as many levels of business rules and clients and servers as I need. I can also query objects and build object schemas using standardized, multiply-implemented languages. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matt at veosystems.com Fri Feb 5 08:05:24 1999 From: matt at veosystems.com (matt@veosystems.com) Date: Mon Jun 7 17:08:38 2004 Subject: Component Markup Language In-Reply-To: <4EB3E7E7.1B5AD737@darmstadt.gmd.de> from "Robb Shecter" at Nov 4, 11 02:25:59 pm Message-ID: <19990205080503.30544.qmail@veosystems.com> Robb, You might find an old paper of mine - The User Interface as Document - interesting. It's still available from my old NYU home page at http://cs.nyu.edu/phd_students/fuchs Matthew Fuchs matt@veosystems.com now with CommerceOne > > Hi, > > Has anyone thought about or worked on an markup language to describe a > User Interface in a platform independent way? > > I'd think that this would language would describe: instantiating > components, adding them to containers, and configuring interactions > between them. > > Thanks, > - Robb > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hpyle at agora.co.uk Fri Feb 5 08:34:22 1999 From: hpyle at agora.co.uk (hpyle@agora.co.uk) Date: Mon Jun 7 17:08:39 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces for XML) Message-ID: <8025670F.002EF9AD.00@mailhost.agora.co.uk> Tyler wrote, > If XML is ever going to be editable by an average > internet user for some common tasks, meaningful prefixes do matter. Can I ask for some "average user" stuff here? Now that the namespace arguments have been rounded up a few times. Although James Clarks' page does explain the state of affairs very clearly, it's still talking to the wrong people. What I & my other average-developer colleagues need is more like a "cookbook". Not the intricacies of why flour plus butter behave so strangely; we need to know how to roll the pastry out. Current interest in XML - in the absence of many standardised industry DTDs - means there's a pressing need to explain how to design sensible XML structures. Whilst there are plenty of XML examples appearing on the Web, few of them are well-designed (my pet peeve: people coding a date as "2/21/99"). Namespaces seem to be an essential solution to two problems encountered when designing XML stuctures: - how can I distinguish my tags from everyone else's, to avoid confusion (eg: "<my:pastry/>"); - how can I use a common repository of meaningful tags at the same time (eg: "<frozen:pastry><my:sauce iso:litres_quantity="0.5"/></frozen:pastry>") With a few examples. Finally, we need directions to the local pizza house... -Hugh agora hpyle@agora.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Fri Feb 5 09:01:27 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:39 2004 Subject: CORBA's not boring yet. / XML in an OS? Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AF6@eukbant101.ericsson.se> > -----Original Message----- > From: Robb Shecter [SMTP:shecter@darmstadt.gmd.de] > > Anyhow, this naturally makes me wonder - could XML and related ideas > like XSL have a place in an operating system? Where would they fit in? > KDE and Gnome could be great playgrounds for trying something like this > out. > Gnome already does. It ships with a libxml if you look at it. I'm not sure how much it's used yet, but the Linux people are really grabbing XML by the horns. Both AbiWord and KWord (2 new word processors) have their native file format as XML. 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 Matthew.Sergeant at eml.ericsson.se Fri Feb 5 09:05:10 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:39 2004 Subject: A weaker XSL? Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AF7@eukbant101.ericsson.se> > -----Original Message----- > From: Clark Evans [SMTP:clark.evans@manhattanproject.com] > > Paul Prescod wrote: > > Exactly :) With a weak-XSL you coudn't build the table of > contents BEFORE the entire stream is read, the same with > sorting, you can't do it before the entire stream is read. > > However, it can do other things, like turning a <catalog> > into a <table>, building a index or trailing table of > contents, etc. Thus it still has use for translating > XML into HTML and other output forms, while not requiring > the memory and processing overhead. > I might have misunderstood, but what's the point of XSL in that case then? Why not just use perl to do s/<(\/?)catalog>/<$1table>/ ? (obviously you can be more complete than this, I just wanted a simple example). 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 oren at capella.co.il Fri Feb 5 09:32:59 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:08:39 2004 Subject: Fw: Namespaces does *not* formally introduce "global attributes" Message-ID: <007701be50e9$c95670c0$5402a8c0@oren.capella.co.il> Ooops, sent this to the wrong lost. Sorry. -----Original Message----- >I asked: >>>Actually, has anyone already written a SAX filter which implements >>>namespaces this way? Is anyone interested? Let's settle this once and for >>>all - "proof by implementation" :-) > >Bill la Forge <b.laforge@jxml.com> wrote: >>Well, there's John Cowan's filter: >> >> http://www.ccil.org/~cowan/XML/NamespaceFilter.java > > >Thanks - and thanks, John. Just the thing. I hope this lays the issue to >rest... > >Share & Enjoy, > > Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Matthew.Sergeant at eml.ericsson.se Fri Feb 5 09:36:03 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:39 2004 Subject: CORBA's not boring yet. / XML in an OS? Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AF9@eukbant101.ericsson.se> > -----Original Message----- > From: Dave Winer [SMTP:dave@userland.com] > > Gotta check it out! XML-RPC.. What CORBA wants to be. ;-> > > http://www.xmlrpc.com/ > Isn't RPC using IIOP and DCOM already slow enough without using XML? Why don't MS just support IIOP? 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 Matthew.Sergeant at eml.ericsson.se Fri Feb 5 09:48:58 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:39 2004 Subject: Component Markup Language Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136AFA@eukbant101.ericsson.se> > -----Original Message----- > From: Frank Boumphrey [SMTP:bckman@ix.netcom.com] > > >HTML 4 isn't quite up to providing a full GUI, even with the DOM. For > >example you can't do menu's. > > Thats news to me! > The HTML WG seem to have a different concept of what menus are to normal application developers. I mean an application that has it's own window with it's own menus. No back button - the window should be totally defined by the XML. Without using Javascript tricks. I didn't mean the <select> tag - or even the deprecated <menu> tag. I mean drop down menus that can have submenus. > You can't do buttons with images on them (I'm > >not talking about images that are buttons), > > What about the <button> element? > > <button> > <img src="stop.gif"> > <br>Stop!! > </button> > > willl give as good a button with an image as VB or C++ > :-) Missed that I guess. > you can't do tabbed dialogs > >(well, you can, but it's non-trivial), > > It's almost trivial using CSS. Use the z layer property. > Yes - almost trivial, but the design of the tabs is up to the designer - it's not provided by the OS. > I'm sure there are other things. Of > >course you could add these things into HTML 5, but I don't think it's > worth > >going down that road. > > X HTML, (I don't think that I am selling any state secrets here) will > include a complete rewrite of 'forms', including new interfaces. > > I for one, and I'm sure that other members of the HTML WG would be very > interested in learning what extra needs people have for the GUI, or for > information handling on the client side. > Well, I think we're really talking apples and oranges here. I want to be able to write applications in XML, with some embedded Javascript, or Perl. I don't want to write forms because then I'm stuck with the whole of the browser (i.e. it's buttons and menus, or I can open a new window with no buttons and menus, but then I can't add menus, and the buttons don't integrate as a toolbar, and I can't have a nicely integrated status bar...). Basically I want XUIL - and I can't wait until it's ready for prime time. 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 rbourret at ito.tu-darmstadt.de Fri Feb 5 10:03:20 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:39 2004 Subject: Namespace clashes? Message-ID: <01BE50F6.34DD5550@grappa.ito.tu-darmstadt.de> Nikita Ogievetsky wrote: > I thought of namespace prefixes as aliases. If parser is capable > to resolve alias <=> alias definition than it should not matter which > alias one uses to define the same namespace? Correct. But in the question asked, the prefixes resolved to different namespaces. -- 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 dave at userland.com Fri Feb 5 12:58:35 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:39 2004 Subject: CORBA's not boring yet. / XML in an OS? In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136AF9@eukbant101.ericss on.se> Message-ID: <3.0.6.32.19990205050217.00f49460@scripting.com> >>Isn't RPC using IIOP and DCOM already slow enough without using XML? Why don't MS just support IIOP? I don't know why MS does anything, I don't work there. I know why I like XML-RPC. It's simple. You can write a client in a few hours, and a server in a couple of days. A JavaScript programmer can learn how to do it, today, in less than 24 hours, and in a few weeks, they'll be able to do it in minutes. I have some theories about why this is true: 1. HTTP is everywhere. Does IIOP run on my machine? I'm pretty sure it doesn't. And it's not just about Microsoft, I have Macs too. 2. XML looks like HTML. To someone who has mastered HTML the transition is easy. Performance matters, for sure. But sometimes people overlook that people performance is probably the single most important limiting factor. I can tell you this, CORBA wasn't designed for my mind. It's so complicated, so many new concepts to understand. I even had trouble understanding HTML way back when. Wire protocols can be optimized, but people's brains move at their own rate, rejecting things that appear too complicated, waiting for something that makes sense to them. We're all busy! The problem with COM, CORBA and Apple Events is that each of them were invented before the web exploded and are quite platform specific, and are not understandable to people who do web development. Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Veillard at w3.org Fri Feb 5 13:37:02 1999 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:08:39 2004 Subject: CORBA's not boring yet. / XML in an OS? In-Reply-To: <5F052F2A01FBD11184F00008C7A4A80001136AF6@eukbant101.ericsson.se>; from Matthew Sergeant (EML) on Fri, Feb 05, 1999 at 10:01:00AM +0100 References: <5F052F2A01FBD11184F00008C7A4A80001136AF6@eukbant101.ericsson.se> Message-ID: <19990205083605.Q25569@w3.org> Quoting Matthew Sergeant (EML) (Matthew.Sergeant@eml.ericsson.se): > > -----Original Message----- > > From: Robb Shecter [SMTP:shecter@darmstadt.gmd.de] > > > > Anyhow, this naturally makes me wonder - could XML and related ideas > > like XSL have a place in an operating system? Where would they fit in? > > KDE and Gnome could be great playgrounds for trying something like this > > out. > > > Gnome already does. It ships with a libxml if you look at it. I'm > not sure how much it's used yet, but the Linux people are really grabbing > XML by the horns. Both AbiWord and KWord (2 new word processors) have their > native file format as XML. I happen to be the author of that library. It's in use at least in the Gnumeric and Gwp, i.e. the spreadsheet and word processor, (gzipped) XML is the native format for those. I know that a couple of other Gnome project uses that library too. XML is very much in the spirit of Linux, and this community will certainly be very active as soon as XML will be seen as the best platform and tool independant exchange format. Daniel (not speaking for W3C in that case) -- [Yes, I have moved back to France !] Daniel.Veillard@w3.org | W3C INRIA Rhone-Alpes | Today's Bookmarks : Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind, Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, Kaffe, http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Amaya. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From CBenedet at Bluestone.com Fri Feb 5 13:44:54 1999 From: CBenedet at Bluestone.com (Benedetto, Christopher) Date: Mon Jun 7 17:08:39 2004 Subject: No subject Message-ID: <9A4DF69E3C5ED211B86400A0C9D17760847234@thor.operations.bluestone.com> unsubscribe xml-dev ============================================ Christopher Benedetto Product Manager Phone: (609) 727-4600 ext. 3024 Fax: (609) 727-5077 Bluestone Software, Inc. 1000 Briggs Road Mt. Laurel, NJ 08054 mailto:cbenedet@bluestone.com http://www.bluestone.com ============================================ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 13:55:29 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:39 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces for XML) In-Reply-To: <8025670F.002EF9AD.00@mailhost.agora.co.uk> Message-ID: <199902051355.IAA32750@hesketh.net> At 07:37 AM 2/5/99 +0000, hpyle@agora.co.uk wrote: >Can I ask for some "average user" stuff here? Now that the namespace >arguments have been rounded up a few times. > >Although James Clarks' page does explain the state of affairs very clearly, >it's still talking to the wrong people. What I & my other >average-developer colleagues need is more like a "cookbook". Not the >intricacies of why flour plus butter behave so strangely; we need to know >how to roll the pastry out. I've been attempting to cover namespaces intelligibly in my latest books, though none of them have appeared yet. Given the controversy, it's not surprising that most 'explanations' are directed at the weirdness and not the simplicity. I may give it a crack and attempt to post a tutorial when I finish these last two books... >Current interest in XML - in the absence of many standardised industry DTDs >- means there's a pressing need to explain how to design sensible XML >structures. Whilst there are plenty of XML examples appearing on the Web, >few of them are well-designed (my pet peeve: people coding a date as >"2/21/99"). Namespaces seem to be an essential solution to two problems >encountered when designing XML stuctures: >- how can I distinguish my tags from everyone else's, to avoid confusion >(eg: "<my:pastry/>"); >- how can I use a common repository of meaningful tags at the same time >(eg: "<frozen:pastry><my:sauce >iso:litres_quantity="0.5"/></frozen:pastry>") >With a few examples. Finally, we need directions to the local pizza >house... I'd love to see a 'good examples and best practices'-oriented site for XML, but haven't found one yet, though there are pieces everywhere. David Megginson and Rick Jelliffe's books are close, but both are pre-namespaces as well. Now, about that pizza house... Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 Mark.Birbeck at iedigital.net Fri Feb 5 13:57:07 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:39 2004 Subject: Namespaces does *not* formally introduce "global attributes" Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054968@SOHOS002> > Additionally, implementers would have been able to easily add > a namespace > processing module on top of their current XML parsers (a SAX namespace > expansion filter, for example, is trivial when implemented this way), > _without changing the interfaces_. Future implementations > might use better > interfaces - such as APIs for accessing just the "namespace > part" or the > "local part" of an expanded name - but the point is every XML > application > would go on working as it is, without any changes. Reminds me of a question I had a while back: what happens to a perfectly acceptable XML 1.0 document run through an XML parser which has a namespace processing module? This is, after all, valid XML 1.0: <this:is:my:good this:is:an:attribute:called:a1="1" /> (As is: <:::: :::="1" /> ) In terms of the old document run through the new parser, as far as namespaces go this should be no different to: <good a1="1" /> But in the new parsers it will be an error, because, as the spec says, "The namespace prefix, unless it is xml or xmlns, must have been declared ..." It seems that XML namespaces are not backwards compatible with 'old' documents. If this is true, is it explicitly justified anywhere? I haven't come across it. Perhaps it is the intention of the spec that a 'non-conformant' document (i.e., more than one colon in names, etc.) simply 'drops back' to XML 1.0, rather than being 'failed' by the namespace processor. But this then means you couldn't merge two DTDs in a document - one built with namespaces in mind, and one not. Maybe another approach is that if a prefix is *not* declared using an xmlns tag then the prefix and its local name are to all intents and purposes just one name. This would allow you to mix DTDs, as I mention, but would then mean you don't have 'conforming and non-conforming' documents, you have 'conforming and non-conforming' elements - but it would work. And maybe none of this matters and we're just assuming that XML is 'young' enough for us to catch the problem early, everyone is already starting to conform, and in which case on completion of the namespaces spec we would have to declare XML 1.1, and say that it is *not* backwards compatible. Anyway, I would be interested to know if anyone has seen an explicit reference to this - either saying I'm wrong and namespaces *are* backwards compatible, or justifying why it is OK to not be backwards compatible. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 paul at prescod.net Fri Feb 5 13:58:19 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:39 2004 Subject: A weaker XSL? References: <5F052F2A01FBD11184F00008C7A4A80001136AF7@eukbant101.ericsson.se> Message-ID: <36BAF65C.4FFD371B@prescod.net> "Matthew Sergeant (EML)" wrote: > > I might have misunderstood, but what's the point of XSL in that case > then? Why not just use perl to do s/<(\/?)catalog>/<$1table>/ ? > > (obviously you can be more complete than this, I just wanted a > simple example). That's an odd question. I don't see that there are some problems that are "too simple" for XSL. The simpler the problem, the more sense it makes to use XSL. We use XSL because it is: * standardized * declarative * optimizable * can be implemented in the heart of a repository * has many competing implementations We use Python because it is: * flexible * highly extensible * has a powerful standard library I'm told that these are reasons also to use Perl if you can stand it. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 14:08:49 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:39 2004 Subject: Namespaces does *not* formally introduce "global attributes" In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D054968@SOHOS002> References: <A26F84C9D8EDD111A102006097C4CD0D054968@SOHOS002> Message-ID: <14010.64038.298058.609899@localhost.localdomain> Mark Birbeck writes: > Reminds me of a question I had a while back: what happens to a perfectly > acceptable XML 1.0 document run through an XML parser which has a > namespace processing module? This is, after all, valid XML 1.0: > > <this:is:my:good this:is:an:attribute:called:a1="1" /> > > (As is: > > <:::: :::="1" /> > > ) Exactly. XML 1.0 remains in force, so for general-purpose XML parsers, namespace processing needs to be an optional feature, enabled at user discretion (as it is in Expat). Dedicated tools for RDF, XSL, etc. will, of course, need namespace processing on. Further to this topic, the following note does appear in the XML 1.0 spec: Note: The colon character within XML names is reserved for experimentation with name spaces. Its meaning is expected to be standardized at some future point, at which point those documents using the colon for experimental purposes may need to be updated. (There is no guarantee that any name-space mechanism adopted for XML will in fact use the colon as a name-space delimiter.) In practice, this means that authors should not use the colon in XML names except as part of name-space experiments, but that XML processors should accept the colon as a name character. In other words, you're allowed to use ':' for non-namespace purposes but you're playing with fire if you do. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Feb 5 14:10:26 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:39 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces forXML) References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> Message-ID: <36BAF974.6F87E679@prescod.net> hpyle@agora.co.uk wrote: > > Although James Clarks' page does explain the state of affairs very clearly, > it's still talking to the wrong people. I don't think that "average developers" need to worry about namespaces. It is quite simple to build powerful, useful applications without them. I mean if you are implementing RDF or XSL then you need them, but short of that, I wouldn't bother. > Namespaces seem to be an essential solution to two problems > encountered when designing XML stuctures: > - how can I distinguish my tags from everyone else's, to avoid confusion > (eg: "<my:pastry/>"); Actually, this problem is very RARELY encountered. If you are building a typical one-organization application then what are you doing with "other people's tags" in your documents? I mean, if you are writing typical software, it will choke and die when it comes upon tags it does not know about. > - how can I use a common repository of meaningful tags at the same time > (eg: "<frozen:pastry><my:sauce > iso:litres_quantity="0.5"/></frozen:pastry>") You don't need namespaces for that. Just create a "liters_quantity" element type and include it in your various DTDs with parameter entities. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 14:12:39 1999 From: Matthew.Sergeant at eml.ericsson.se (Matthew Sergeant (EML)) Date: Mon Jun 7 17:08:39 2004 Subject: A weaker XSL? Message-ID: <5F052F2A01FBD11184F00008C7A4A80001136B01@eukbant101.ericsson.se> > -----Original Message----- > From: Paul Prescod [SMTP:paul@prescod.net] > > "Matthew Sergeant (EML)" wrote: > > > > I might have misunderstood, but what's the point of XSL in that > case > > then? Why not just use perl to do s/<(\/?)catalog>/<$1table>/ ? > > > > (obviously you can be more complete than this, I just wanted a > > simple example). > > That's an odd question. I don't see that there are some problems that are > "too simple" for XSL. The simpler the problem, the more sense it makes to > use XSL. > I guess what I should have said was "Why not use CSS then". If we're talking about an XSL that doesn't do transformations then it's CSS you should use. The perl example I guess was a bad idea, but I just meant what we seemed to be talking about was tag matching/replacing with programmability. CSS2 covers that. > I'm told that these are reasons also to use Perl if you can stand it. > You missed a smiley there I assume. 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 skshirsa at nortelnetworks.com Fri Feb 5 14:26:58 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:08:40 2004 Subject: 'How to unsubscribe?' information is attached to every mail. Message-ID: <3.0.32.19990205092431.0072499c@bl-mail2.corpeast.baynetworks.com> In spite of the fact that "hot to unsubscribe" information is attached to each an devery mail, I don't know why do people broadcast their message to unsubscribe. At 08:39 AM 2/5/99 -0500, Benedetto, Christopher wrote: >unsubscribe xml-dev > >============================================ >Christopher Benedetto >Product Manager >Phone: (609) 727-4600 ext. 3024 >Fax: (609) 727-5077 >Bluestone Software, Inc. >1000 Briggs Road >Mt. Laurel, NJ 08054 >mailto:cbenedet@bluestone.com >http://www.bluestone.com >============================================ > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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 dave at userland.com Fri Feb 5 14:31:56 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:40 2004 Subject: HTML, XML, XML-RPC in one net app Message-ID: <3.0.6.32.19990205063526.00f64140@scripting.com> We're getting close to releasing Frontier 6, and as part of that process we created a demo app that's accessible thru HTML, XML and XML-RPC. The app is now on the air, ready for you to check out and think about and possibly learn from. ***HTML interface First, here's the HTML interface. http://www.mailtothefuture.com/ Please log on, get a password, create a message or two, became familiar with how it works from a user's point of view. You'll definitely want to have a couple of messages in your queue to try out the other examples. ***XML interface Now, thru your web browser, visit these two pages: http://www.mailtothefuture.com/msgcounter.xml http://www.mailtothefuture.com/msgreader.xml$1 There you go, dynamic XML. Now, what's it good for? Not much, because you also want to be able to add a message or delete a message, and for that you need to make a procedure call. ***XML-RPC interface The XML-RPC interface is documented on this page: http://www.mailtothefuture.com/public/techInfo There are five procedures: mailToTheFuture.addMessage (username, password, msgstruct) mailToTheFuture.deleteMessage (username, password, n) mailToTheFuture.getAllMessages (username, password) mailToTheFuture.getMessage (username, password, msgnum) mailToTheFuture.getMessageCount (username, password) With these five procedures you can access all the functionality of the server without coming in thru the HTML interface. ***Next steps We've already got XML-RPC clients running in the following environments: Python, Perl, Java, Frontier, and are close to having a clean interface to JavaScript running in the popular web browsers. Thru this interface, applications can use the W3C DOM or other XML APIs to walk structures on the MTTF server. We're working with a talented UI development team lead by Marc Canter, the lead developer of Macromedia Director. To us it's a black-box, we've provided wires into our server, and the designers have already figured out how to hook in. We'll go back over their work when they're ready and create a simple browser-based API for calling into our server, and optimize their interface in the CMS running on the server. ***Beyond Hello World I know that many of you on this list weren't involved in the evolution of system scripting on the Mac, but this is feeling a lot like that, this is a simple demo app that's functional and interesting enough to motivate applications, but simple enough so that it isn't a huge chore. We're beyond the Hello World stage in the XML-RPC world. ***Crossing boundaries And XML-RPC is now meeting one of its other objectives, it crosses platform boundaries. We have XML-RPC servers running in Java, Python, Apache, Perl and Frontier. We want XML-RPC to go everywhere, crossing not just technical boundaries, but connecting the open source communities with commercial developers and system integrators. The MTTF server can be cloned in all those environments, and as long as it supports the same XML-RPC interfaces, you can swap a Windows NT server for a Linux server, or vice versa. That may be the most revolutionary feature of XML-RPC. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Michael.Kay at icl.com Fri Feb 5 14:48:47 1999 From: Michael.Kay at icl.com (Michael.Kay@icl.com) Date: Mon Jun 7 17:08:40 2004 Subject: A weaker XSL? Message-ID: <93CB64052F94D211BC5D0010A80013310EB2DA@WWMESS3> > > How do I build a table of contents that is output BEFORE the document > without reading the whole input before I start to output? > You can't, and that isn't my objective. What you can do, and what I currently do with SAXON, is to perform a single serial pass of the input document that simultaneously generates a TOC and the main rendered document on two separate output streams, then merge these together for presentation. This is far more efficient with a large document than building the entire document tree in memory or scanning it twice. 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 hpyle at agora.co.uk Fri Feb 5 14:50:40 1999 From: hpyle at agora.co.uk (hpyle@agora.co.uk) Date: Mon Jun 7 17:08:40 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces forXML) Message-ID: <8025670F.005165A0.00@mailhost.agora.co.uk> Paul Prescod wrote, > I don't think that "average developers" need to worry about namespaces. ... > If you are building a > typical one-organization application then what are you doing with "other > people's tags" in your documents? Maybe my perspective is a little warped. I'm working on healthcare applications in the UK - interoperability will (sometime) become a big deal. :-) -Hugh agora hpyle@agora.co.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 paul at prescod.net Fri Feb 5 14:56:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:40 2004 Subject: A weaker XSL? References: <5F052F2A01FBD11184F00008C7A4A80001136B01@eukbant101.ericsson.se> Message-ID: <36BB012C.9F11672C@prescod.net> "Matthew Sergeant (EML)" wrote: > > I guess what I should have said was "Why not use CSS then". If we're > talking about an XSL that doesn't do transformations then it's CSS you > should use. The perl example I guess was a bad idea, but I just meant what > we seemed to be talking about was tag matching/replacing with > programmability. CSS2 covers that. I could be wrong, but I don't believe that CSS2 can take XML conforming to one DTD and transform it into XML conforming to another DTD. There is a transformation language called "STTS3" based on CSS syntax but I must admit that I would prefer to see a simple transformation language use a subset of XSL syntax. > > I'm told that these are reasons also to use Perl if you can stand it. > > > You missed a smiley there I assume. >From the Simpson's: Teenager 1: "Man, that cannonball guy is so cool." Teenager 2: "Er. Are you being sarcastic?" Teenager 1: "Uh. Hmm. I can't even tell anymore." -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 15:00:21 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:40 2004 Subject: New XML Resources page (Re: Using XSL as a Validation Language) Message-ID: <007801be5118$752645a0$5ef96d8c@NT.JELLIFFE.COM.AU> From: Robin Cover <robin@isogen.com> >Hello Rick. Re below: I posted a blurb on my news page. Thanks Robin. >I'd also like to have the URL (did I miss it??) so as to track revisions. The "Chinese XML Now! " site is a project to help developers of Chinese XML Software. The URL is http://www.ascc.net/xml/ We are pleased to announce a page "XML and SGML Resources" in which we are putting some of the results of our research and development: software, declarations, documentation, turials, and technology notes. The URL is http://www.ascc.net/xml/en/utf-8/resource_index.html In the initial offering of this page are: 1) Three SGML declarations for Big5 2) The article "Using XSL as a Structure Validation Language" 3) A new article "lineDataWrap: An Element Set for Line-Delimited Records" , which describes an element set for handling database "dumps" , e.g. comma-delimited lines (CDL). 4) The accompanying "lineDataWrap" DTD. In the next week we plan to augment this with: 5) A lines->XML tranformation software based on the lineDataWrap DTD 6) Updated versions of the "XMLized" ISO public entity sets 7) Misc. XML utilities 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 bckman at ix.netcom.com Fri Feb 5 15:06:58 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:40 2004 Subject: Component Markup Language Message-ID: <005801be5118$e59a1d20$96acdccf@ix.netcom.com> Matthew wrote: >>Well, I think we're really talking apples and oranges here. I want to be able to write applications in XML, with some embedded Javascript, or Perl. I don't want to write forms because then I'm stuck with the whole of the browser (i.e. it's buttons and menus, or I can open a new window with no buttons and menus, but then I can't add menus, and the buttons don't integrate as a toolbar, and I can't have a nicely integrated status bar...). Basically I want XUIL - and I can't wait until it's ready for prime time.<< The problem here is that to be 'cross platform' one needs a layer between the XML+script, and the platforms API. That essentially means either using Java or a preexisting interface such as a browser or a word processor. I myself use XML and a VB interface to create what you are trying to achieve. I simply pass my insructions to in XML to my VB application. This of course that is not cross platform. Frank ----- Original Message ----- From: Matthew Sergeant (EML) <Matthew.Sergeant@eml.ericsson.se> To: <xml-dev@ic.ac.uk> Sent: Friday, February 05, 1999 4:48 AM Subject: RE: Component Markup Language >> -----Original Message----- >> From: Frank Boumphrey [SMTP:bckman@ix.netcom.com] >> >> >HTML 4 isn't quite up to providing a full GUI, even with the DOM. For >> >example you can't do menu's. >> >> Thats news to me! >> > The HTML WG seem to have a different concept of what menus are to >normal application developers. I mean an application that has it's own >window with it's own menus. No back button - the window should be totally >defined by the XML. Without using Javascript tricks. I didn't mean the ><select> tag - or even the deprecated <menu> tag. I mean drop down menus >that can have submenus. > >> You can't do buttons with images on them (I'm >> >not talking about images that are buttons), >> >> What about the <button> element? >> >> <button> >> <img src="stop.gif"> >> <br>Stop!! >> </button> >> >> willl give as good a button with an image as VB or C++ >> > :-) Missed that I guess. > >> you can't do tabbed dialogs >> >(well, you can, but it's non-trivial), >> >> It's almost trivial using CSS. Use the z layer property. >> > Yes - almost trivial, but the design of the tabs is up to the >designer - it's not provided by the OS. > >> I'm sure there are other things. Of >> >course you could add these things into HTML 5, but I don't think it's >> worth >> >going down that road. >> >> X HTML, (I don't think that I am selling any state secrets here) will >> include a complete rewrite of 'forms', including new interfaces. >> >> I for one, and I'm sure that other members of the HTML WG would be very >> interested in learning what extra needs people have for the GUI, or for >> information handling on the client side. >> > Well, I think we're really talking apples and oranges here. I want >to be able to write applications in XML, with some embedded Javascript, or >Perl. I don't want to write forms because then I'm stuck with the whole of >the browser (i.e. it's buttons and menus, or I can open a new window with no >buttons and menus, but then I can't add menus, and the buttons don't >integrate as a toolbar, and I can't have a nicely integrated status bar...). >Basically I want XUIL - and I can't wait until it's ready for prime time. > > 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 simonstl at simonstl.com Fri Feb 5 15:13:25 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:40 2004 Subject: Colonialism, SAX, Java, and Namespaces In-Reply-To: <36BAF974.6F87E679@prescod.net> References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> Message-ID: <199902051513.KAA01453@hesketh.net> <vent temp="2000"> At 08:00 AM 2/5/99 -0600, Paul Prescod wrote: >I don't think that "average developers" need to worry about namespaces. It >is quite simple to build powerful, useful applications without them. I >mean if you are implementing RDF or XSL then you need them, but short of >that, I wouldn't bother. I would really appreciate if someday the people building W3C specs would acknowledge that 'average developers' actually do have to worry about namespaces, notations, parameter entities, include/ignore sections, and trying to read the specs themselves. If they would then take that knowledge and apply it to the specification-writing process, from start to finish, we might be able to move forward with a lot less back-and-forth about what these things are really supposed to mean. I get the feeling that some of the writers on this list - though _certainly_ not all - view the 'average developer' as some kind of primitive creature that should be shunted aside in the name of progress. This colonialist view (I don't know what else to compare it to - simple elitism seems inadequate) has contributed to the development of a lot of tools that people talk about but very few people understand. If, instead of treating average developers as know-nothings to be conquered (they don't need to know the details, they just need to use it), we treat average developers as potential contributors, we might move farther along with XML. Namespaces themselves, in most cases, aren't that hard to use. They do, however, contain the potential for disaster if applied in certain circumstances in certain ways, and understanding that potential (and how to avoid it) is critical information that's needed for anyone building a namespace-aware application or using those sets of tools. Not all of those people are in the core XML community, and not all of them give a damn about XML, but they may need to know what it takes to use namespaces effectively and safely. </vent> Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 Feb 5 15:33:11 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:40 2004 Subject: Fw: Namespaces does *not* formally introduce "global attributes" References: <3.0.32.19990204162458.00b5d650@pop.intergate.bc.ca> Message-ID: <36BB105A.8416AD93@mecomnet.de> Tim Bray wrote: > > At 07:16 PM 2/4/99 -0500, David Megginson wrote: > >Actually, so far, pretty much everyone seems to have implemented > >namespaces this way, and it's working like a charm: it's standard in > >the very popular Perl XML:Parser module (which uses Expat) > > Seconded. Here's the example I use to teach namespaces to perl programmers; > they get it instantly > That they get it instantly is no surprise: the example does not handle the case which the rcommendation leave open to various interpretations. If the example is to be pertinent, please extend it to illustrate the "unqualified attribute name" case, ideally in the presence of both default and explicitly qualified namespaces for the respective element "type". Then please make the recommendation say the same thing (by assertion rather than negation). > use XML::Parser; > > $xml = "<z xmlns='http://one.org' > xmlns:two='http://two.org'><y1 /><two:y2 /></z>"; > $p = new XML::Parser(Namespaces => 1, > Handlers => { Start => \&STag }); > $p->parse($xml); > > sub STag { > my ($expat, $type) = @_; > my $ns = $expat->namespace($type); > print "Element type $type is from namespace $ns\n"; > } > =========output========================================== > Element type z is from namespace http://one.org > Element type y1 is from namespace http://one.org > Element type y2 is from namespace http://two.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Feb 5 15:39:07 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:40 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted NamespacesforXML) References: <8025670F.005165A0.00@mailhost.agora.co.uk> Message-ID: <36BB0934.E09CAEF2@prescod.net> hpyle@agora.co.uk wrote: > > Paul Prescod wrote, > > I don't think that "average developers" need to worry about namespaces. > ... > > If you are building a > > typical one-organization application then what are you doing with "other > > people's tags" in your documents? > > Maybe my perspective is a little warped. I'm working on healthcare > applications in the UK - interoperability will (sometime) become a big > deal. :-) Even so, people have been solving these sorts of problems without namespaces for years (i.e HL7 initiative). In order to exchange documents in healthcare it is probably NOT necessary to mix elements from different document types *blindly*. That's all namespaces help with. If you know in advance what element types must be mixed in a document of a particular type then you can just choose names that do not clash (or use a simple prefixing convention). -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Feb 5 15:43:33 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:40 2004 Subject: Colonialism, SAX, Java, and Namespaces References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> Message-ID: <36BB0D56.EDF427B0@prescod.net> "Simon St.Laurent" wrote: > > I would really appreciate if someday the people building W3C specs would > acknowledge that 'average developers' actually do have to worry about > namespaces, notations, parameter entities, include/ignore sections, and > trying to read the specs themselves. In my mind, this is just silly. I've never read the "SQL Specs" (have you?) and I certainly don't know everything there is to know about SQL or relational database technology. That doesn't make me a knuckle-dragging neanderthal. It makes me someone who recognizes that he doesn't need to know EVERYTHING about EVERY technology he uses. That's a losing proposition for a working programmer. I'm also someone who recognizes that it is not appropriate to dumb down everything so that I *CAN* understand it in its entirety. All I ask is that the actual interfaces that I am asked to work with be simplified so that I can follow them. The "interface" to namespaces for a developer is SAX or RDF engine and eventually DOM. *That's* what should be simple. Namespaces are an infrastructure technology. You use them THROUGH something, like RDF. Without something like RDF they are essentially useless. So unless you think that "RDF" is for the "average developer", namespaces are not for the average developer. When/if something like RDF takes off that situation may change. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 15:55:35 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:40 2004 Subject: Colonialism, SAX, Java, and Namespaces In-Reply-To: <36BB0D56.EDF427B0@prescod.net> References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> Message-ID: <199902051555.KAA02409@hesketh.net> At 09:25 AM 2/5/99 -0600, Paul Prescod wrote: >I'm also someone who recognizes that it is not appropriate to dumb down >everything so that I *CAN* understand it in its entirety. All I ask is >that the actual interfaces that I am asked to work with be simplified so >that I can follow them. The "interface" to namespaces for a developer is >SAX or RDF engine and eventually DOM. *That's* what should be simple. > >Namespaces are an infrastructure technology. You use them THROUGH >something, like RDF. Without something like RDF they are essentially >useless. So unless you think that "RDF" is for the "average developer", >namespaces are not for the average developer. When/if something like RDF >takes off that situation may change. Fine, Paul. Keep using the 'dumb down' vocabulary to show everyone what you really think of the 'average developer'. Ignore that fact that (unlike SQL) there are very few resources that do explain these structures in readable English (or other languages, to the best of my knowledge.) Assume that interfaces - themselves barely explained - can cover all this up neatly, though the discussion on this list has indicated repeatedly that those interfaces are not yet up to that task. Namespaces are all over Internet Explorer. Millions of people will be encountering them in some form, and for better or worse, that often leads to contagion. Like it or not, these things are going to take off, and we'd do a lot better to accomodate those millions than keep calling them 'dumb.' Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 jborden at mediaone.net Fri Feb 5 15:57:51 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:40 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces forXML) In-Reply-To: <8025670F.005165A0.00@mailhost.agora.co.uk> Message-ID: <000201be511f$7ab08f60$d3228018@jabr.ne.mediaone.net> Healthcare applications have the same issues as other applictions, with the added 'benefit' of multiple standards issuers and third party 'interested' organizations. For example elements from the hl7: namespace dicom: namespace hicfa: namespace might be combined in a single document. Namespaces aren't that difficult to deal with for the developer, but need to be dealt with by organizations with are developing DTD's,Schemas etc which span standards. Now, getting the U.S. and U.K. to agree on a set of standards (and namespaces) is its own issue :-) This is where XML and XTL has potential, e.g. U.S. HL7 2.3 <-> HL7/XML transport <- XTL -> U.K. EDIFACT XML transport <-> EDIFACT Transformations expressed in XSL/XTL can assist with interface of different messaging systems and integration of different 'flavors' of HL7. > > Paul Prescod wrote, > > I don't think that "average developers" need to worry about namespaces. > ... > > If you are building a > > typical one-organization application then what are you doing with "other > > people's tags" in your documents? > > Maybe my perspective is a little warped. I'm working on healthcare > applications in the UK - interoperability will (sometime) become a big > deal. :-) > 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 clark.evans at manhattanproject.com Fri Feb 5 16:01:50 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:40 2004 Subject: A weaker XSL? References: <5F052F2A01FBD11184F00008C7A4A80001136B01@eukbant101.ericsson.se> Message-ID: <36BB1440.661A32C1@manhattanproject.com> "Matthew Sergeant (EML)" wrote: > I guess what I should have said was "Why not use CSS then". If we're > talking about an XSL that doesn't do transformations then it's CSS you > should use. I'm not suggesting that the weakend XSL woudn't do any transformations, only that the transformations it does be based upon a stream rather than upon an object. If this dosn't make sence, then I'd like to hear more. What I'd rather not see is a "single" language which defines XML->HTML mappings where an intermediate form could increase reusability. Thus, | -> (XSL) -> HTML | / XML -> (XTL) -> XML -> (XSL) -> XML | \ | -> (XSL) -> PDF? | DOM, Server | SAX Client(s) Side Processing | Side Processing | * Ordering | * Filtering * Table of | * Formatting Contents | * Contextual Linking? * Other "shared | * Other "individual and information | preference-oriented generating | stylistic operations" operations" Mathematically speaking, I'd like to see SAX as a sufficient condition for XSL processing, where I'd like to see a full-blown DOM implementation used when it is a necessary condition for XTL. This way items like a table of contents, sorting, and other commonly used transformations can be seperated from the customized, style oriented transformations. :) Clark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 16:02:28 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:41 2004 Subject: A New Hope (was Re: Storing Lots of Fiddly Bits (was Re: What is XML for?)) Message-ID: <00c201be5120$a6d3e320$5ef96d8c@NT.JELLIFFE.COM.AU> From: spreitze@parc.xerox.com <spreitze@parc.xerox.com> >Right! I think a significant part of the problem here is that people are realizing that XML's data model is not as expressive as they'd like. For example, XML's entity structure looks like a semi-labelled graph (vertices are labelled (with entity tags) but edges are not labelled), whereas many other data models (e.g., RDF) let you label both the edges and the vertices. HyTime lets you label edges too: anyone can use that (to those people who whinge "but it is too hard" I say "CORBA CORBA CORBA": some things are big and difficult, it doesn't mean they are therefore bad). The question is, should such labelling be part of the language at the lexical level (which XML deals with) or a further layer. It is the old tradeoff that a general purpose system will (probably) be worse at any specific task than a specific system. > It seems to me that one plausible way out of this conundrum is for the XML Schema WG to recognize (1) the need for schemas to be written in terms of more expressive data modelling systems, (2) the need to support a variety of encodings of those data models into XML, and (3) the need for a schema to describe a particular encoding (the one desired for the schema at hand) of the schema's data model into XML. Sounds good. But Mike's comments do betray a wish that XML operated on some other level than the strictly lexical: but it doesn't, except by chance. Rick xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Fri Feb 5 16:07:06 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:41 2004 Subject: A weaker XSL? References: <93CB64052F94D211BC5D0010A80013310EB2DA@WWMESS3> Message-ID: <36BB1520.6271C6A@manhattanproject.com> Michael.Kay@icl.com wrote: > > How do I build a table of contents that is output BEFORE the document > > without reading the whole input before I start to output? > You can't, and that isn't my objective. What you can do, and what I > currently do with SAXON, is to perform a single serial pass of the input > document that simultaneously generates a TOC and the main rendered document > on two separate output streams, then merge these together for presentation. > This is far more efficient with a large document than building the entire > document tree in memory or scanning it twice. I agree. Nice. Very nice. :) Clark -- software n : 1. written programs or procedures or rules and associated documentation pertaining to the operation of a computer system. 2. applied philosophy xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at weblogic.com Fri Feb 5 16:12:09 1999 From: peter at weblogic.com (Peter Seibel) Date: Mon Jun 7 17:08:41 2004 Subject: When to use attributes vs. elements Message-ID: <19990205161816668.AAA169@ashbury.weblogic.com@lawton> Is there an XML philosophy (or an SGML philosophy for that matter) about when to use attributes vs when to use elements when desigining a document type. For example if I was writing a document type for representing (part) java classes I could have something like: <class> <package>x.y.z</package> <name>Foo</name> <!-- other more complicated stuff: definitely elements --> </class> or I could have: <class package="x.y.z" name="Foo"> <!-- other more complicated stuff: definitely elements --> </class> Obviously I wouldn't use attributes, if the value had any structure to it. But in a case like this is there some principle that would give some guidence? -Peter P.S. Actually in the attribute case I think I'd do something more like: <class name="x.y.z.Foo"> and let the application split apart the package part from the base name; that way I could declare name to be ID since it should be unique. -- Peter Seibel Perl/Java/English Hacker peter@weblogic.com Is Windows98 Y2K compliant? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Feb 5 16:16:32 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:41 2004 Subject: Colonialism, SAX, Java, and Namespaces In-Reply-To: <199902051555.KAA02409@hesketh.net> References: <36BB0D56.EDF427B0@prescod.net> <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> Message-ID: <3.0.6.32.19990205081814.00d50ec0@scripting.com> >>Namespaces are all over Internet Explorer. Millions of people will be encountering them in some form, and for better or worse, that often leads to contagion. Like it or not, these things are going to take off, and we'd do a lot better to accomodate those millions than keep calling them 'dumb.' Then Web Review and O'Reilly and PC Mag will run tutorials. And there will be a Visual Quickstart for Namespaces, and of course Namespaces for Dummies. There's a system in place for handling this stuff. Namespaces in a Nutshell? I think that what you're saying is that XML is quickly becoming a lot bigger than the XML-DEV list. But there's no need to panic.. 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 Charles.Gamble at singularity.co.uk Fri Feb 5 16:21:44 1999 From: Charles.Gamble at singularity.co.uk (Charles Gamble) Date: Mon Jun 7 17:08:41 2004 Subject: MSXML 1.0 Message-ID: <1731A8D895B4D2119F94006097E59FEDD27C@singular_s1_nt4.singularity.co.uk> Can MSXML 1.0 be used to read in strings containing XML content? If so, how is this done? An example in script would be useful, showing the XML object being created , the string being declared with XML content and the string then being loaded into the XML object. All the examples I have seen use an XML file to load into the XML object. An example in C++ would also come in handy. Please tell me this is possible. Thanks in advance, Charles Gamble. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Feb 5 16:44:39 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:41 2004 Subject: Colonialism, SAX, Java, and Namespaces References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> <199902051555.KAA02409@hesketh.net> Message-ID: <36BB1B53.3B90A754@prescod.net> "Simon St.Laurent" wrote: > > At 09:25 AM 2/5/99 -0600, Paul Prescod wrote: > >I'm also someone who recognizes that it is not appropriate to dumb down > >everything so that I *CAN* understand it in its entirety. > > Fine, Paul. Keep using the 'dumb down' vocabulary to show everyone what > you really think of the 'average developer'. I used the term *dumb down* in reference to *myself*. The average developer is a dummy in all but a few fields, just like me. We cannot restrict all fields until they are simple enough for everyone to understand. As someone pointed out recently, we wouldn't have a technologically advancing civilization if we did that. If we cannot agree on that much then further discussion is not going to be productive. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Fri Feb 5 16:46:09 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:41 2004 Subject: SAXON (Was: Re: A weaker XSL?) References: <93CB64052F94D211BC5D0010A80013310EB2DA@WWMESS3> Message-ID: <36BB1F4C.396D2974@manhattanproject.com> <cut> Discussion about a weaker version of XSL where sequential access is a sufficient condition for processing and random access is not the necessary condition. </cut> Michael.Kay@icl.com wrote: > > How do I build a table of contents that is output BEFORE the document > > without reading the whole input before I start to output? > > You can't, and that isn't my objective. What you can do, and what I > currently do with SAXON, is to perform a single serial pass of the input > document that simultaneously generates a TOC and the main rendered document > on two separate output streams, then merge these together for presentation. > This is far more efficient with a large document than building the entire > document tree in memory or scanning it twice. Stream processing! This is what I initially assumed XSL did. It's so nice to hear that I'm not on another planet. It's about time we considered the case when an XML document is a sequentially accessed stream. Wonderful! Michael, how do I get SAXON? I'm excited. :) Clark -- flyweight n : 1. the most confusing part of the otherwise wonderful Design Patterns book 2. when everything looks like a nail xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Charles.Gamble at singularity.co.uk Fri Feb 5 16:49:36 1999 From: Charles.Gamble at singularity.co.uk (Charles Gamble) Date: Mon Jun 7 17:08:41 2004 Subject: FW: MSXML 1.0 Message-ID: <1731A8D895B4D2119F94006097E59FEDD27F@singular_s1_nt4.singularity.co.uk> By the way, I only have IE 4.0 installed. > -----Original Message----- > From: Charles Gamble > Sent: 05 February 1999 16:16 > To: 'xml-dev@ic.ac.uk' > Subject: MSXML 1.0 > > Can MSXML 1.0 be used to read in strings containing XML content? > If so, how is this done? An example in script would be useful, showing > the XML object being created , the string being declared with XML content > and the string then being loaded into the XML object. > All the examples I have seen use an XML file to load into the XML object. > An example in C++ would also come in handy. > Please tell me this is possible. > Thanks in advance, > Charles Gamble. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 16:50:25 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:41 2004 Subject: Namespaces does *not* formally introduce "global attributes" Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054969@SOHOS002> David Megginson wrote: > Mark Birbeck writes: > > Reminds me of a question I had a while back: ... > > Further to this topic, the following note does appear in the XML 1.0 > spec: > > Note: The colon character within XML names is reserved for > experimentation with name spaces. ... > > In other words, you're allowed to use ':' for non-namespace purposes > but you're playing with fire if you do. > Thanks David. I was trying to find it in all of the namespace documentation/comment, but didn't realise that the topic was anticipated in XML 1.0. (With all that that implies! Won't open hornets nest now thought.) Thanks again. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 david at megginson.com Fri Feb 5 17:06:06 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:41 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces forXML) In-Reply-To: <36BAF974.6F87E679@prescod.net> References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <36BAF974.6F87E679@prescod.net> Message-ID: <14010.65394.42870.480866@localhost.localdomain> Paul Prescod writes: > > Namespaces seem to be an essential solution to two problems > > encountered when designing XML stuctures: - how can I distinguish > > my tags from everyone else's, to avoid confusion (eg: > > "<my:pastry/>"); > > Actually, this problem is very RARELY encountered. If you are > building a typical one-organization application then what are you > doing with "other people's tags" in your documents? I mean, if you > are writing typical software, it will choke and die when it comes > upon tags it does not know about. This depends on whether the information is documentation or fielded/tabular content. So far, far over half the work that Megginson Technologies is doing with XML (rather than SGML) is for data exchange rather than document production. For example, let's say that I design a record structure for information about a member of a mailing list: <member> <name>Paul Prescod</name> <email>paul@prescod.net</email> <company>ISOGEN</company> </member> Now, let's say that I get records in from other mailing lists whose maintainers include extra information that is not part of my original spec: <member> <name>Paul Prescod</name> <email>paul@prescod.net</email> <company>ISOGEN</company> <origin>Canada</origin> </member> These records are still using <member>, <email>, and <company> in the same way, but they've added something else. Now someone else might take a different approach to <origin>, since it wasn't part of my original spec: <member> <name>Paul Prescod</name> <email>paul@prescod.net</email> <company>ISOGEN</company> <origin>University of Waterloo</origin> </member> The advantages of being able to come up with globally-unique names should be obvious: <member xmlns="http://foo.com/ns/" xmlns:a="http://hack.com/ns/"> <name>Paul Prescod</name> <email>paul@prescod.net</email> <company>ISOGEN</company> <a:origin>Canada</a:origin> </member> or <member xmlns="http://foo.com/ns/" xmlns:b="http://bar.com/ns/"> <name>Paul Prescod</name> <email>paul@prescod.net</email> <company>ISOGEN</company> <b:origin>University of Waterloo</b:origin> </member> or even <member xmlns="http://foo.com/ns/" xmlns:a="http://hack.com/ns/" xmlns:b="http://bar.com/ns/"> <name>Paul Prescod</name> <email>paul@prescod.net</email> <company>ISOGEN</company> <a:origin>Canada</a:origin> <b:origin>University of Waterloo</b:origin> </member> A second major advantage of namespaces is the ability to reuse processing code. If I have written an event-handler/subroutine/method to do something useful with an HTML <table> element, then I'd like to reuse that for *every* document type that happens to use the HTML table model, even if I don't know about the document type in advance. Of course, I know that I could do all of this with architectural forms as well. 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 falk at icon.at Fri Feb 5 17:06:06 1999 From: falk at icon.at (Falk, Alexander) Date: Mon Jun 7 17:08:41 2004 Subject: XML Spy v1.4 released Message-ID: <A01C76E644CAD111B83A0000E8D8890E057AB6@melange.icon.co.at> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Falk, Alexander.vcf Type: application/octet-stream Size: 1062 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990205/90325ba8/FalkAlexander.obj From paul at prescod.net Fri Feb 5 17:15:22 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:41 2004 Subject: A weaker XSL? References: <5F052F2A01FBD11184F00008C7A4A80001136B01@eukbant101.ericsson.se> <36BB1440.661A32C1@manhattanproject.com> Message-ID: <36BB2173.9CC476D7@prescod.net> Clark Evans wrote: > > I'm not suggesting that the weakend XSL woudn't do any > transformations, only that the transformations it does > be based upon a stream rather than upon an object. I have no problem with a weakened, transformational XSL for certain stream-based applications. But you seem to think that such a thing could be a replacement for XSL "as we know it." I don't believe that. I have the following problems with your two-tier model: * in general the HTML and PDF versions of a document will order and organize things differently. Online navigation is quite different from print navigation. So the part of the language that is "media specific" must be essentially as powerful as the part that is not. * if the data has ALREADY been transformed then why isn't CSS "good enough" for the second step? * people want the transformation part to take place on the client side in order to distribute the processing load. In applications where your model is sufficient, I think we already have the languages in place to MAKE it work: XSL does the transformation and CSS does simple style annotation. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Feb 5 17:21:02 1999 From: jmcdonou at library.berkeley.edu (Jerome McDonough) Date: Mon Jun 7 17:08:41 2004 Subject: Colonialism, SAX, Java, and Namespaces In-Reply-To: <36BB0D56.EDF427B0@prescod.net> References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> Message-ID: <3.0.5.32.19990205085933.009b1a30@library.berkeley.edu> At 09:25 AM 2/5/1999 -0600, Paul Prescod wrote: >Namespaces are an infrastructure technology. You use them THROUGH >something, like RDF. Without something like RDF they are essentially >useless. So unless you think that "RDF" is for the "average developer", >namespaces are not for the average developer. When/if something like RDF >takes off that situation may change. > I would argue, actually, that most average developers are going to have to deal with RDF. With the proliferation of information that all organizations are having to cope with, metadata to keep track of the information will be more and more essential. And RDF seems to be gaining significant mindshare as the way to store metadata among the SGML/XML crowd. If that trend continues, any developer working in medium-to-large organizations is going to be dealing with RDF, and hence, namespaces. This doesn't necessarily argue for any changes in the namespace spec, but assumptions that the average developer isn't going to have to deal with RDF (or any other metadata encoding standard) may be a bit rash. 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 rbourret at ito.tu-darmstadt.de Fri Feb 5 17:22:34 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:41 2004 Subject: Colonialism, SAX, Java, and Namespaces Message-ID: <01BE5133.156BC980@grappa.ito.tu-darmstadt.de> Paul Prescod wrote: > I used the term *dumb down* in reference to *myself*. The average > developer is a dummy in all but a few fields, just like me. We cannot > restrict all fields until they are simple enough for everyone to > understand. As someone pointed out recently, we wouldn't have a > technologically advancing civilization if we did that. If we cannot agree > on that much then further discussion is not going to be productive. I don't think Simon is asking for simpler technology. I think he's asking for more explanatory writing in the specs. Precision is almost impossible to achieve in spoken languages -- there is always somebody clever or foolish enough to "misinterpret" the most basic words -- and so the question is whether you write a short, highly formal spec, interpret it afterward, and hope that everybody hears/understands you, or write a longer, perhaps less formal spec, interpret it place, and hope you don't introduce inconsistencies and ambiguities, or go somewhere in between. Personally, I vote for the longer, slightly less formal route, as I believe it leads to wider acceptance and, in the long run, less misinterpretation. That said, I've written enough specs in my lifetime that I sympathize with anyone who writes one at all, no matter what style they choose. -- 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 simpson at polaris.net Fri Feb 5 17:22:47 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:08:41 2004 Subject: When to use attributes vs. elements Message-ID: <3.0.32.19990205121500.007d2ec0@polaris.net> At 08:17 AM 2/5/99 -0800, Peter Seibel wrote: >Is there an XML philosophy (or an SGML philosophy for that matter) about >when to use attributes vs when to use elements when desigining a document >type.... For an SGML view, here's a comment (dated 28 Apr 1992) from C.M. Spielberg-McQueen: http://www.oasis-open.org/cover/attrSperberg92.html Last April this was the topic of a thread here on XML-DEV. You can check the archives, or see it all in one package here: http://www.oasis-open.org/cover/elementAttr9804.html Both references are from Robin Cover's excellent (and frequently updated) SGML/XML site, obviously located at http://www.oasis-open.org/cover/. In general, one thing to remember is that (at least for simple XML applications) attribute values are "invisible" when the document is viewed. Best, JES ==================== John E. Simpson Just XML (ISBN 0-13-943417-8) Available now from Prentice Hall PTR xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Feb 5 17:23:12 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:08:41 2004 Subject: When to use attributes vs. elements Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEF37@RED-MSG-08> Peter asked whether there are rules or guidelines in XML for when to use attributes versus elements. You will find a wealth of opinions on this topic. Partly this reflects the wealth of options that XML gives you and the fact that XML can be employed for many purposes. You may want to take a look at "XML Syntax Recommendation for Serializing Graphs of Data" (http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.html) for a suggestion on how to use XML for serializing programming objects and data from databases. -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 david at megginson.com Fri Feb 5 17:27:23 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:41 2004 Subject: Colonialism, SAX, Java, and Namespaces In-Reply-To: <36BB0D56.EDF427B0@prescod.net> References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> <36BB0D56.EDF427B0@prescod.net> Message-ID: <14011.9910.776880.149972@localhost.localdomain> Paul Prescod writes: > Namespaces are an infrastructure technology. You use them THROUGH > something, like RDF. Without something like RDF they are > essentially useless. So unless you think that "RDF" is for the > "average developer", namespaces are not for the average > developer. When/if something like RDF takes off that situation may > change. I (politely) disagree again -- there are many applications that can take advantages of namespaces without an RDF-like infrastructure. Here are some examples: 1. Search engines (i.e. find every mention of "Megginson" in an element named {http://www.software.com/ns/}developer). 2. Browsers (i.e. set any occurrence of {http://www.software.com/ns/}keyword in monospaced type for all document types, unless overridden by a more specific rule). 3. Localization transformations (i.e. attempt to read the contents of every element with an attribute named {http://finance.com/ns/}currency as a number and convert it to the local currency if possible). All of these (and many more) can be applied to typical human-readable documents with mixed content; they're not limited to RDF-like documents. 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 larsga at ifi.uio.no Fri Feb 5 17:34:28 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:08:41 2004 Subject: COBOL XML parser? In-Reply-To: <199902041412.JAA10888@hesketh.net> References: <199902041412.JAA10888@hesketh.net> Message-ID: <wkpv7ou55z.fsf@ifi.uio.no> * Simon St.Laurent | | * Lisp james anderson has written one that is distributed with the CL-HTTP web server. See <URL:http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html> in the contrib-directory of the distribution. I've tinkered a bit with a DTD parser in Common Lisp my spare time, but since that is close to non-existent, so are the results. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Feb 5 17:38:26 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:42 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted Namespaces forXML) Message-ID: <3.0.32.19990205093621.00bd7d60@pop.intergate.bc.ca> At 08:00 AM 2/5/99 -0600, Paul Prescod wrote: >I don't think that "average developers" need to worry about namespaces. It >is quite simple to build powerful, useful applications without them. Yes, it's possible, but it seems crystal clear to me that a year or so from now, the "average XML document", were such a thing to exist, would have namespaces. Office 2000 is full of 'em. RDF is full of 'em. And if nothing else, old-fashioned document wrangling is, I predict, going to be dipping regularly into namespaces like, for example, HTML. Which is why it really is a problem that something that we tried so hard to make simple is being perceived (rightly or wrongly) as complex and intimidating. -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 clark.evans at manhattanproject.com Fri Feb 5 17:50:05 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:42 2004 Subject: Architectural Forms and Namespaces (Was: Re: SAX, Java, and Namespaces ) References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <36BAF974.6F87E679@prescod.net> <14010.65394.42870.480866@localhost.localdomain> Message-ID: <36BB2E4F.6524A575@manhattanproject.com> David Megginson wrote: > <cut> a very nice discussion of namespaces </cut> > Of course, I know that I could do all of this with > architectural forms as well. You can do _all_ of it with both? I had pictured a combination punch to solve the problem. I see namespaces and architectural forms as yet another complementary system within XML. Namespaces uniquely identify an element's structure, and archectural forms describe the mappings between these various structures. I don't see one or the other used. I see them being used in combination. What am I missing? Clark Evans -- software n : 1. written programs or procedures or rules and associated documentation pertaining to the operation of a computer system. 2. applied philosophy xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Feb 5 17:52:45 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:08:42 2004 Subject: When to use attributes vs. elements In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAEF37@RED-MSG-08> Message-ID: <Pine.GHP.4.02A.9902051740360.27539-100000@mail.ilrt.bris.ac.uk> On Fri, 5 Feb 1999, Andrew Layman wrote: > Peter asked whether there are rules or guidelines in XML for when to use > attributes versus elements. > > You will find a wealth of opinions on this topic. Partly this reflects the > wealth of options that XML gives you and the fact that XML can be employed > for many purposes. > > You may want to take a look at "XML Syntax Recommendation for Serializing > Graphs of Data" > (http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.html) for a > suggestion on how to use XML for serializing programming objects and data > from databases. > > -Andrew Layman Is this paper suggesting that the entire XML (and SGML?) community might be persuaded to serialise directed labelled graphs into XML always using this proposed canonicalised serialisation algorithm? If not, how can we tell from looking at a chunk of XML data whether they've followed this approach or followed one of the other various (explicit or implicit) graph serialisation patterns? Should we be able to tell whether this algorithm has been used without consulting/dereferencing schema declarations, ie. is there a need to propose an enclosing 'GraphSerialisation' tag of some sort so we can tell whether these rules have been used? Or some other sort of aid to interpretation...? If not, doesn't this amount to assuming (a) the we _know_ what others were thinking when they designed their serialisation algorithms, or (b) that the world can be persuaded to adopt this approach for 100% of data and document interchange. Neither fits well with the "wealth of opinions on this topic"... 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 simonstl at simonstl.com Fri Feb 5 17:57:02 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:42 2004 Subject: Colonialism, SAX, Java, and Namespaces In-Reply-To: <01BE5133.156BC980@grappa.ito.tu-darmstadt.de> Message-ID: <199902051753.MAA05051@hesketh.net> At 06:12 PM 2/5/99 +0100, Ronald Bourret wrote: >I don't think Simon is asking for simpler technology. I think he's asking >for more explanatory writing in the specs. Precision is almost impossible >to achieve in spoken languages -- there is always somebody clever or >foolish enough to "misinterpret" the most basic words -- and so the >question is whether you write a short, highly formal spec, interpret it >afterward, and hope that everybody hears/understands you, or write a >longer, perhaps less formal spec, interpret it place, and hope you don't >introduce inconsistencies and ambiguities, or go somewhere in between. Precisely. Taking the time and making the effort to ensure that specifications are clear - and not just to a small community of experts - means a lot less need for repeated explanation afterward. It makes a specification more inclusive, avoiding the need for debates over who is worthy of reading the spec. That inclusiveness can encourage more people to join the implementation process, and produce richer yields of new ideas and real source code - and less debate about non-normative sections and the impossibility of figuring out formal specifications. Extending that inclusive approach to the larger discussions also promises to have significantly more benefits than raining down comments telling developers that the specifications (and by implication, XML) really aren't meant for them, that they shouldn't be reading those things, and they certainly shouldn't be complaining about them. Being inclusive takes extra effort, but it hardly stands in the way of clear or useful standards. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 gkholman at CraneSoftwrights.com Fri Feb 5 17:57:01 1999 From: gkholman at CraneSoftwrights.com (G. Ken Holman) Date: Mon Jun 7 17:08:42 2004 Subject: When to use attributes vs. elements In-Reply-To: <19990205161816668.AAA169@ashbury.weblogic.com@lawton> Message-ID: <Version.32.19990205124315.00ea8690@CraneSoftwrights.com> At 99/02/05 08:17 -0800, Peter Seibel wrote: >Is there an XML philosophy (or an SGML philosophy for that matter) about >when to use attributes vs when to use elements when desigining a document >type. >... >But in a case like this is there some principle that would give some guidence? Philosphical? No. Religious? Yes. :{)} Some people fervently *believe* in one way while other *believe* in the other way. Here is a public repository of opinion: http://www.oasis-open.org/cover/elementsAndAttrs.html .......... Ken -- G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Box 266, V: +1(613)489-0999 Kars, Ontario CANADA K0A-2E0 F: +1(613)489-0995 Training: http://www.CraneSoftwrights.com/x/schedule.htm Resources: http://www.CraneSoftwrights.com/x/resources.htm Shareware: http://www.CraneSoftwrights.com/x/shareware.htm Next XSL Training: X-Tech:1999-03-07 WWW8:1999-05-11 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 18:02:16 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:42 2004 Subject: Colonialism, SAX, Java, and Namespaces Message-ID: <A26F84C9D8EDD111A102006097C4CD0D05496B@SOHOS002> Simon St.Laurent wrote: > I get the feeling that some of the writers on this list - though > _certainly_ not all - view the 'average developer' as some kind of > primitive creature that should be shunted aside in the name > of progress. Why would anyone shunt aside 'average developers'? Where else do the truly great developers come from, but the large pool of average developers? However, if all we ever talk about is what can be understood by the most number of people, then we do *not* progress. Do you really want to keep the useful discussion about how and whether to store XML files in a database or not to be constantly concerned with how many people can understand and contribute? Sure, you want to be as helpful as you can to others who are learning, but also you sometimes want to have high-level discussions with your peers (not to say we're all 'truly great' either - just 'above average'). > This colonialist view (I don't know what else to compare it > to - simple > elitism seems inadequate) has contributed to the development > of a lot of > tools that people talk about but very few people understand. I'm not sure which colonialism you're thinking of, but the one I read about involved dominating foreign lands, taking their cash and selling the occupants as slaves. Next you'll be talking about holocausts - rounding up 'average developers' and the like. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 paul at prescod.net Fri Feb 5 18:04:47 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:42 2004 Subject: Namespaces for "average programmers" Message-ID: <36BB2E8E.61D4902F@prescod.net> LeT me try again with this namespaces characterization. You can't do anything useful with markup unless you have two things: a schema language to enforce constraints and a processing model to *do something*. If you are truly an average developer, then you don't want to invent a schema language or processing model. So you must use one that exists. There are only two standards-track schema languages: DTDs and RDF schemas. DTDs do not know anything about namespaces. Therefore you do not need to know anything about namespaces to use DTDs. RDF supports namespaces. But RDF's use of namespaces is mostly documented in RDF itself. "Best practices" for namespace usage in RDF schemas are specific to RDF. Anyhow I think that it is debatable whether average programmers use RDF. On the procesing side, XSL uses namespaces but anybody can figure out how to use namespaces in RDF just by reading the XSL specification (or a book/article on XSL). Once again, you don't have to become an expert on the namespaces specification to use XSL. Plus XSL has essentially no support for namespaces in the documents it proceses. One day it might, but again the best practices for namespace usage relative to XSL will arise at that point. In other words, it will be at least a year before the infrastructure for using arbitary namespaces will be available. And using the fixed namespaces we have today (xml:, xsl:, fo:) is pretty much a no-brainer. People on the xsl-list seem to have no problem with it. In other words, don't worry be happy. The sky is not falling. (it is interesting to note that XSL gets away with using namespaces because there is no schema language that defines it. RDF gets away with using namespaces because there is no RDF processing model. Presumably every RDF application defines a processing model from scratch.) Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmg at trivida.com Fri Feb 5 18:15:20 1999 From: jmg at trivida.com (Jeff Greif) Date: Mon Jun 7 17:08:42 2004 Subject: Slowness of JDK 1.1.x String.intern() [was Re: SAX, Java, and Namespaces ] Message-ID: <030601be5133$166851f0$a24630d1@greif.trivida.com> JDK 1.1.7 intern is native, but is slow because it first converts the characters in the string from unicode to UTF-8 in a freshly malloc'ed buffer. The buffer is later freed if the string is already interned. It is stored in the string table along with the String if not already present. It would be much better if a fixed-sized buffer for small strings and an alloca()'ed or malloc'ed buffer for larger ones were used, since the lookup operation has the option of copying the string if it needs to be inserted. I've sent Sun a revised version, but don't know whether or when it will be used. Jeff -----Original Message----- From: Tyler Baker <tyler@infinet.com> To: Tim Bray <tbray@textuality.com> Cc: David Megginson <david@megginson.com>; xml-dev@ic.ac.uk <xml-dev@ic.ac.uk> Date: Thursday, February 04, 1999 5:48 PM Subject: Re: SAX, Java, and Namespaces (was Re: Restricted Namespacesfor XML) ... earlier stuff snipped ... > >As I said before things have improved. intern() is now native so there is really no excuse >that I can think of why it should still be slow (it is not as slow as it used to be but >calling it has roughly half the cost of calling new() now). Nevertheless, the String class >should of had a static intern() method a long time ago that accepts a character array. Boy >would it have been convenient... > >Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 18:21:13 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:42 2004 Subject: Slowness of JDK 1.1.x String.intern() [was Re: SAX, Java, and Namespaces ] Message-ID: <3.0.32.19990205101910.00bdf210@pop.intergate.bc.ca> At 10:12 AM 2/5/99 -0800, Jeff Greif wrote: >JDK 1.1.7 intern is native, but is slow because it first converts the >characters in the string Actually, the real reason that most XML parsers will *never* use built-in intern is because they probably have the name available in a character array, and can go look things up in the handcrafted table without String-i-fying it - thus skipping several steps of work that a built-in intern is going to have to do. E.g. Lark's symbol table is a double array, storing both the character-array and String version of each name - you lookup based on the character array and return the string if it's already there. The point is that you call new String() only once per unique name. -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 jes at kuantech.com Fri Feb 5 18:32:24 1999 From: jes at kuantech.com (Jeffrey E. Sussna) Date: Mon Jun 7 17:08:42 2004 Subject: CORBA's not boring yet. / XML in an OS? In-Reply-To: <3.0.6.32.19990205050217.00f49460@scripting.com> Message-ID: <000301be5135$7c9af840$5118a8c0@kuantech1.quokka.com> If you have Netscape Navigator 4 on your machine, then IIOP runs on your machine. -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Dave Winer Sent: Friday, February 05, 1999 5:02 AM To: xml-dev@ic.ac.uk Subject: RE: CORBA's not boring yet. / XML in an OS? >>Isn't RPC using IIOP and DCOM already slow enough without using XML? Why don't MS just support IIOP? I don't know why MS does anything, I don't work there. I know why I like XML-RPC. It's simple. You can write a client in a few hours, and a server in a couple of days. A JavaScript programmer can learn how to do it, today, in less than 24 hours, and in a few weeks, they'll be able to do it in minutes. I have some theories about why this is true: 1. HTTP is everywhere. Does IIOP run on my machine? I'm pretty sure it doesn't. And it's not just about Microsoft, I have Macs too. 2. XML looks like HTML. To someone who has mastered HTML the transition is easy. Performance matters, for sure. But sometimes people overlook that people performance is probably the single most important limiting factor. I can tell you this, CORBA wasn't designed for my mind. It's so complicated, so many new concepts to understand. I even had trouble understanding HTML way back when. Wire protocols can be optimized, but people's brains move at their own rate, rejecting things that appear too complicated, waiting for something that makes sense to them. We're all busy! The problem with COM, CORBA and Apple Events is that each of them were invented before the web exploded and are quite platform specific, and are not understandable to people who do web development. 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 avirr at LanMinds.Com Fri Feb 5 18:36:14 1999 From: avirr at LanMinds.Com (Avi Rappoport) Date: Mon Jun 7 17:08:42 2004 Subject: Colonialism, SAX, Java, and Namespaces In-Reply-To: <199902051753.MAA05051@hesketh.net> References: <01BE5133.156BC980@grappa.ito.tu-darmstadt.de> Message-ID: <v04104404b2e0e79f3670@[207.33.50.55]> At 12:56 PM -0500 2/5/99, Simon St.Laurent wrote: > Precisely. Taking the time and making the effort to ensure that > specifications are clear - and not just to a small community of experts - > means a lot less need for repeated explanation afterward. It makes a > specification more inclusive, avoiding the need for debates over who is > worthy of reading the spec. I agree, and have found that the best way to be truly clear is to provide as many examples as possible. The one caveat is that almost every beginner will follow those examples slavishly, so they'd better be well-designed and applicable to a wide variety of situations. There's a nice opportunity for an "XML Namespaces By Example" book and/or site, which could provide an excellent supplement to the spec. If, in fact, the examples really do follow the spec... Perhaps the best way to get started is to encourage people to post their early designs and drafts to the list for constructive comments. That way, those of us who are having a hard time grokking the process can learn from the public analysis. Avi ________________________________________________________________ Avi Rappoport, Web Site Search Tools Maven: <mailto:avirr@lanminds.com> Guide to Site Indexing and Local Search Engines: <http://www.searchtools.com> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Fri Feb 5 18:51:12 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:42 2004 Subject: Architectural Forms and Namespaces (Was: Re: SAX, Java, and Namespaces ) In-Reply-To: <36BB2E4F.6524A575@manhattanproject.com> References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <36BAF974.6F87E679@prescod.net> <14010.65394.42870.480866@localhost.localdomain> Message-ID: <3.0.5.32.19990205125207.00ab6940@amati.techno.com> At 05:45 PM 2/5/99 +0000, Clark Evans wrote: >I don't see one or the other used. I see them >being used in combination. What am I missing? It was true of the original namespace approach (but may not be with the latest), that anything you could say with namespaces you could also say with architectural mappings (that is, binding an element or attribute instance to a globally-unique name). The reverse was not (and is not) true: there are many things you can say with architectures that you cannot say with name spaces. Name spaces and architectures were (and hopefully still are) complementary at least to the degree that the use of one did not interefere with use of the other and the two could be used in combination in various clever ways. Note that one of the key things that architectures provide that name spaces do not is an explicit definition of how to validate a document against the syntactic requirements of the architecture--this is because the architecture mechanism uses DTD as its formal definition, thus any document can be validated against its architectural DTD. In addition, the architecture is, by definition of the Architecture standard, a definition of the *semantics* of the architecture (whatever that might mean and however they might be defined), not just the definition of a vocabulary of element types and attributes. This is a subtle but important distinction. Note that any vocabulary of names used as a name space can also be used as an architecture. Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Feb 5 18:56:56 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:42 2004 Subject: Colonialism, SAX, Java, and Namespaces References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> <36BB0D56.EDF427B0@prescod.net> <14011.9910.776880.149972@localhost.localdomain> Message-ID: <36BB3BC8.F1476D09@prescod.net> David Megginson wrote: > > > When/if something like RDF takes off that situation may > > change. > > I (politely) disagree again -- there are many applications that can > take advantages of namespaces without an RDF-like infrastructure. I didn't mean a metadata infrastructure like RDF. I meant that we namespaces need to be put in a lot more *context* before average programmers should worry about them. In the abstract they will be complicated because questions like "what does an unqualified attribute mean" and "what are best practices" are best answered *in the context of concrete applications*. XSL uses namespaces and nobody finds them confusing. Because XSL provides an intuitive context and interface to the namespace concept. But take that concept out of context and people will get confused. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Feb 5 18:58:37 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:42 2004 Subject: SAX, Java, and Namespaces (was Re: Restricted NamespacesforXML) References: <3.0.32.19990205093621.00bd7d60@pop.intergate.bc.ca> Message-ID: <36BB3AED.8836CF36@prescod.net> Tim Bray wrote: > > Yes, it's possible, but it seems crystal clear to me that a year or > so from now, the "average XML document", were such a thing to exist, > would have namespaces. Office 2000 is full of 'em. I understand that but I do not think that the consumers of those documents (whether end-users or "average programmers") will need to go back to the XML Names specification to understand them. > RDF is full of > 'em. And if nothing else, old-fashioned document wrangling is, I > predict, going to be dipping regularly into namespaces like, for > example, HTML. The average HTML user is not going to go to the namespaces specification any more than they went to the SGML specification. Nor should they. > Which is why it really is a problem that something that we tried so > hard to make simple is being perceived (rightly or wrongly) as > complex and intimidating. -Tim Namespaces are intimidating for exactly the same reason that things like XLink and architectural forms are intimidating. Namespaces are abstract. But when you apply them to a spec, like Office 2000, or HTML, they become simple to understand. In a particular context, they are simple. That's why "average developers" should sit back and wait for the context to develop. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Feb 5 19:51:55 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:42 2004 Subject: Namespaces does *not* formally introduce "global attributes" References: <A26F84C9D8EDD111A102006097C4CD0D054968@SOHOS002> Message-ID: <36BB4B8B.2C33BC9F@infinet.com> Mark Birbeck wrote: > > Additionally, implementers would have been able to easily add > > a namespace > > processing module on top of their current XML parsers (a SAX namespace > > expansion filter, for example, is trivial when implemented this way), > > _without changing the interfaces_. Future implementations > > might use better > > interfaces - such as APIs for accessing just the "namespace > > part" or the > > "local part" of an expanded name - but the point is every XML > > application > > would go on working as it is, without any changes. > > Reminds me of a question I had a while back: what happens to a perfectly > acceptable XML 1.0 document run through an XML parser which has a > namespace processing module? This is, after all, valid XML 1.0: > > <this:is:my:good this:is:an:attribute:called:a1="1" /> > > (As is: > > <:::: :::="1" /> > > ) Good point. > In terms of the old document run through the new parser, as far as > namespaces go this should be no different to: > > <good a1="1" /> > > But in the new parsers it will be an error, because, as the spec says, > "The namespace prefix, unless it is xml or xmlns, must have been > declared ..." > > It seems that XML namespaces are not backwards compatible with 'old' > documents. If this is true, is it explicitly justified anywhere? I > haven't come across it. Perhaps it is the intention of the spec that a > 'non-conformant' document (i.e., more than one colon in names, etc.) > simply 'drops back' to XML 1.0, rather than being 'failed' by the > namespace processor. But this then means you couldn't merge two DTDs in > a document - one built with namespaces in mind, and one not. One idea would be to have a processing instruction in the prolog of the document which tells the XML Parser whether namespaces processing should be turned on or not before parsing of the body begins. <?xml:namespaces status="on"?> XML Parser which cannot process XML namespaces would then either throw an error or at least give a warning. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 5 20:13:22 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:43 2004 Subject: Namespaces does *not* formally introduce "global attributes" Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054972@SOHOS002> Tyler Baker wrote: > One idea would be to have a processing instruction in the > prolog of the document which tells > the XML Parser whether namespaces processing should be turned > on or not before parsing of the > body begins. > > <?xml:namespaces status="on"?> > > XML Parser which cannot process XML namespaces would then > either throw an error or at least > give a warning. Except that the problem may be that a document uses two DTDs, one ns compliant and one not. That's why I came to the conclusion that nodes should conform, rather than entire documents. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 tyler at infinet.com Fri Feb 5 20:55:09 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:43 2004 Subject: Slowness of JDK 1.1.x String.intern() [was Re: SAX, Java,and Namespaces ] References: <3.0.32.19990205101910.00bdf210@pop.intergate.bc.ca> Message-ID: <36BB59FA.FF612D99@infinet.com> Tim Bray wrote: > At 10:12 AM 2/5/99 -0800, Jeff Greif wrote: > >JDK 1.1.7 intern is native, but is slow because it first converts the > >characters in the string > > Actually, the real reason that most XML parsers will *never* use > built-in intern is because they probably have the name available in a > character array, and can go look things up in the handcrafted > table without String-i-fying it - thus skipping several steps > of work that a built-in intern is going to have to do. E.g. Lark's > symbol table is a double array, storing both the character-array > and String version of each name - you lookup based on the > character array and return the string if it's already there. The > point is that you call new String() only once per unique name. I do pretty much the exact same thing.except on each call to new String() I do something of the form: new String().intern(). This way at the application level that for element names and attribute names you can test for identity instead of equality. Since you can't exactly do something like this in any programming language I know of: String s = new String("foo"); switch (s) { case "foo": case "bar": } You need to write code like this: if (s.equals("foo")) { } else if (s.equals("bar)) { } etc. In cases where the most likely scenario is testing for equality of a lot of strings and then executing a default action as in the case of an else statement, this can get expensive. Even though calling String.intern() has a one time cost for the first occurrence of an element or attribute name, repeatedly calling String.equals() can be quite expensive too. Code of the form: if (s == "foo") else if (s == "bar") is about as fast as an integer compare and even though you may take a small performance hit at the parser level (or DOM level) in the general case you will be improving things at the application level even if you use String.equals() since the String.equals() method is of the form: public boolean equals(Object o) { if (this == o) { return true; } // Do other string comparing code } Nevertheless, the String.intern() method has a poor implementation under the hood. I don't know what kind of table the JDK is using under the hood for each JVM, but whatever implementation SUN is using is pretty lame. But despite the poor implementation of String.intern(), it is still a win at the application level to be dealing with Names that are represented as interned strings. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Feb 5 21:12:40 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:43 2004 Subject: Colonialism, SAX, Java, and Namespaces References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> <36BB0D56.EDF427B0@prescod.net> <14011.9910.776880.149972@localhost.localdomain> <36BB3BC8.F1476D09@prescod.net> Message-ID: <36BB5E85.E17C557F@infinet.com> Paul Prescod wrote: > XSL uses namespaces and nobody finds them confusing. Because XSL provides > an intuitive context and interface to the namespace concept. But take that > concept out of context and people will get confused. I have seen one XSL Stylesheet example posted by a newbie that dealt with namespaces. The fact that no one is using this supplement to XML called "Namespaces in XML" can be construed that namespaces are either too complicated or too usesless to be of any utility to these "average developers". Yah, I may be just one of the many people here complaining about namespaces, but would you rather deal with people who take a look at "Namespaces in XML" and say "what the heck is this mumbo jumbo" and ignore namespaces altogether. Any specification or so-called standard that does not achieve some level of concensus among its intended audience is nothing more than a glorified document with a bunch of "expert" names on them. Unless the W3C is in the business of wasting the time and money of its membership, I suspect that someone in the organization will be sensitive to the some of the "Namespaces in XML" concerns of this budding XML developer community. If the W3C simply ignores everyone, then everyone will eventually ignore the W3C. It is that simple. Tyler BTW, I would probably not be wasting so much of my time on this whole "Namespaces in XML" issue if the entire "Namespaces in XML" spec were not incorporated into the XSL draft (something I care much more about). xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Feb 5 21:16:58 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:08:43 2004 Subject: When to use attributes vs. elements Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEF3C@RED-MSG-08> Thank you. Dan asks a reasonable question, which is whether a document that uses the conventions described in http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.html needs to signal somehow that these conventions are in play. In case of the "canonical format" I proposed, however, I don't think special signalling is necessary: The proposal does not add any new interpretations to the use of elements or attributes beyond what can be described in a DTD or a schema such as XML-Data or DCD. Elements, attributes, ids and idrefs are carefully used so that their normal XML interpretation matches the scoping and linking rules of object graphs or relational databases. In a general case, if conventions add rules for interpretation above what is in the structure of a document or above what can be expressed in a DTD, then this would need to be somehow signalled in order for a reader to process the document. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 6 10:52:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:43 2004 Subject: Colonialism, SAX, Java, and Namespaces References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> <36BB0D56.EDF427B0@prescod.net> <14011.9910.776880.149972@localhost.localdomain> <36BB3BC8.F1476D09@prescod.net> <36BB5E85.E17C557F@infinet.com> Message-ID: <36BC1A9C.76AF9AAF@prescod.net> Tyler Baker wrote: > > I have seen one XSL Stylesheet example posted by a newbie that dealt > with namespaces. The fact that no one is using this supplement to XML > called "Namespaces in XML" can be construed that namespaces are either > too complicated or too usesless to be of any utility to these > "average developers". Some specifications are meant to be directly used by end-users: CSS. Some specifications are meant to be used by other standardizers: DTDs. Namespaces are being used in RDF, XSL, and Voyager. "Average developers" will use namespaces through those technologies and others. I do not buy your thesis that the fact that people are not yet using namespaces demonstrates that namespaces are a failure. XSL and Voyager are not standardized yet and RDF is itself quite immature in its implementations. I also do not buy the thesis that it elitist to recommend that "average developers" not waste their time learning an abstraction until infrastructure and context becomes available in order to use it. There are many technologies that I expect will be relevant to average developers at some point in the future but are not now. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Feb 6 14:58:05 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:43 2004 Subject: Colonialism, SAX, Java, and Namespaces In-Reply-To: <36BC1A9C.76AF9AAF@prescod.net> References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> <36BB0D56.EDF427B0@prescod.net> <14011.9910.776880.149972@localhost.localdomain> <36BB3BC8.F1476D09@prescod.net> <36BB5E85.E17C557F@infinet.com> Message-ID: <199902061457.JAA21847@hesketh.net> At 04:34 AM 2/6/99 -0600, Paul Prescod wrote: >I also do not buy the thesis that it elitist to recommend that "average >developers" not waste their time learning an abstraction until >infrastructure and context becomes available in order to use it. There are >many technologies that I expect will be relevant to average developers at >some point in the future but are not now. Well, I guess we'll see what the average developers do, and how they respond to such attitudes and their results in the specs. Speaking for myself as an 'average developer', I find this view infuriating, and a poor excuse to avoid the extra effort needed to make specs more immediately usable and comprehensible. On the other hand, maybe some developers don't care and it may in the long run have no significant impact. We've been over this too many times, so I'll end here with a plea to spec developers and their explainers. Make your specifications as comprehensible as you can to as wide an audience as you can, so that all of us can spend more time writing implentations and less time debating what the specs mean. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 b.laforge at jxml.com Sat Feb 6 16:03:43 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:43 2004 Subject: What Clean Specs Achieve, WAS: Colonialism, SAX, Java, and Namespaces Message-ID: <000901be51e9$a5dff3e0$c9a8a8c0@thing2> One of the big advantages of Java is that a small shop can tackle significant projects. With clean specs, the same will be true for XML. It is worth the extra effort to keep the specs as clean as possible. It goes beyond wide-acceptance. It means smaller project teams and shorter delivery times. And that makes XML a competative advantage. Bill From: Simon St.Laurent <simonstl@simonstl.com> >... Make your specifications as >comprehensible as you can to as wide an audience as you can, so that all of >us can spend more time writing implentations and less time debating what >the specs mean. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Sat Feb 6 16:11:09 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:43 2004 Subject: Colonialism, SAX, Java, and Namespaces Message-ID: <015601be51eb$2e3d8260$82aedccf@ix.netcom.com> Simon wrote, >>We've been over this too many times, so I'll end here with a plea to spec developers and their explainers. Make your specifications as comprehensible as you can to as wide an audience as you can, so that all of us can spend more time writing implentations and less time debating what the specs mean.<< I would second that. It should be just as easy to write clear English as it is to write gobblydy-gook. There is absolutely no reason why a spec. cannot be both precise and understandable. As no less a person than Albert Einstein said, "If you can't explain a proposition to an intelligent layman the proposition is probably flawed" . Specs have both 'Normative' and 'informitive' parts to them. A little more work on the informtive parts would be very useful. Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (March) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From b.laforge at jxml.com Sat Feb 6 17:40:50 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:43 2004 Subject: Colonialism, SAX, Java, and Namespaces Message-ID: <001001be51f7$374b3440$c9a8a8c0@thing2> From: Frank Boumphrey <bckman@ix.netcom.com> >I would second that. It should be just as easy to write clear English as it >is to write gobblydy-gook. My own experience is that clarity requires considerable effort, but its worth it. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Sat Feb 6 17:45:22 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:43 2004 Subject: What Clean Specs Achieve, WAS: Colonialism, SAX, Java, and Na mespaces Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054976@SOHOS002> Bill la Forge wrote: > One of the big advantages of Java is that a small shop can > tackle significant projects. With clean specs, the same will > be true for XML. > Hands up, who has read the Java spec (and that's not the same as reading the nice clear instructions given to you by the people who wrote the compiler)? Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 simonstl at simonstl.com Sat Feb 6 17:55:49 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:43 2004 Subject: What Clean Specs Achieve In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D054976@SOHOS002> Message-ID: <199902061755.MAA23664@hesketh.net> At 05:53 PM 2/6/99 +0000, Mark Birbeck wrote: >Hands up, who has read the Java spec (and that's not the same as reading >the nice clear instructions given to you by the people who wrote the >compiler)? But is anyone here trying to _implement_ Java? Lots of folks here are indeed trying to _implement_ XML 1.0 (parsers and SAX), XLink and XPointer, Namespaces, XSL, etc. It's not like we're only trying to _use_ them, as is the case with Java (or SQL, another example that's been bounced around.) Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 Sat Feb 6 17:58:17 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:43 2004 Subject: COBOL XML parser? References: <199902041412.JAA10888@hesketh.net> <wkpv7ou55z.fsf@ifi.uio.no> Message-ID: <36BC83CE.39823C2@mecomnet.de> the version in the CL-HTTP release includes a dom, a dtd parser, and validation. Lars Marius Garshol wrote: > > ... See > > <URL:http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html> > > in the contrib-directory of the distribution. > > I've tinkered a bit with a DTD parser in Common Lisp my spare time, > but since that is close to non-existent, so are the results. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 6 18:08:02 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:43 2004 Subject: What Clean Specs Achieve Message-ID: <3.0.32.19990206100726.00c02210@pop.intergate.bc.ca> At 12:58 PM 2/6/99 -0500, Simon St.Laurent wrote: > >But is anyone here trying to _implement_ Java? Lots of folks here are >indeed trying to _implement_ XML 1.0 (parsers and SAX), XLink and XPointer, >Namespaces, XSL, etc. It's not like we're only trying to _use_ them, as is >the case with Java (or SQL, another example that's been bounced around.) Most of them seem to be succeeding. What should we conclude? -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 Sat Feb 6 18:10:02 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:43 2004 Subject: Namespace Applications References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <36BAF974.6F87E679@prescod.net> <14010.65394.42870.480866@localhost.localdomain> Message-ID: <36BC80C6.B2950AF6@prescod.net> David Megginson wrote: > <email>paul@prescod.net</email> > <company>ISOGEN</company> > <a:origin>Canada</a:origin> > <b:origin>University of Waterloo</b:origin> > </member> > > ... > > The advantages of being able to come up with globally-unique names > should be obvious: Actually it isn't to me. The problem is now you have <a:origin> and <b:origin> element types but you don't know what to do with them. This is the point I keep harping about: processing expectations. Clearly <a:origin> is supposed to be mapped either to nothing or to <david:CountryOfOrigin> and <b:origin> is to be mapped either to nothing or to <david:GraduatedFrom>. It seems to me that information should not be let into my information system until it is expressed in terms that my information system is familiar with. What that means is that these things should be shipped with either architectural declarations or an XSL stylesheet that lets me locally reinterpret them. If all you want to do is make unknown elements "disappear" you can do that without namespaces also. > A second major advantage of namespaces is the ability to reuse > processing code. If I have written an event-handler/subroutine/method > to do something useful with an HTML <table> element, then I'd like to > reuse that for *every* document type that happens to use the HTML > table model, even if I don't know about the document type in advance. I can think of a variety of non-namespace ways to handle this (including the one you pointed out). Maybe I'm over-conservative but I will not advise my customers to depend on the namespace mechanism until there are facilities for validating and processing them intelligently. I mean even the most XSL-sophisticated XML editor/formatter would not recognize your namespace-prefixed HTML element if you changed the prefix because XSL itself does not handle it. I mean there is leading edge and there is bleeding edge.... -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Feb 6 18:18:18 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:43 2004 Subject: What Clean Specs Achieve In-Reply-To: <3.0.32.19990206100726.00c02210@pop.intergate.bc.ca> Message-ID: <199902061818.NAA23905@hesketh.net> At 10:07 AM 2/6/99 -0800, Tim Bray wrote: >At 12:58 PM 2/6/99 -0500, Simon St.Laurent wrote: >> >>But is anyone here trying to _implement_ Java? Lots of folks here are >>indeed trying to _implement_ XML 1.0 (parsers and SAX), XLink and XPointer, >>Namespaces, XSL, etc. It's not like we're only trying to _use_ them, as is >>the case with Java (or SQL, another example that's been bounced around.) > >Most of them seem to be succeeding. What should we conclude? -Tim Most people who don't succeed, don't announce. We can't conclude anything. Judging from the volume of questions (and controversy) on this and its sibling lists (XSL-list, xlxp-dev), there's a lot of improvement that could be made. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 Mark.Birbeck at iedigital.net Sat Feb 6 18:36:09 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:43 2004 Subject: What Clean Specs Achieve Message-ID: <A26F84C9D8EDD111A102006097C4CD0D054977@SOHOS002> Simon St.Laurent wrote: > At 05:53 PM 2/6/99 +0000, Mark Birbeck wrote: > >Hands up, who has read the Java spec (and that's not the > same as reading > >the nice clear instructions given to you by the people who wrote the > >compiler)? > > But is anyone here trying to _implement_ Java? Lots of folks here are > indeed trying to _implement_ XML 1.0 (parsers and SAX), XLink > and XPointer, > Namespaces, XSL, etc. It's not like we're only trying to > _use_ them, as is > the case with Java (or SQL, another example that's been > bounced around.) And that's the point! If you want to write a Java compiler then get down with all the specs, as well as current theory on compiler writing, grammars, languages, OO, and so on - because you're going to need it! And if you want to write an XML parser, or XSL transformer, or your own DOM then sure, get with the nitty-gritty of the specifications, but you better also get clued up on language theory - I've seen Umberto Eco quoted in some places! - meta-information, mark-up languages, and all the rest of it. But don't tell me that someone using Office 2000 to write a letter to their bank manager needs to understand namespaces. And that is not elitist, colonialist or patronising - I credit people with more intelligence than wanting to understand quantum physics before they switch the TV on. The truth is that if people want to be at the leading edge of thought in *any* discipline, then they better get used to the idea that nothing worth understanding is ever easy. If it was, it would be 'common sense' and therefore nothing new. If someone really wants to write their own parser and they are having trouble understanding namespaces, they should seriously ask if they are ready for such an undertaking. As I keep saying, I'm not arguing for specs that are *more* difficult to understand - it's not exactly the most profound utterance to say 'clearer is better'. But at the same time I personally don't immediately try to blame someone else if I don't understand something, and I particularly don't think anyone *owes* me anything. If the spec writers are good enough to spare some time and answer some of my questions I am very grateful, but it is *not* their obligation. The reality is that I have already saved hundreds of hours of work for our company by using XML. The hours and hours I spent last year, reading and re-reading, trying to understand the implications of it all, have been recovered many, many times over by the speed with which we are now able to develop web sites with our new tools. I think I have more than had my money's worth from the 'gobbledy-gook' the spec writers have produced, and my suspicion is that many people out there have too. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 begeddov at jfinity.com Sat Feb 6 19:03:14 1999 From: begeddov at jfinity.com (Gabe Beged-Dov) Date: Mon Jun 7 17:08:43 2004 Subject: Namespace Applications References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <36BAF974.6F87E679@prescod.net> <14010.65394.42870.480866@localhost.localdomain> <36BC80C6.B2950AF6@prescod.net> Message-ID: <36BC91A8.73022A96@jfinity.com> Paul Prescod wrote: > David Megginson wrote: > > ... > > > > The advantages of being able to come up with globally-unique names > > should be obvious: > > Actually it isn't to me. The problem is now you have <a:origin> and > <b:origin> element types but you don't know what to do with them. Naming something doesn't equate to being able to process it. As long as I can identify something I can always process it later, once I (or someone else) know more. Early vs. Late binding. Many "processing" scenarios are only concerned with forwarding data. An analogy is mail transfer agents and envelope vs. contents. The namespace qualified element name is the address. In David's example, there are two "origin" names. If they aren't qualified by the namespace, they won't be able to be delivered correctly. Its still up to the recipient to figure out what to do with the contents of the element once delivered. The recipient might be quite a few "hops" aways from the sender. Giving something a unique name is an end in and of itself. You may only find something useful to do with it further down the timeline or processing pipeline. Late binding is a GOOD thing as long as the late bound agent gets all of the data needed to "process". Gabe Beged-Dov www.jfinity.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Sat Feb 6 19:05:40 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:44 2004 Subject: What Clean Specs Achieve References: <199902061755.MAA23664@hesketh.net> Message-ID: <36BC93A3.2544EAC@mecomnet.de> Mark Birbeck wrote: >Hands up, who has read the Java spec (and that's not the same as reading >the nice clear instructions given to you by the people who wrote the >compiler)? i spent more time with the vm spec than with the language spec. i was more interested as to whether i could ever hope to be afforded things like closures and generic functions, the answer for which was to be found more likely in whether the vm precluded them, than in what the language designers thought of 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 simonstl at simonstl.com Sat Feb 6 19:25:30 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:44 2004 Subject: What Clean Specs Achieve In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D054977@SOHOS002> Message-ID: <199902061925.OAA24843@hesketh.net> At 06:44 PM 2/6/99 +0000, Mark Birbeck wrote: >But don't tell me that someone using Office 2000 to write a letter to >their bank manager needs to understand namespaces. You're right. They don't need to know, and most likely, they don't want to. Unfortunately, lots of people between that user and the namespace spec do need to know how to provide reliable and efficient namespace-aware processing. I'd like to think that you don't need to have Microsoft's resources to process a specification and produce reliable and efficient software. XML - even namespaces - isn't exactly rocket science. If you're willing to hit your head against the specs for a few months, which I do for a living, it becomes clear that none of this stuff is really as psychotically complicated as it seems at first. The cost of hitting your head against the specs can be prohibitive, however, if you're a small organization without extensive resources. More complex specs mean that you have to spend more resources comprehending those specs, wasting time that could have been better spent coding. Writing clean specs, clear specs, intelligible specs, helps everyone who needs to implement them, as well as the few users who straggle all the way to the specs to find out exactly why things work the way they do. It may not have a direct impact on the Office 2000 user, but it certainly could affect the choices they have among tools for processing and managing those documents beyond the Office 2000 software itself. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 tyler at infinet.com Sat Feb 6 19:54:57 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:44 2004 Subject: What Clean Specs Achieve References: <A26F84C9D8EDD111A102006097C4CD0D054977@SOHOS002> Message-ID: <36BC9DCA.C82CCC03@infinet.com> Mark Birbeck wrote: > But don't tell me that someone using Office 2000 to write a letter to > their bank manager needs to understand namespaces. And that is not > elitist, colonialist or patronising - I credit people with more > intelligence than wanting to understand quantum physics before they > switch the TV on. The truth is that if people want to be at the leading > edge of thought in *any* discipline, then they better get used to the > idea that nothing worth understanding is ever easy. If it was, it would > be 'common sense' and therefore nothing new. If someone really wants to > write their own parser and they are having trouble understanding > namespaces, they should seriously ask if they are ready for such an > undertaking. I don't consider XML even with namespaces to be anything revolutionary or bleeding edge. XML is supposedly a "standards" effort at creating a simple markup language for the web, not some technology exploration. This whole "Namespaces in XML" stuff seems unfortunately to be a technology exploration. Instead of trying something simple, the W3C decided to create something totally new. Now I am all for creativity and technical exploration, but certainly not in a standards effort. If XML is not going to be simple, why use XML at all when there supposedly are much more powerful and well-established standardized alternatives like SGML in existence that get the job done. Why should XML be just another reinvention of the wheel. I mean come on, markup should not be rocket science folks. I could create my own markup language in a small amount of time with all kinds of features, but it would not be standardized as many people would likely not agree with some of my ideas. So that is what standards are about: simplicity and concensus. Anything less and it is not a standard but a glorified document with lots of "expert" names on it. > As I keep saying, I'm not arguing for specs that are *more* difficult to > understand - it's not exactly the most profound utterance to say > 'clearer is better'. But at the same time I personally don't immediately > try to blame someone else if I don't understand something, and I > particularly don't think anyone *owes* me anything. If the spec writers > are good enough to spare some time and answer some of my questions I am > very grateful, but it is *not* their obligation. I guess this goes right down to the heart of the question of XML's intended audience. My impression was that XML was intended primarily as a simple markup language for the web. If XML is just a hyped up subset of SGML, then what good does it buy me or the majority of the web as a tool for the general user-audience. After all HTML is crap, but tons and tons of people with absolutely no programming experience can pick it up rather fast. I feel the same can be said of XML if you ignore namespaces. If "Namespaces in XML" are dropped from XSL and remain an optional layer on top of XML, then I would stop complaining right now as "Namespaces in XML" will die off on its own because only a very few people will want to use it. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Feb 6 20:08:37 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:44 2004 Subject: What Clean Specs Achieve Message-ID: <A26F84C9D8EDD111A102006097C4CD0D05497C@SOHOS002> Tyler Baker wrote: > I guess this goes right down to the heart of the question of > XML's intended audience. My > impression was that XML was intended primarily as a simple > markup language for the web. If > XML is just a hyped up subset of SGML, then what good does it > buy me or the majority of the > web as a tool for the general user-audience. It buys you loads. Imagine you want to write a tool to do presentations. Imagine you want it viewed by lots of people all over the world. If you use a Shockwave DTD for your file format then it will be. Imagine you want to embed some data into your reports that can be used by a Excel - graphed, pivoted, sorted, etc. - you could put that section of the data into Office 200 format. Imagine you want to spell check all your invoices. You could pass your data to a general purpose spell checker that doesn't just understand Word, or understand OLE documents, but understands ANY document in the entire world! The productivity increases are just too big too take in. Hyped up? > After all HTML > is crap, but tons and tons of > people with absolutely no programming experience can pick it > up rather fast. Or slow if they go and read the HTML 4.0 spec. Most intelligent people would start with 'HTML in a day'. Many on this list patronisingly think that the average user is stupid enough to want to waste their time taking the long way round. They've got better things to do! Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 Mark.Birbeck at iedigital.net Sat Feb 6 20:15:37 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:08:44 2004 Subject: What Clean Specs Achieve Message-ID: <A26F84C9D8EDD111A102006097C4CD0D05497D@SOHOS002> Simon St.Laurent to: > The cost of hitting your head against the specs can be prohibitive, > however, if you're a small organization without extensive > resources. More > complex specs mean that you have to spend more resources comprehending > those specs, wasting time that could have been better spent coding. Equally we could spend less time discussing the clarity of specs and more time trying to understand them! Anyway, the point I made in the last message was that my company has SAVED money by adopting XML - even taking into account after investing a lot of time to understand it and its implications - and we are a VERY small company. I don't know why I'm pursuing this, but here goes: there is a flaw in the logic you are following here. When technology is new and leading edge, it is generally going to be difficult to follow, because we do not have the intellectual reference points with which to understand it. There is no *absolute* measure of whether a spec is easy or difficult to understand, since it depends on the general culture of understanding. As each spec comes in, we find it easier to understand, not because it is better written, but because we are building on the previous layers of our knowledge. And then, when someone makes another big paradigm shift, we'll all be at sea again for a while. So, for you to contrast 'understanding' with 'productivity' is mistaken, because, firstly, if you do not understand the implications of a new technology, what are you going to code up anyway? Are we really worried about the ability of someone at home using a simple text editor to code up their video collection? If they wanted to do that they would be better off with a spreadsheet or writing a database app - and these tools should use XML as their native file formats. And secondly, as I said about our company, programmers do gain in the long run, because the new technology is more efficient than the old. Mark Birbeck Managing Director Intra Extra Digital Ltd. 39 Whitfield Street London W1P 5RE w: http://www.iedigital.net/ t: 0171 681 4135 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 larsga at ifi.uio.no Sat Feb 6 20:23:44 1999 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:08:44 2004 Subject: ANN: xmlproc 0.60 Message-ID: <wk3e4jcmdz.fsf@ifi.uio.no> xmlproc is a validating XML parser written in Python, which supports SAX 1.0, XML namespaces, SGML Open catalog files and XCatalog 0.1. The parser can be used for both well-formedness parsing as well as validating parsing, and the DTD parser in the package can be used separately. xmlproc can report errors in Norwegian and English, and more languages can easily be added. xmlproc can be found at: <URL:http://www.stud.ifi.uio.no/~larsga/download/python/xml/xmlproc.html> --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 clark.evans at manhattanproject.com Sat Feb 6 20:46:39 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:44 2004 Subject: What Clean Specs Achieve References: <A26F84C9D8EDD111A102006097C4CD0D054977@SOHOS002> <36BC9DCA.C82CCC03@infinet.com> Message-ID: <36BCA969.C6D66CA9@manhattanproject.com> Tyler Baker wrote: > If XML is not going to be simple, why use XML at all when there > supposedly are much more powerful and well-established standardized > alternatives like SGML in existence that get the job done. This is my understanding: * XML is for information interchange on a large international scale. * SGML was primarily created for internal manuals and specifications. Computationally, SGML has irregular structures that *require* the DTD to be known before the file can be parsed. XML does not have this restriction, it's syntax is independent of the "architecture" or DTD. More than that, this change has had only minimal "reduction" of it's usefulness, i.e., it is harder for harder for humans to diectly author in the language. This simplification has drastically reduced its computational complexity, thus enabling it to be applied in many more contexts. Namespaces is the mechanism to keep all of those contexts from colliding with each other. Architectures is the mechanism that provides the mapping between those contexts. It is this greater applicability that is driving the need for namespaces. This *is* new. No existing document interchange "syntax" has gotten this far, I would say that the INI file format and the CVS file format would have been the runners-up to XML. The complexity to which a computer program express itself using the XML syntax is far greater than CVS or INI syntax. Think of XML as a better "CVS" or "INI" format, not as a weakened SGML. This is the better metaphor. See, SGML and most other "exchange" mechanisms in the past have tied the "syntax" and the "semantics" together. XML is different. It clearly defines the syntax and leaves the "semantics" to the application of the technology. The "DTD" is optional. And Architectures allows you to have more than one DTD. This way each party to the communication can have their own interpretation of the exchange. Seperating these two is a _hudge_ leap forward in software systems. Anyway, this is my view of things. I hope it helps. :) Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Sat Feb 6 20:48:50 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:44 2004 Subject: What is XML? (Was: Re: What Clean Specs Achieve) References: <A26F84C9D8EDD111A102006097C4CD0D054977@SOHOS002> <36BC9DCA.C82CCC03@infinet.com> Message-ID: <36BCA9A0.86A77C68@manhattanproject.com> Tyler Baker wrote: > If XML is not going to be simple, why use XML at all when there > supposedly are much more powerful and well-established standardized > alternatives like SGML in existence that get the job done. This is my understanding: * XML is for information interchange on a large international scale. * SGML was primarily created for internal manuals and specifications. Computationally, SGML has irregular structures that *require* the DTD to be known before the file can be parsed. XML does not have this restriction, it's syntax is independent of the "architecture" or DTD. More than that, this change has had only minimal "reduction" of it's usefulness, i.e., it is harder for harder for humans to diectly author in the language. This simplification has drastically reduced its computational complexity, thus enabling it to be applied in many more contexts. Namespaces is the mechanism to keep all of those contexts from colliding with each other. Architectures is the mechanism that provides the mapping between those contexts. It is this greater applicability that is driving the need for namespaces. This *is* new. No existing document interchange "syntax" has gotten this far, I would say that the INI file format and the CVS file format would have been the runners-up to XML. The complexity to which a computer program express itself using the XML syntax is far greater than CVS or INI syntax. Think of XML as a better "CVS" or "INI" format, not as a weakened SGML. This is the better metaphor. See, SGML and most other "exchange" mechanisms in the past have tied the "syntax" and the "semantics" together. XML is different. It clearly defines the syntax and leaves the "semantics" to the application of the technology. The "DTD" is optional. And Architectures allows you to have more than one DTD. This way each party to the communication can have their own interpretation of the exchange. Seperating these two is a _hudge_ leap forward in software systems. Anyway, this is my view of things. I hope it helps. :) Clark Evans xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dan at holle.demon.co.uk Sat Feb 6 22:04:48 1999 From: dan at holle.demon.co.uk (Dan Holle) Date: Mon Jun 7 17:08:44 2004 Subject: DTD: Extra Complexity? In-Reply-To: <wk3e4jcmdz.fsf@ifi.uio.no> Message-ID: <000001be521b$991c0ea0$0400a8c0@dan.perrysfield> Many applications I've seen, and a few that I have created, don't validate the XML against a DTD. Is the DTD an extra step, inherited from SGML, that doesn't really fit XML? --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 clark.evans at manhattanproject.com Sat Feb 6 22:21:11 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:44 2004 Subject: DTD: Extra Complexity? References: <000001be521b$991c0ea0$0400a8c0@dan.perrysfield> Message-ID: <36BCBF9A.C168DDC3@manhattanproject.com> Dan Holle wrote: > Many applications I've seen, and a few that I have > created, don't validate the XML against a DTD. > Is the DTD an extra step, inherited from SGML, > that doesn't really fit XML? XML defines the basic syntax (elements, attributes, entities) A DTD defines how the syntax is structured, i.e., the relationships among the elements and attributes. First, a DTD is optional. This will depend upon your context. If an XML stream has one and only one set of structural rules which define the document, then a single DTD is appropriate. Second, when you have many users of the XML stream, each with different needs, a single DTD dosn't work. You need many. This is what architectural forms allows to happen. It super-imposes the structure of one or more DTD's upon an XML stream. In this case, the DTD declaration is omitted, and another syntax is used to bind the DTD to the document. Third, if it is hard to define "when" the stream begins or ends (i.e. it's not a file), or if the DTD is implicitly understood at both the source and the destination of the message, then it is perfectly acceptable to omit the DTD. Does help? :) Clark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sblackbu at erols.com Sat Feb 6 22:44:43 1999 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:08:44 2004 Subject: Extra Complexity? Message-ID: <003101be5222$38f5ef80$01010101@sammy> It depends on how you use XML. If you use it to transfer data between applications then DTD's are completely useless. Their assumption that the world is flat is inappropriate for data applications. Also, the validations performed using DTD's don't buy you anything. The application must perform its own validation based upon some business rules. DTD's allow you to "validate" that a field contains a number but you can't use DTD's to "validate" that a field contains a prime number (that is an application layer validation). If you want to replace HTML (i.e. pretty text) then DTD's become useful. HTH, Sam http://ourworld.compuserve.com/homepages/sam_blackburn -----Original Message----- From: Dan Holle <dan@holle.demon.co.uk> To: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk> Date: Saturday, February 06, 1999 5:07 PM Subject: DTD: Extra Complexity? >Many applications I've seen, and a few that I have created, don't validate >the XML against a DTD. > >Is the DTD an extra step, inherited from SGML, that doesn't really fit XML? > >--dan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sat Feb 6 22:51:48 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:44 2004 Subject: Extra Complexity? In-Reply-To: <003101be5222$38f5ef80$01010101@sammy> from "Samuel R. Blackburn" at Feb 6, 99 05:44:13 pm Message-ID: <199902062342.SAA12353@locke.ccil.org> Samuel R. Blackburn scripsit: > It depends on how you use XML. If you use it to transfer > data between applications then DTD's are completely useless. Not so. DTDs make sure that container elements have the appropriate content, provide default information, and allow access to non-XML components in a standardized way. They also permit the representation of data that is not a tree, and even allow datatype declarations. Furthermore, they allow limited amounts of data reuse. > Their assumption that the world is flat is inappropriate for > data applications. What do you mean by "flat"? > Also, the validations performed using DTD's > don't buy you anything. The application must perform its own > validation based upon some business rules. DTD validation is often not sufficient, but that does not mean that it is not useful. > DTD's allow you > to "validate" that a field contains a number but you can't use > DTD's to "validate" that a field contains a prime number (that > is an application layer validation). In fact, XML DTDs do *not* allow you to validate that a "field" (whether than means an attribute value or #PCDATA content) is numeric. > If you want to replace HTML (i.e. pretty text) then DTD's become > useful. They are useful for far more than that. Documents are complex data, and simple data can also benefit from what is downright essential for complex data. -- 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 b.laforge at jxml.com Sat Feb 6 23:06:19 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:44 2004 Subject: MDSAX beta2 includes filters for namespace and architectural forms Message-ID: <001201be5224$b199cea0$c9a8a8c0@thing2> MDSAX 1.0 beta 2 is now available at: http://www.jxml.com/mdsax/index.html This release includes a context markup language for defining filter structures. A number of filters are included with this release, among them o John Cowan's namespace filter and o David Megginson's XAF filter for Architectural Forms. This is Open Source Software: http://www.jxml.com/License.txt Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Sat Feb 6 23:47:34 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:45 2004 Subject: Namespaces and interoperability (was Re: SAX, Java, and Namespaces) In-Reply-To: <8025670F.005165A0.00@mailhost.agora.co.uk> Message-ID: <4.1.19990207104017.00c3ebe0@steptwo.com.au> At 00:48 6/02/1999 , hpyle@agora.co.uk wrote: | Paul Prescod wrote, | > I don't think that "average developers" need to worry about namespaces. | ... | > If you are building a | > typical one-organization application then what are you doing with "other | > people's tags" in your documents? | | Maybe my perspective is a little warped. I'm working on healthcare | applications in the UK - interoperability will (sometime) become a big | deal. :-) Well, let me put it like this then: You are working out a structured interchange format. If you want structure, you'll need a DTD, otherwise there is absolutely no way of validating that you have got correct data. If you have a DTD, then namespaces are irrelevant: they simply don't work together in any meaningful way. Or to put it another way: allowing arbitrary nesting of someone else's tags doesn't achieve anything. You still have to know what to do with them when you receive them. In summary: get stuck into writing a DTD, and ignore this whole "namespaces" mess ... J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Sat Feb 6 23:51:50 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:45 2004 Subject: Average developers (was Re: Colonialism, SAX, Java, and Namespaces) In-Reply-To: <199902051513.KAA01453@hesketh.net> References: <36BAF974.6F87E679@prescod.net> <8025670F.002EF9AD.00@mailhost.agora.co.uk> Message-ID: <4.1.19990207104529.00b6e260@steptwo.com.au> At 01:12 6/02/1999 , Simon St.Laurent wrote: | I would really appreciate if someday the people building W3C specs would | acknowledge that 'average developers' actually do have to worry about | namespaces, notations, parameter entities, include/ignore sections, and | trying to read the specs themselves. If they would then take that knowledge | and apply it to the specification-writing process, from start to finish, we | might be able to move forward with a lot less back-and-forth about what | these things are really supposed to mean. Simon, I would ask: _why_ does the average developer need all this complexity? I've been tacking jobs big and small, in the real world, for some time now. And I haven't bothered with any of it. Simple DTDs can take you a hell of a long way ... (Namespaces are simply meaningless in 99% of real-world apps, for without DTDs, you have nothing.) Just my $0.02 of course ... ;-) J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Sun Feb 7 00:00:09 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:45 2004 Subject: RDF (was Re: Colonialism, SAX, Java, and Namespaces) In-Reply-To: <3.0.5.32.19990205085933.009b1a30@library.berkeley.edu> References: <36BB0D56.EDF427B0@prescod.net> <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> Message-ID: <4.1.19990207105247.00c75ca0@steptwo.com.au> At 02:59 6/02/1999 , Jerome McDonough wrote: | I would argue, actually, that most average developers are going to have | to deal with RDF. With the proliferation of information that all | organizations are having to cope with, metadata to keep track of the | information will be more and more essential. And RDF seems to be gaining | significant mindshare as the way to store metadata among the SGML/XML | crowd. If that trend continues, any developer working in medium-to-large | organizations is going to be dealing with RDF, and hence, namespaces. | This doesn't necessarily argue for any changes in the namespace spec, | but assumptions that the average developer isn't going to have to deal | with RDF (or any other metadata encoding standard) may be a bit rash. Talking about RDF ... At the last XML conference in Sydney, there was a speaker presenting this wonderful new standard called RDF. I took the opportunity to ask a few questions ... Since RDF uses namespaces, it obviously doesn't have a DTD. Now since the intention is to store a lot of data in RDF, how do we check that a RDF file is correct and meaningful? How do we validate it? (Yes, this is a naive question.) J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jborden at mediaone.net Sun Feb 7 00:13:46 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:45 2004 Subject: Namespaces and DTDs was RE: Namespaces and interoperability (was Re: SAX, Java, and Namespaces) In-Reply-To: <4.1.19990207104017.00c3ebe0@steptwo.com.au> Message-ID: <000101be522e$12c53580$d3228018@jabr.ne.mediaone.net> James Robertson wrote: > > Well, let me put it like this then: > > You are working out a structured interchange format. If you > want structure, you'll need a DTD, otherwise there is absolutely > no way of validating that you have got correct data. > > If you have a DTD, then namespaces are irrelevant: they simply > don't work together in any meaningful way. > > Or to put it another way: allowing arbitrary nesting of someone > else's tags doesn't achieve anything. You still have to know > what to do with them when you receive them. > > In summary: get stuck into writing a DTD, and ignore this > whole "namespaces" mess ... > It has been previously discussed that we need to use the namespace prefix as declared in the DTD in order to validate XML documents with namespaces. Would explicit declaration of namespace URIs as an attribute allow *namespace aware validators* to correctly validate documents in namespace URI dependent way as opposed to a prefix dependent way. Use attribute declarations to declare namespaces: <!ELEMENT example (a|b|aaa:p|xxx:y)> <!ATTLIST example xmlns:aaa CDATA #DEFAULT "urn:aaa" xmlns:xxx CDATA #DEFAULT "urn:xxx"> <!ELEMENT xxx:y (#PCDATA)> <!ELEMENT html:p (#PCDATA)> so <example> <aaa:p> whatever </aaa:p> <xxx:y> something else </xxx:y> </example> is valid as well as <example xmlns:bbb="urn:aaa" xmlns:yyy="urn:xxx"> <bbb:p> another </bbb:p> <yyy:y> example </yyy:y> </example> Is this what has been suggested before (and I am just getting it :-)? 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 bckman at ix.netcom.com Sun Feb 7 02:03:07 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:45 2004 Subject: Extra Complexity? Message-ID: <00ed01be523d$d825ef40$87addccf@ix.netcom.com> >Many applications I've seen, and a few that I have created, don't validate >the XML against a DTD. > >Is the DTD an extra step, inherited from SGML, that doesn't really fit XML? > The real value of a DTD is as a check on the author, to make sure that the document has a consistent structure. If I am searching through a document using the DOM it is always nice to know that myDoc.firstChild.lastChild.firstChild.nodeValue will access the content of the same kind of element. If I am building a document by machine I will not always use a DTD, but if a fallible human has access to the document it should always be validated after any 'hand-rolled' change is made. That way I know that my document has a consistent structure. In summary when I am authoring a document I will always check its validity, but when displaying a document I will not check it for validity, only for well formedness. Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (March) ----- Original Message ----- From: Dan Holle <dan@holle.demon.co.uk> To: <xml-dev@ic.ac.uk> Sent: Saturday, February 06, 1999 4:56 PM Subject: DTD: Extra Complexity? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sun Feb 7 03:42:46 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:45 2004 Subject: A critique of XML-RPC Message-ID: <199902070433.XAA23875@locke.ccil.org> I have read the XML-RPC specification at http://www.scripting.com/frontier5/xml/code/rpc.html with great interest. I have the following issues with it: 1) There is no support for internationalization, despite the support present in XML. Since the MIME type is text/xml (as opposed to application/xml), the character encoding is US-ASCII unless overridden. No mention is made of support for character references like † (DOUBLE DAGGER). I would suggest supporting either "text/xml; charset='utf-8'". In addition, the references to "ASCII" in the spec should be changed. 2) There is no support for integers longer than 32 bits. I suggest allowing <int> values to be arbitrarily large, reserving the <i4> tag for 32-bit signed values. This would be an upward compatible extension for senders; receivers would have to check whether <int> data was in fact within the 32-bit signed range if backward compatibility is desired. 3) Floats are fairly useless because no rules exist for setting limits. I suggest that no receiver be allowed to reject a value which can be represented in 32-bit IEEE floats: between 1e-149 and 1e104, positive or negative, or zero. 4) The statement that "A string can be used to encode binary data" cannot be true, because arbitrary binary data cannot appear in XML documents: there is no way to represent bytes of value 0-8, 11-12, or 14-31. This is only a documentation consideration, as the base64 element does allow the representation of arbitrary binary data. 5) The very limited fault struct means that more complex exceptions such as Java, Python, or C++ support must be flattened into strings for return to the client, even though XML-RPC has ways of encoding more complex objects. I suggest allowing a struct within a fault object. -- 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 jborden at mediaone.net Sun Feb 7 04:12:32 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:45 2004 Subject: What Clean Specs Achieve In-Reply-To: <3.0.32.19990206100726.00c02210@pop.intergate.bc.ca> Message-ID: <000201be524f$72cec4c0$d3228018@jabr.ne.mediaone.net> We should conclude that simple is good. Efforts like the 'annotated XML spec' are a big help. In most specs a few well chosen examples greatly add to formalisms. Questions and controversies are bound to happen, especially with new technology. The proof will not be the existence of XML parsers, rather applications which are adopted by the general public (e.g. html). specs alone can't take us there. > > > >But is anyone here trying to _implement_ Java? Lots of folks here are > >indeed trying to _implement_ XML 1.0 (parsers and SAX), XLink > and XPointer, > >Namespaces, XSL, etc. It's not like we're only trying to _use_ > them, as is > >the case with Java (or SQL, another example that's been bounced > around.) > > Most of them seem to be succeeding. What should we conclude? -Tim > 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 uche.ogbuji at fourthought.com Sun Feb 7 07:07:22 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:08:45 2004 Subject: CORBA's not boring yet. / XML in an OS? In-Reply-To: Your message of "Thu, 04 Feb 1999 16:36:49 PST." <3.0.6.32.19990204163649.00f40e20@scripting.com> Message-ID: <199902070709.AAA07204@malatesta.local> > Gotta check it out! XML-RPC.. What CORBA wants to be. ;-> > > http://www.xmlrpc.com/ <DeLurkAndFlameOn> For one who recently made a clumsy swipe at another to the effect that they like to hear themselves talk, you are no slouch in the department of vacuous, self-promotional, and frequently off-topic cant. First I read here that CORBA is "heavyweight", and now that it is a mere shadow of XML-RPC. I guess one can say anything about an unrelated technology from the safe confines of an XML list. </DeLurkAndFlameOn> -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 7 07:40:59 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:08:45 2004 Subject: Component Markup Language Message-ID: <0bec01be526d$42222740$0300000a@othniel.cygnus.uwa.edu.au> >> >Has anyone thought about or worked on an markup language to describe a >> >User Interface in a platform independent way? About a year ago I toyed with the idea of doing an XML representation of Visual Basic forms. I didn't put too many cycles into it because I figured Microsoft would do it at some stage. 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 Sun Feb 7 08:04:15 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:08:45 2004 Subject: CORBA's not boring yet. / XML in an OS? Message-ID: <0d2701be5270$824dbca0$0300000a@othniel.cygnus.uwa.edu.au> >Anyhow, this naturally makes me wonder - could XML and related ideas >like XSL have a place in an operating system? Where would they fit in? >KDE and Gnome could be great playgrounds for trying something like this >out. For a while now, I've been thinking what an OS (or more likely shell) would look like if it took Unix's "everything as a file" to "everything as an XML element". A system would be a single XML "uberdocument" (physically, separate entities, including unparsed for any non-XML files on the system but logically, the one XML document). Applications (which would themselves be nodes in the element tree) would operate on other nodes in the element tree. There would be an application, for example, that got mail via POP or IMAP, represented it in XML and then attached it a particular point in the uberdocument. XSL could be used to sort the mail. XSL would also be used to view the mail. It's XML for the sake of it, but I think it would be fun to try out. 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 uche.ogbuji at fourthought.com Sun Feb 7 08:09:15 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:08:45 2004 Subject: What Clean Specs Achieve, WAS: Colonialism, SAX, Java, and Na mespaces In-Reply-To: Your message of "Sat, 06 Feb 1999 17:53:24 GMT." <A26F84C9D8EDD111A102006097C4CD0D054976@SOHOS002> Message-ID: <199902070810.BAA07298@malatesta.local> Bill la Forge: > > One of the big advantages of Java is that a small shop can > > tackle significant projects. With clean specs, the same will > > be true for XML. Mark Birbeck: > Hands up, who has read the Java spec (and that's not the same as reading > the nice clear instructions given to you by the people who wrote the > compiler)? I have. Both the core language and the library specs, about three years ago (just about when 1.0 came out). They were very simple, clear, and even more useful than many of the textbooks I have since seen. They were certainly superior to any of the W3C specs I've read (and I've read HTML 4.0, XML 1.0, Namespaces, DOM 1.0, XLink, XPointer, and XSL). In fact, despite what Paul says, I often try to learn new technologies by reading the specs directly. I have had varying success, but I don't intend to change my habits any time soon, despite my experiences with the W3C. A lot of people appear to be ducking the fact that one _can_ write clear, concise and readable specs without sacrificing the necessary precision and formality: it just requires effort. I don't know whether the problems with W3C specs come from lack of inclination towards such effort, or lack of resources for such effort. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From uche.ogbuji at fourthought.com Sun Feb 7 08:25:31 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:08:45 2004 Subject: What Clean Specs Achieve In-Reply-To: Your message of "Sat, 06 Feb 1999 10:07:48 PST." <3.0.32.19990206100726.00c02210@pop.intergate.bc.ca> Message-ID: <199902070827.BAA07349@malatesta.local> > >But is anyone here trying to _implement_ Java? Lots of folks here are > >indeed trying to _implement_ XML 1.0 (parsers and SAX), XLink and XPointer, > >Namespaces, XSL, etc. It's not like we're only trying to _use_ them, as is > >the case with Java (or SQL, another example that's been bounced around.) > > Most of them seem to be succeeding. What should we conclude? -Tim I have worked on teams implementing DOM, XSL and parts of XLL. Some users might grant that we have been "succeeding", but let me assure you that if so, it is despite the W3C specs, not because of them. DOM, especially is unforgivably inconsistent, incomplete, and unclear for a production-ready (1.0) specification. Then there is the matter that it blithely violates other specs, such as CORBA's IDL, making weak excuses all the while ("but we had to support ECMAScript, don't you know?") Others here have spoken for me as to the confusing nature of the Namespaces spec, and what I find interesting is that you claim you were trying to make that spec simple. As another has said, clearly if such intelligent people are so baffled by a document whose scope and effect is meant to be simple, there are likely problems with the document. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Sun Feb 7 08:55:34 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:08:45 2004 Subject: CORBA's not boring yet. / XML in an OS? Message-ID: <01fe01be5276$e1d65050$5402a8c0@oren.capella.co.il> >James Tauber <jtauber@jtauber.com> wrote: >>For a while now, I've been thinking what an OS (or more likely shell) would >>look like if it took Unix's "everything as a file" to "everything as an XML >>element". > > >Nice thought. Well, since we're talking about exotic systems, why don't you >start with Plan9, which takes "everything is a file" much beyond a normal >UNIX. Maybe you could "simply" wrap it with an XML driver layer... Probably >not but it would be an interesting study. Anyone looking for an operating >system related thesis subject? :-) > >Have fun, > > Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Sun Feb 7 10:39:00 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:08:45 2004 Subject: document vs non-document entity (was Re: CORBA's not boring yet. / XML in an OS?) Message-ID: <0e2401be5286$1f471500$0300000a@othniel.cygnus.uwa.edu.au> One (serious) issue that imediately arises out of my XML ?berdocument system is that there is a difference in XML between the document entity and other entities: the existence of the prolog. If an XML document has a empty prolog, there is no problem because an XML document entity with an empty prolog is a legal external parsed entity. However, the moment you have an XML declaration or document type declaration, the entity can no longer act as an external parsed entity. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Associate Researcher, Electronic Commerce Network Curtin University of Technology, Perth, Western Australia Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Feb 7 13:39:05 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:45 2004 Subject: document vs non-document entity (was Re: CORBA's not boring yet. / XML in an OS?) In-Reply-To: <0e2401be5286$1f471500$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <199902071338.IAA13969@hesketh.net> At 06:38 PM 2/7/99 +0800, James Tauber wrote: >One (serious) issue that imediately arises out of my XML ?berdocument system >is that there is a difference in XML between the document entity and other >entities: the existence of the prolog. > >If an XML document has a empty prolog, there is no problem because an XML >document entity with an empty prolog is a legal external parsed entity. >However, the moment you have an XML declaration or document type >declaration, the entity can no longer act as an external parsed entity. I like the uberdocument OS concept very much (as those who suspect my XML-everywhere sympathies probably guessed.) The doctype declaration issue is a significant problem for a single-document model. I think there may be two ways out, however: 1) Hope that the schema spec uses some other mechanism to connect to documents (and document fragments) that isn't as disruptive. 2) Use a master document that has connections to other documents, using XLink to manage relationships within the set of documents. This way you can have all the prologs and DTDs you like, though you'd need another level of organization. Hmmm... fun idea! I've been thinking a lot about XML as resource files, which is where the thoughts above came from, but you've gone a few orders of magnitude past that. Simon St.Laurent XML: A Primer / Building XML Applications (March) Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Sun Feb 7 13:41:17 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:08:45 2004 Subject: A critique of XML-RPC In-Reply-To: <199902070433.XAA23875@locke.ccil.org> Message-ID: <3.0.6.32.19990207054425.00d411c0@scripting.com> John thanks for the interest and comments. I posted them on our discussion group so other people involved with XML-RPC can see them. http://discuss.userland.com/msgReader$2736 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 James.Anderson at mecomnet.de Sun Feb 7 13:59:35 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:45 2004 Subject: Namespaces and DTDs was RE: Namespaces and interoperability (was Re: SAX, Java, and Namespaces) References: <000101be522e$12c53580$d3228018@jabr.ne.mediaone.net> Message-ID: <36BD9D72.D5761541@mecomnet.de> yes, it has been suggested before, and yes it does work. note that, as one is using the uri-bindings, one does not "use the namespace prefix". if the prefixes in the dtd are not identical with those in the document, then one need only establish scoping rules the bindings effected by attlist declarations. note that the approach is unorthodox. it violates one of the unspoken namespace tenets: that they do not affect the validity of a document. time will tell if this holds up. please note, that your example happens to have an unbound "html" prefix. it is missing an attlist declaration to the effect of <!ATTLIST html:p xmlns:html CDATA #DEFAULT "urn:aaa" > i would also suggest that the attlist-based binding is to be preferred to deferring the disambiguation until the document is read: it does not preclude alternative prefixes while at the same time making it possible to determine whether the dtd is complete before beginning to parse/process the document. Borden, Jonathan wrote: > > James Robertson wrote: > > > > If you have a DTD, then namespaces are irrelevant: they simply > > don't work together in any meaningful way. The "any" in this statement is in error. > ... > > It has been previously discussed that we need to use the namespace prefix > as declared in the DTD in order to validate XML documents with namespaces. > > Would explicit declaration of namespace URIs as an attribute allow > *namespace aware validators* to correctly validate documents in namespace > URI dependent way as opposed to a prefix dependent way. > > Use attribute declarations to declare namespaces: > > <!ELEMENT example (a|b|aaa:p|xxx:y)> > <!ATTLIST example > xmlns:aaa CDATA #DEFAULT "urn:aaa" > xmlns:xxx CDATA #DEFAULT "urn:xxx"> > <!ELEMENT xxx:y (#PCDATA)> > <!ELEMENT html:p (#PCDATA)> > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Sun Feb 7 14:24:21 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:46 2004 Subject: document vs non-document entity (was Re: CORBA's not boring yet. / XML in an OS?) References: <0e2401be5286$1f471500$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <36BDA33D.31D92896@mecomnet.de> Which implies that references would be through links rather than entity references and that the focus is not the document, but the element, element-range, or whatever link semantic the OS implements. If the "standard" link is to the root element, then it would have the same effect as the file systems which have distinguish resource from data forks or support file headers, but provide the "data" as the standard file content. It would be XML, just not literal XML. James Tauber wrote: > > One (serious) issue that imediately arises out of my XML ?berdocument system > is that there is a difference in XML between the document entity and other > entities: the existence of the prolog. > > If an XML document has a empty prolog, there is no problem because an XML > document entity with an empty prolog is a legal external parsed entity. > However, the moment you have an XML declaration or document type > declaration, the entity can no longer act as an external parsed 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 James.Anderson at mecomnet.de Sun Feb 7 15:39:18 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:46 2004 Subject: Namespace Applications References: <8025670F.002EF9AD.00@mailhost.agora.co.uk> <36BAF974.6F87E679@prescod.net> <14010.65394.42870.480866@localhost.localdomain> <36BC80C6.B2950AF6@prescod.net> Message-ID: <36BDB4C7.453E619A@mecomnet.de> Paul Prescod wrote: > > David Megginson wrote: > > <email>paul@prescod.net</email> > > <company>ISOGEN</company> > > <a:origin>Canada</a:origin> > > <b:origin>University of Waterloo</b:origin> > > </member> > > > > ... > > > > The advantages of being able to come up with globally-unique names > > should be obvious: > > Actually it isn't to me. The problem is now you have <a:origin> and > <b:origin> element types but you don't know what to do with them. This is > the point I keep harping about: processing expectations. So long as one remains in the "encoded XML" domain, the names are (modulo validation) academic. XML is one thing, and one thing only: a *code* - that is a specified collection of symbols with a collection of permitted relations. Which means that there is no semantics to be concerned with. There should be no exectation that namespaces change that. A semantics appears exactly at the point where the relation to the source and/or target domain is specified. Which cannot happen in the code itself. It happens at the point where a document becomes an *encoding* of something else. At this point one *does* know "what to do with them" because the domain to which one is decoding includes a process specification, or constraints on values, or whatever. At which point the question becomes "is the encoding complete and consistent?" At which point unambiguous names are essential. The essential requirement is not that of correct names. (cf. the <david:CountryOfOrigin> point below.) Neither is it that of correct relations. (cf. the XSL/ EA point below). It is that of unambiguous names. > Clearly > <a:origin> is supposed to be mapped either to nothing or to > <david:CountryOfOrigin> and <b:origin> is to be mapped either to nothing > or to <david:GraduatedFrom>. It seems to me that information should not be > let into my information system until it is expressed in terms that my > information system is familiar with. Iff an application has a "{a=}origin", it can determine that the intended treatment is that of "{david}CountryOfOrigin". "XML Namespaces" permit the application to delay until the point of decoding the binding of an encoded name to a symbol in the application domain. Iff this is possible, then a *direct mapping* to the application domain is possible. Which is why similar facilities must be supported within enabling architectures, which interpose additional encodings as proxies for the eventual application domain. > > What that means is that these things should be shipped with either > architectural declarations or an XSL stylesheet that lets me locally > reinterpret them. Iff there is a mismatch between the immediate decoded domain and the eventual application domain, then there is more to do. I suggest, however, that this is not intrinsically a decoding problem and, as such, has only indirectly to do with namespaces. As noted, it can be handled with mechanisms such as those provided by XSL or enabling architectures, but need not be. Note also, that to literally "ship" documents with a stylesheet begs the question. The eventual binding is to be specified by the receiving process, not the sending process. To augment them at the receiving end is a possibility, but overlooks that there are alternative application mechanisms to do much of that for which one would use architectural forms or XSL transformations. In cases where the application environment does not provide the necessary mechanisms, I'd put my money on XSL, as it supports more extensive transformations than enabling architectures. The combination (namespaces + XSL) also provides a better separation of the two mechanisms. The combination is unavoidable. Unless one is willing to express all XSL patterns in a context dependant form, then unambiguous names remain a requirement and some sort of namespace mechanism is a prerequisite to guaranteed matches. If one is willing to limit patterns to context dependent expressions and to presume complete documents as reference targets, then one would succeed at pushing the problem back to that of ensuring "unique document type names". xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 7 15:39:21 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:46 2004 Subject: "Clean Specs" References: <199902070827.BAA07349@malatesta.local> Message-ID: <36BDAF1D.A908F8EF@prescod.net> What is a "clean spec?" People in this discussion are mixing together a variety of things that I do not consider the same. Uche Ogbuji wrote: > I have worked on teams implementing DOM, XSL and parts of XLL. Some users > might grant that we have been "succeeding", but let me assure you that if so, > it is despite the W3C specs, not because of them. DOM, especially is > unforgivably inconsistent, incomplete, and unclear for a production-ready > (1.0) specification. There is not a SINGLE person on this mailing list that would say that it is right to create specifcations that are inconsistent, incomplete or unclear. It is beyond doubt that specifications in the XML family, including XML itself, have these problems. The question is how to avoid that? * some people say that what the spec needs is "more English". But much of the problem with the namespaces specification comes from ambiguity in the English. * some people say that we need "more non-normative text" but once again, it is a non-normative appendix that is confusing people. What almost nobody has suggested is that we need more formal notation. Now if we look at James Clark's "clarifying" document what we see is *less* English text and *more* notation. As David Megginson has pointed out, when a spec. invents a notation to explain its abstract concepts the spec. becomes temporarily harder to read because you have to learn the notation before the specification. This will turn people off. I remember that Algebraic notation turned me off in my first year math classes. But in the *long run* it makes life easier for everyone. Implementors have precise definitions of what the hell they are supposed to implement. End-users get software they can use. People reading the specification for their own education and edification will understand it better -- if they perservere through the task of learning the notation. I know that W3C spec. writers are under pressure to use more normative English and less normative notation. This is not a vote for "clean" specifications. It is a vote for messy, hard-to-implement ones. Where is Dan Connolly when you need him? Let me point out: the CSS and HTML specifications are easy to read because everyone who wants to read them already understands the basic concepts of web pages and layout. They are concrete implementations of ideas we already understand. The same goes for Java. (and yes, I read the Java specification, but AFTER I already knew Java) I wonder if anyone on this list has ever learned a language that was radically different from what they already knew through the language specification: Scheme, Prolog, APL? Technical writing is damn hard. When you do it right, you must make certain decisions about ordering of concepts and revelations that are the exact opposite of what you do in writing a specification. When you write a spec., you need to present things in the order of fundamental building blocks to high level concepts. In technical writing you will put your students to sleep if you zoom in on details before explaining the general framework. I've told people who want to read the DSSSL specification to start at the back and work forwards. Of course once they become implementors then they read it the opposite way around. Life is hard for implementors. I'd rather be forced to implement the entire suite of XML specifcations over HTML/CSS 2. That isn't a slight against HTML/CSS, it's just an attempt to put things in perspective. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 7 15:53:16 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:46 2004 Subject: document vs non-document entity (was Re: CORBA's not boring yet. / XML in an OS?) References: <0e2401be5286$1f471500$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <36BDB21C.36D0EE83@prescod.net> James Tauber wrote: > > One (serious) issue that imediately arises out of my XML ?berdocument system > is that there is a difference in XML between the document entity and other > entities: the existence of the prolog. This is a serious problem inherited from SGML. It is my opinion that instead of namespace declarations being done through attributes they should have been just another form of PI-based declaration. Then in version 2.0 of XML, all declarations should have been made "localizable." In particular, there should be a way to declare internal text entities, unparsed entities and attribute defaults locally. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 7 15:57:05 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:46 2004 Subject: Extra Complexity? References: <003101be5222$38f5ef80$01010101@sammy> Message-ID: <36BDB39B.97433230@prescod.net> "Samuel R. Blackburn" wrote: > > It depends on how you use XML. If you use it to transfer > data between applications then DTD's are completely useless. > Their assumption that the world is flat is inappropriate for > data applications. DTDs model tree structures. > Also, the validations performed using DTD's > don't buy you anything. The application must perform its own > validation based upon some business rules. DTD's allow you > to "validate" that a field contains a number but you can't use > DTD's to "validate" that a field contains a prime number (that > is an application layer validation). So what you are saying is that because DTDs do not do everything you could dream of, they should not be used for anything? A more effective point of view is: "use DTDs for the 90% of the problem that they CAN solve, but expect to require application-specific logic for the 10% that they CANNOT." When "XML Schemas" come about, that number may shift to 95% and 5% but the basic principles will not. I'm fairly confident that there will be no provision for validating that a number is prime, unless it is through an "escape mechanism." DTDs also have an "escape mechanism". Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 7 16:00:31 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:46 2004 Subject: RDF (was Re: Colonialism, SAX, Java, and Namespaces) References: <36BB0D56.EDF427B0@prescod.net> <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> <4.1.19990207105247.00c75ca0@steptwo.com.au> Message-ID: <36BDB47A.35407949@prescod.net> James Robertson wrote: > > > Now since the intention is to store a lot of data in > RDF, how do we check that a RDF file is correct > and meaningful? > > How do we validate it? There is such a thing as an "RDF schema". It checks an almost disjoint set of things from what a DTD would check. If you don't care about things being in a particular order and want to treat linking and containment as the same thing, then you should use RDF schemas. If you do care about the order of things, you should use DTDs. You could also use them together to check different things. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Feb 7 16:32:39 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:46 2004 Subject: "Clean Specs" In-Reply-To: <36BDAF1D.A908F8EF@prescod.net> Message-ID: <000001be52b6$d54f1d90$d3228018@jabr.ne.mediaone.net> Paul raises some important points here. The question is as to what is the best way to write specs, best being efficient and clear. The namespace spec is often used as an example of an unclear spec. I do not agree with this. When I read the namespace spec it is very clear. My misunderstandings of the spec have come almost entirely from *every thing everyone else has been saying* about namespaces rather than the spec itself. Being somewhat of a neophyte, I assumed that there existed concepts within about namespaces that I missed from the very simple spec. The simplicity of the namespace spec was driven home by the examples James Clark has given. To me this is an excellent example of why a spec should be written in 3 parts: a formal specification (BNF or whatever), a plain english description, lots of good examples. Here is my plain english distillation of namespaces: Namespaces are a way to distinguish element and attribute names using URI's so that element and attribute names can be reused without causing problems for software. << formal description here >> For example ... Paul is correct that formalisms obfuscate specs for neophytes. The problem is that english is ambiguous. For those of us who can't read formalisms nor english a good set of examples are needed. The best RFCs contain these three parts. Jonathan Borden http://jabr.ne.mediaone.net > > > What is a "clean spec?" > > People in this discussion are mixing together a variety of things that I > do not consider the same. > > Uche Ogbuji wrote: > > I have worked on teams implementing DOM, XSL and parts of XLL. > Some users > > might grant that we have been "succeeding", but let me assure > you that if so, > > it is despite the W3C specs, not because of them. DOM, especially is > > unforgivably inconsistent, incomplete, and unclear for a > production-ready > > (1.0) specification. > > There is not a SINGLE person on this mailing list that would say that it > is right to create specifcations that are inconsistent, incomplete or > unclear. It is beyond doubt that specifications in the XML family, > including XML itself, have these problems. The question is how to avoid > that? > > * some people say that what the spec needs is "more English". But much of > the problem with the namespaces specification comes from ambiguity in the > English. > > * some people say that we need "more non-normative text" but once again, > it is a non-normative appendix that is confusing people. > > What almost nobody has suggested is that we need more formal notation. Now > if we look at James Clark's "clarifying" document what we see is *less* > English text and *more* notation. > > As David Megginson has pointed out, when a spec. invents a notation to > explain its abstract concepts the spec. becomes temporarily harder to read > because you have to learn the notation before the specification. This will > turn people off. I remember that Algebraic notation turned me off in my > first year math classes. But in the *long run* it makes life easier for > everyone. Implementors have precise definitions of what the hell they are > supposed to implement. End-users get software they can use. People reading > the specification for their own education and edification will understand > it better -- if they perservere through the task of learning the notation. > > I know that W3C spec. writers are under pressure to use more normative > English and less normative notation. This is not a vote for "clean" > specifications. It is a vote for messy, hard-to-implement ones. Where is > Dan Connolly when you need him? > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmg at trivida.com Sun Feb 7 16:35:58 1999 From: jmg at trivida.com (Jeff Greif) Date: Mon Jun 7 17:08:46 2004 Subject: Extra Complexity? References: <003101be5222$38f5ef80$01010101@sammy> Message-ID: <36BDC065.2667EC43@trivida.com> This seems a bit too thorough a rejection of DTD's for content validation. It is helpful in writing the application validation code for the prime number to be able to expect to have a certain kind of element or attribute in a particular place that is the thing to be checked for primality, and to know that a large subset of the other prerequisites needed for this kind of check must have already been satisfied. I find the parser's validation against a DTD valuable in my application's code which is doing just this sort of thing. It saves lots of checking for various errors that cannot happen if the document is known to be valid according to the DTD. Jeff "Samuel R. Blackburn" wrote: > It depends on how you use XML. If you use it to transfer > data between applications then DTD's are completely useless. > Their assumption that the world is flat is inappropriate for > data applications. Also, the validations performed using DTD's > don't buy you anything. The application must perform its own > validation based upon some business rules. DTD's allow you > to "validate" that a field contains a number but you can't use > DTD's to "validate" that a field contains a prime number (that > is an application layer validation). > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Feb 7 16:58:19 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:46 2004 Subject: "Clean Specs" In-Reply-To: <36BDAF1D.A908F8EF@prescod.net> References: <199902070827.BAA07349@malatesta.local> Message-ID: <199902071658.LAA16110@hesketh.net> At 09:19 AM 2/7/99 -0600, Paul Prescod wrote: >What is a "clean spec?" Good question, one with many answers. >People in this discussion are mixing together a variety of things that I >do not consider the same. > >Uche Ogbuji wrote: >> I have worked on teams implementing DOM, XSL and parts of XLL. Some users >> might grant that we have been "succeeding", but let me assure you that if so, >> it is despite the W3C specs, not because of them. DOM, especially is >> unforgivably inconsistent, incomplete, and unclear for a production-ready >> (1.0) specification. > >There is not a SINGLE person on this mailing list that would say that it >is right to create specifcations that are inconsistent, incomplete or >unclear. It is beyond doubt that specifications in the XML family, >including XML itself, have these problems. The question is how to avoid >that? Glad to hear that we're actually arguing toward a common purpose. > * some people say that what the spec needs is "more English". But much of >the problem with the namespaces specification comes from ambiguity in the >English. > > * some people say that we need "more non-normative text" but once again, >it is a non-normative appendix that is confusing people. > >What almost nobody has suggested is that we need more formal notation. Now >if we look at James Clark's "clarifying" document what we see is *less* >English text and *more* notation. What we need is text that conforms to the formal notation, and lots of examples that are checked hard against both the text and the formalisms for accuracy. This is extraordinarily difficult to do right, but it results in standards that are both solid and understandable. To a considerable extent this demands that spec writers see themselves as implementors - and probably that they include implementors in the process, especially implementors who don't have prior experience in whatever standards provided the foundation of the current project. The story for XML 1.0 of using Peter Murray-Rust as a canary is a good one, though I'd like to see more of that in the actual group of people writing the specs, not just the surrounding groups. One other point: putting explanatory text and examples into 'non-normative' sections is pretty much equivalent to abandoning them, announcing that the writers didn't put the effort to ensure that they were completely conformant with the formal specification and therefore equally normative. Making the _entire_ spec normative, both the formalisms and the explanatory text, seems like a more likely approach to succeed, though again it requires (considerable) additional effort on the part of the specification writers. >As David Megginson has pointed out, when a spec. invents a notation to >explain its abstract concepts the spec. becomes temporarily harder to read >because you have to learn the notation before the specification. This will >turn people off. I remember that Algebraic notation turned me off in my >first year math classes. But in the *long run* it makes life easier for >everyone. Implementors have precise definitions of what the hell they are >supposed to implement. End-users get software they can use. People reading >the specification for their own education and edification will understand >it better -- if they perservere through the task of learning the notation. Are there good resources describing formal notations? I tend to find that the people creating formal notations do so because they're fed up with text, and then do a lousy job describing the notations. All they've done is make the learning curve a hell of a lot steeper, while creating a subculture of experts fluent in that notation who then feel empowered to use that notation to create all kinds of wonderful things that the rest of us can't figure out. I would _never_ write an XML book that started by explaining EBNF and then used that to walk through the spec; I wouldn't expect readers to stick beyond the first few paragraphs. (It has been done before, and there are readers who enjoy that, but in my limited experience they're a very small minority.) >I know that W3C spec. writers are under pressure to use more normative >English and less normative notation. This is not a vote for "clean" >specifications. It is a vote for messy, hard-to-implement ones. Where is >Dan Connolly when you need him? It requires making the effort to align the text and the formalisms. Now that we have XML as a foundation, that task may become simpler; I don't find it very difficult to describe the structures of XML documents and XML DTDs in plain English, even to those without extensive XML experience. Making XML a common formal foundation is a good way out of this mess for lots of standards - though that, of course, requires undertaking the project Paul has described above of making the foundation formalism intelligible. XML won't work as a common foundation for everything, so we'll still be stuck with the other vocabularies for a lot of projects. Spec writers will still have an obligation to write clear text. >Let me point out: the CSS and HTML specifications are easy to read because >everyone who wants to read them already understands the basic concepts of >web pages and layout. They are concrete implementations of ideas we >already understand. The same goes for Java. (and yes, I read the Java >specification, but AFTER I already knew Java) CSS was actually a huge jump for a lot of people in the HTML world; I'd say it was harder than you make it out to be. CSS2 is easy to read because it recognizes that difficulty (more than CSS1 did) and addresses it directly. I've never found the HTML specs to be of much use, though the latest drafts look much more promising. >I wonder if anyone on this list has ever learned a language that was >radically different from what they already knew through the language >specification: Scheme, Prolog, APL? Never tried radically different. I found the ECMA-262 spec for ECMAScript/JavaScript much more useful for syntax than the books I was attempting to use at the time, though that too required some effort. >Technical writing is damn hard. When you do it right, you must make >certain decisions about ordering of concepts and revelations that are the >exact opposite of what you do in writing a specification. When you write a >spec., you need to present things in the order of fundamental building >blocks to high level concepts. In technical writing you will put your >students to sleep if you zoom in on details before explaining the general >framework. It's definitely difficult. I've spent about 100 hours this week documenting assorted XML material to finish a book, and I've seen specs with varying degrees of clarity, from super-sharp to non-existent. (I've also been dealing with numerous cases where text and formalism don't match at all. That's especially fun.) I'm not convinced that technical writing needs to run backward from the way that a specification must be written, however. Starting out with building blocks and constructing grander concepts is perhaps a nice theoretical model, but I don't think I've seen too many specs that follow that construct precisely. Typically, specs at least present the big picture to give readers some idea of why they're bothering, then focus in on details, and then zoom back out. Abstracts and introductions are at least as important to writing a good spec as they are to writing a book, as are glossaries. >Life is hard for implementors. I'd rather >be forced to implement the entire suite of XML specifcations over HTML/CSS >2. That isn't a slight against HTML/CSS, it's just an attempt to put >things in perspective. Actually, once they get through the HTML-in-XML stuff, I think implementing HTML/CSS2 would be a heck of a lot easier than implementing XML/XLink/XPointer/XSL/fragments/XQL/etc. That's your choice, of course. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 srn at techno.com Sun Feb 7 17:09:46 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:08:46 2004 Subject: DTD: Extra Complexity? In-Reply-To: <000001be521b$991c0ea0$0400a8c0@dan.perrysfield> References: <000001be521b$991c0ea0$0400a8c0@dan.perrysfield> Message-ID: <199902071708.LAA01289@bruno.techno.com> [Dan Holle:] > Many applications I've seen, and a few that I have created, don't > validate the XML against a DTD. > Is the DTD an extra step, inherited from SGML, that doesn't really > fit XML? True, there is often no necessity for an application to validate incoming data against a DTD. BUT: DTDs are essential in marketplaces in which open information interchange occurs in a multivendor environment. In this kind of situation, DTDs serve as contracts between information-creating application developers and information-consuming application developers. When information fails to be interchanged successfully (i.e., when things don't work), and if there's no DTD contract, then there's no way to tell who's responsible to make what changes in order to restore successful open information interchange. Software maintenance costs spiral upward, customers get confused and unhappy, and the atmosphere in the marketplace is poisoned. With a DTD contract in place, the reliability of open information interchange is much higher, and the entry cost to software vendors of serving any given marketplace is much more predictable. Now about the necessity of applications performing validation. You're right, it's not strictly necessary. BUT: * Vendors of information-consuming software often wish to incorporate validation of incoming information into their applications in order to deflect blame away from themselves when things don't work right and it's not their fault. It is impossible to create software that understands just any old gobbledygook that happens to come along. * Similarly, vendors of information-creating software often wish to incorporate validation of outgoing information into their applications in order to demonstrate that, if some information-consuming application chokes on it, it is the fault of the information-consuming application and not the fault of the information-creating application. It is impossible to create information that can be understood by just any old information-processing application. So, back to your question: "Is the DTD an extra step, inherited from SGML, that doesn't really fit XML?" The answer is that DTDs are an essential, non-optional feature of XML whenever XML is used in a marketplace of open information interchange that is served by multiple software vendors. Given that XML is supposed to be used on the Web, DTDs are certainly essential to XML's widespread success in enhancing opportunities for open information interchange in a multivendor context. On the other hand, open DTDs are not good news for the ultra-dominant software vendors. Efforts to create industry-standard DTDs are the strategic Manhattan Projects of the ongoing struggle between information owners and software vendors for control of huge libraries of valuable commercial information. Eventually, the information owners are going to win, leaving them in a position to buy their software from the lowest bidder. The Silicon Integration Initiative's ECIX project [www.si2.org] springs to mind as an example. -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 jtauber at jtauber.com Sun Feb 7 17:26:15 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:08:46 2004 Subject: document vs non-document entity (was Re: CORBA's not boring yet. / XML in an OS?) Message-ID: <002101be52be$e92480a0$0300000a@othniel.cygnus.uwa.edu.au> Paul Prescod: >This is a serious problem inherited from SGML. It is my opinion that >instead of namespace declarations being done through attributes they >should have been just another form of PI-based declaration. Then in >version 2.0 of XML, all declarations should have been made "localizable." >In particular, there should be a way to declare internal text entities, >unparsed entities and attribute defaults locally. Well this is actually where my thinking has been going. I've been thinking about whether localizable declarations might be achievable using an *attribute* mechanism following on from how namespaces ended up. Eg <Root> ... <SomeElement xmldecl="local-decl.pen"> <!-- markup declarations in local-decl.pen apply --> </SomeElement> ... </Root> The xmldecl attribute takes the value of the URI of an external parameter entity. To avoid name clashes, it might be an idea to have xmldecl:foo="local-decl.pen" and then qualify entities with the prefix foo (ie &foo:SomeEntity;) James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Associate Researcher, Electronic Commerce Network Curtin University of Technology, Perth, Western Australia xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 7 17:37:01 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:46 2004 Subject: XSL and namespaces Message-ID: <36BDCC48.741BC90C@prescod.net> Someone pointed out that XSL does in fact work on the URI-replaced namespace, not the prefixed name. I missed this because I was looking for more sophisticated features. I'm not sure yet if the support provided is "sufficient." It seems like we should have a mechanism for dynamically assembling stylesheets BASED ON the namespaces used in a document. But maybe that's not necessary. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 7 17:38:28 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:46 2004 Subject: DTD: Extra Complexity? References: <000001be521b$991c0ea0$0400a8c0@dan.perrysfield> <199902071708.LAA01289@bruno.techno.com> Message-ID: <36BDCD80.180338D8@prescod.net> "Steven R. Newcomb" wrote: > > Given that XML is supposed to be used on the Web, DTDs are certainly > essential to XML's widespread success in enhancing opportunities for > open information interchange in a multivendor context. > > On the other hand, open DTDs are not good news for the ultra-dominant > software vendors. I noticed something ominous in one of the Office 2000 products. It was generating a schema on the fly for the data it was sending. "We know this data conforms to this standard because we invented the standard to fit the data." If the person on the other end can't see the schema *in advance* then they can't code software that works with the data. That's pretty much as bad as not having a schema at all. I don't want to say that generating a schema on the fly is ALWAYS bad. The point should be that you should specify as much as you can in a static schema, (or other formal specification). "Inline extensions" should be a last resort and should be explicitly catered for in the static schema. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sun Feb 7 19:06:13 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" Message-ID: <3.0.32.19990207110448.00c1d440@pop.intergate.bc.ca> At 12:01 PM 2/7/99 -0500, Simon St.Laurent wrote: >To a considerable extent this demands that spec writers see themselves as >implementors - and probably that they include implementors in the process, >especially implementors who don't have prior experience in whatever >standards provided the foundation of the current project. The story for >XML 1.0 of using Peter Murray-Rust as a canary is a good one, though I'd >like to see more of that in the actual group of people writing the specs, >not just the surrounding groups. There's an interesting lesson lurking in there. The original XML WG included implementors of Author/Editor, HoTMetaL, groff, SP, Jade, Pat/Lector, IBMIDDOC, Dynatext, Mosaic, and Grif. So Simon's (implied) theory that the specs would have been better, had the authoring group included implementors, stands on shaky ground. A couple of hypotheses that might explain this: - being an implementor is not a particularly strong qualification for writing specs - being a core-technology implementor, rather than a solution builder or system integrator, is not a particularly strong qualification for writing specs This group is notably and vocally dissatisfied with the specs, I am watching with attention for concrete suggestions as to how to make future specs better - the one premise that seems to get consensus, in this group at least, is "more examples". (Hmm, the namespace spec has tons). As regards the namespace spec, another hypothesis: - it might be easier to understand for people coming in from outside who aren't carrying around a bunch of SGML-derived expectations. And given that XML actually seems to be succeeding quite vigorously in the marketplace, a final hypothesis: - there is little relation between the presentation quality of a spec, in and of itself, and whether the world will welcome it (presumably we *do* believe that the quality of the design being spec'd does have some such relationship) My own personal take - the XML spec has holes that I'm more deeply aware of than anyone in the world, but it's a bearable compromise given the combined resource/time/political constraints - and the real-world problems with XML are not the spec itself, but SGML-derived bogosities like parameter entities. And as regards the namespace spec, I think that some people on this list are substantially full of shit, and are wilfully refusing to see how simple it is because it does not meet their own design prejudices. I think that spec is *way* better than the XML spec. Having said all that, people who write specs always have to try to do a better job next time, so this recent discourse is very very useful. -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 simonstl at simonstl.com Sun Feb 7 19:23:16 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" In-Reply-To: <3.0.32.19990207110448.00c1d440@pop.intergate.bc.ca> Message-ID: <199902071922.OAA17850@hesketh.net> At 11:05 AM 2/7/99 -0800, you wrote: >At 12:01 PM 2/7/99 -0500, Simon St.Laurent wrote: >>To a considerable extent this demands that spec writers see themselves as >>implementors - and probably that they include implementors in the process, >>especially implementors who don't have prior experience in whatever >>standards provided the foundation of the current project. The story for >>XML 1.0 of using Peter Murray-Rust as a canary is a good one, though I'd >>like to see more of that in the actual group of people writing the specs, >>not just the surrounding groups. > >There's an interesting lesson lurking in there. The original XML WG >included implementors of Author/Editor, HoTMetaL, groff, SP, Jade, >Pat/Lector, IBMIDDOC, Dynatext, Mosaic, and Grif. So Simon's (implied) >theory that the specs would have been better, had the authoring group >included implementors, stands on shaky ground. A couple of hypotheses >that might explain this: I think you missed a key point I made in the above paragraph - that the inclusion of implementors _without_ prior experience in the material being worked on is important. I'd argue quite heartily that the many years of implementation experience the WG brought to the table put them at a _disadvantage_ in writing specs that might be read by an audience without that level of prior experience: the non-SGML audience XML was supposedly to reach. >the one premise that seems to get >consensus, in this group at least, is "more examples". (Hmm, the >namespace spec has tons). Make them normative, document them heavily, and build on them in layers (step 1, then step 2 - same example, growing more complex), and you'll hear loud cheers from this corner. >- [namespaces] might be easier to understand for people coming > in from outside who aren't carrying around a bunch of SGML-derived > expectations. I wish, but I think a lot of people are getting stuck figuring out what XML's SGML-derived expectations are and then piling namespaces on top of it. >And as regards the namespace spec, I think that some people on this >list are substantially full of shit, and are wilfully refusing to see >how simple it is because it does not meet their own design prejudices. >I think that spec is *way* better than the XML spec. I don't think that's going to get you a lot of positive feedback from anyone, on this spec or future specs. Namespaces better than XML 1.0? Maybe if it didn't have to layer on top of XML 1.0. I'm looking forward to a future revision of XML where this can get cleanly integrated, and maybe that'll be the one worth judging. Simon St.Laurent XML: A Primer / Building XML Applications (March) 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 eliot at dns.isogen.com Sun Feb 7 19:32:54 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" In-Reply-To: <3.0.32.19990207110448.00c1d440@pop.intergate.bc.ca> Message-ID: <3.0.5.32.19990207133327.00a67790@amati.techno.com> At 11:05 AM 2/7/99 -0800, Tim Bray wrote: >My own personal take - the XML spec has holes that I'm more deeply >aware of than anyone in the world, but it's a bearable compromise >given the combined resource/time/political constraints - and the >real-world problems with XML are not the spec itself, but SGML-derived >bogosities like parameter entities. I'm with Tim here: writing specs, and in particular, standards is difficult at best. And, like anything, it is a human activity, which means it will be flawed, by definition. The editors had a very hard job and did, IMNSHO, an excellent job within the constraints they had. And XML does suffer from things in SGML that are objectively not well designed (entities in SGML are just a mess generally). The XML spec had a particularly tough row to hoe: it had to be both as rigorous as possible and as easy-to-use as possible. These two things are generally not compatible, especially for a general audience. As Paul P. points out, if you don't already understand the formal notation of the spec, understanding the spec completely and unambiguously is hard. That the editors got close is a testament to their skill and tenacity. Compare, for example, the DSSSL spec, which is, in my opinion, one of the better technical standards I've worked with. James Clark relied heavily on formal notation and limited the prose, especially non-normative prose. This makes the DSSSL spec hard to learn DSSSL from initially (you've got to learn two new syntaxes: the formal production syntax and the expression language syntax), but once you learn them, there is little ambiguity. Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sun Feb 7 20:44:20 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" Message-ID: <3.0.32.19990207124243.00ba7eb0@pop.intergate.bc.ca> At 02:25 PM 2/7/99 -0500, Simon St.Laurent wrote: >I think you missed a key point I made in the above paragraph - that the >inclusion of implementors _without_ prior experience in the material being >worked on is important. Actually, here's another piece of evidence that supports your position. Recently, in an effort to refresh my memory as to why something in XML 1.0 was the way it was, I went back and reviewed a whole bunch of the XML SIG mailing list correspondence from back in '97 while the important issues were being thrashed out. Things such as white-space handling and public identifiers and so on were being debated passionately by people who were obviously deeply erudite as to the pros and cons of the issues; in the thousands and thousands of emails, though, there is almost no input as to the structure and presentation of the XML spec - everyone was too focused on the content. I think there's *definitely* a lesson there. -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 jamesr at steptwo.com.au Sun Feb 7 22:18:37 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" In-Reply-To: <36BDAF1D.A908F8EF@prescod.net> References: <199902070827.BAA07349@malatesta.local> Message-ID: <4.1.19990208091225.00bbbca0@steptwo.com.au> At 01:19 8/02/1999 , Paul Prescod wrote: | What is a "clean spec?" | | People in this discussion are mixing together a variety of things that I | do not consider the same. | | Uche Ogbuji wrote: | > I have worked on teams implementing DOM, XSL and parts of XLL. Some users | > might grant that we have been "succeeding", but let me assure you that if so, | > it is despite the W3C specs, not because of them. DOM, especially is | > unforgivably inconsistent, incomplete, and unclear for a production-ready | > (1.0) specification. | | There is not a SINGLE person on this mailing list that would say that it | is right to create specifcations that are inconsistent, incomplete or | unclear. It is beyond doubt that specifications in the XML family, | including XML itself, have these problems. The question is how to avoid | that? Well, has anyone considered employing real, professional technical authors to write the specifications? Instead of (I presume) the progenitors of the ideas. I mean, the inventors of a standard are gurus in their technical area, but rarely would they have professional skills in communication and education ... So I say we ask some real experts ... in writing. Cheers, J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Sun Feb 7 22:23:20 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:47 2004 Subject: RDF (was Re: Colonialism, SAX, Java, and Namespaces) In-Reply-To: <36BDB47A.35407949@prescod.net> References: <36BB0D56.EDF427B0@prescod.net> <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> <4.1.19990207105247.00c75ca0@steptwo.com.au> Message-ID: <4.1.19990208091613.00b80100@steptwo.com.au> At 01:42 8/02/1999 , Paul Prescod wrote: | James Robertson wrote: | > | > | > Now since the intention is to store a lot of data in | > RDF, how do we check that a RDF file is correct | > and meaningful? | > | > How do we validate it? | | There is such a thing as an "RDF schema". It checks an almost disjoint set | of things from what a DTD would check. If you don't care about things | being in a particular order and want to treat linking and containment as | the same thing, then you should use RDF schemas. If you do care about the | order of things, you should use DTDs. You could also use them together to | check different things. Maybe I just haven't woken up enough this morning yet, but I'm not quite sure what all of this means. So I'll restate the question: * I write an RDF document by hand. * I receive an RDF document from someone else. How do I know it makes sense? How do I know the right RDF tags have been used, and in a meaningful way? In otherwords, since an RDF document doesn't have a DTD (since it uses namespaces), how do I check it's right? J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Sun Feb 7 22:34:49 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" In-Reply-To: <3.0.32.19990207124243.00ba7eb0@pop.intergate.bc.ca> Message-ID: <4.1.19990208092325.00c4bc30@steptwo.com.au> At 06:43 8/02/1999 , Tim Bray wrote: | Actually, here's another piece of evidence that supports your position. | Recently, in an effort to refresh my memory as to why something in XML 1.0 | was the way it was, I went back and reviewed a whole bunch of the | XML SIG mailing list correspondence from back in '97 while the important | issues were being thrashed out. Things such as white-space handling | and public identifiers and so on were being debated passionately by | people who were obviously deeply erudite as to the pros and cons of the | issues; in the thousands and thousands of emails, though, there is | almost no input as to the structure and presentation of the XML spec - | everyone was too focused on the content. I think there's *definitely* | a lesson there. -Tim I think I'll make my point more strongly here, as I think Tim highlights this issue in his post. As a whole, we can be considered the "professionals" or "specialists" in the areas of XML, etc. However, there is a whole, much larger, group of professional people who are the experts in: writing stuff that makes sense. They are called technical authors. The XML WG wouldn't think of seriously discussing say, OS filesystem design. I would ask why they think they have the skills and qualifications to write a large and complex technical document, so that it makes sense? The specification document is read by the whole world, and is essentially the only medium that the WG uses to communicate its ideas widely. So it's a document worth doing properly, not something that should be written by technical specialists and amateur authors. Now, this point of view is very new to me as well, and it's come about due to having worked for the last year with a group of technical authors. And they really do know their stuff ... So from now on, I'm going to stick to designing and coding, and consult the experts when I need to write serious documentation. Just some thoughts for the day, J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From liamquin at interlog.com Sun Feb 7 23:19:06 1999 From: liamquin at interlog.com (Liam R. E. Quin) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" In-Reply-To: <3.0.32.19990207110448.00c1d440@pop.intergate.bc.ca> Message-ID: <Pine.BSI.3.96r.990207180946.29147B-100000@shell1.interlog.com> Quoth Tim Bray <tbray@textuality.com> [...] > This group is notably and vocally dissatisfied with the specs, I > am watching with attention for concrete suggestions as to how > to make future specs better - the one premise that seems to get > consensus, in this group at least, is "more examples". (Hmm, the > namespace spec has tons). Having just had a book on the XML spec published... I will say that the spec is one of the better thta I have seen, but that there is still a lot of scope for improvement. It was a really difficult process, and it's easy to forget that at the start, few who were involved in it expected it to generate the interest and fervour that it has. There was no expectation that any aspect of SGML would be changed, either, although in the end SGML *was* changed. But there is a problem with expectations, too. The spec is not an introduction. How many people here learnt C++ by reading the ANSI spec? How many people here learned to tune a radio by reading the international specifications for radio frequency allocation? Next time, develop tutorials alongside the specs perhaps. > My own personal take - the XML spec has holes that I'm more deeply > aware of than anyone in the world, but it's a bearable compromise > given the combined resource/time/political constraints - and the > real-world problems with XML are not the spec itself, but SGML-derived > bogosities like parameter entities. I agree 100%. Ian and I found lots of minor holes last year (asked about some here, sent some to the email address for corrections to the spec), but they are almost all minor. There are a couple of places where the wording says the opposite of what's intended, but where no sane person is likely to read it literally, and that's OK too. The namespace spec was pretty good last time i looked. I think it raises whole big looming purple-and-green questions which I shall try to write about separatesomely. Lee -- Liam Quin, GroveWare Inc., Toronto; The barefoot programmer l i a m q u i n at i n t e r l o g dot c o m http://www.interlog.com/~liamquin/ SGML/XML/Unix/C consulting and programming xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Feb 7 23:33:40 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" In-Reply-To: <4.1.19990208092325.00c4bc30@steptwo.com.au> References: <3.0.32.19990207124243.00ba7eb0@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990207183427.00bdd698@pop.uunet.ca> James' has reiterated a suggestion that has been put forward by others in the past -- notably Dan Connolly and Tim Berners-Lee. Sadly, professional writers are not always easy to come by, and when they are they usually expect compensation -- gotta make a living, dontcha know. A professional technical writer was hired by W3C for the HTML 4.0 specification. The XML WG did have at least one professional writer and one professional editor on board, and many of those who were not professional writers/editors could not fairly be categorized as amateurs given their academic and professional histories. In my experience as a technical writer, I have discovered that the act of explaining the application of a technical design can, in many cases, lay bare its flaws. Cooperation between writers and designers often results in designs that take the end-user into account. Regards, Murray xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sun Feb 7 23:40:13 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" In-Reply-To: <4.1.19990208092325.00c4bc30@steptwo.com.au> References: <3.0.32.19990207124243.00ba7eb0@pop.intergate.bc.ca> Message-ID: <3.0.5.32.19990207174048.007c69c0@amati.techno.com> At 09:31 AM 2/8/99 +1000, James Robertson wrote: >The XML WG wouldn't think of seriously discussing say, OS filesystem >design. I would ask why they think they have the >skills and qualifications to write a large and complex technical >document, so that it makes sense? > >The specification document is read by the whole world, and is essentially >the only medium that the WG uses to communicate its ideas >widely. So it's a document worth doing properly, not something that >should be written by technical specialists and amateur authors. The XML WG was an all-volunteer project, as are most standards efforts. Those of us who participated did so primarily as a personal commitment, not as something our employers (those of us who have them) pay us to do. Standards development is not a commercial process--there is no budget from which technical writers might be hired. The W3C only administers, it does not fund. Same for ISO. Some national bodies do fund some standards development (BSI, the British Standards Institute), but that funding will tend to be used to support the technologists developing the standard and not writers crafting the words. So while it's true that most, if not all, specifications could benefit from professional writers, it usually isn't an option for standards developers. About the most you can hope for is editors who are literate and capable. In the case of Tim and Michael, I think we got about as much literateness and capability as we could want. Note too that writing good standards is a very specialized art--it's very close to writing legal documents. Not all technical writers are skilled at it, even if they are good at other forms of technical writing. Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at dns.isogen.com Sun Feb 7 23:45:25 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" In-Reply-To: <3.0.1.32.19990207183427.00bdd698@pop.uunet.ca> References: <4.1.19990208092325.00c4bc30@steptwo.com.au> <3.0.32.19990207124243.00ba7eb0@pop.intergate.bc.ca> Message-ID: <3.0.5.32.19990207174651.00a8b680@amati.techno.com> At 06:34 PM 2/7/99 -0500, Murray Maloney wrote: > A professional technical writer was hired >by W3C for the HTML 4.0 specification. Didn't know that--puts the lie to what I just posted.... >The XML WG did have at least one professional writer and one >professional editor on board, and many of those who were not >professional writers/editors could not fairly be categorized >as amateurs given their academic and professional histories. > >In my experience as a technical writer, I have discovered that >the act of explaining the application of a technical design >can, in many cases, lay bare its flaws. Cooperation between >writers and designers often results in designs that take the >end-user into account. I agree--in writing my (as yet unfinished) book on HyTime (www.drmacro.com/bookrev) I uncovered numerous problems with the original standard, which helped tremendously during the writing of the 2nd edition of the standard. While reference implementations are always good, "reference tutorials" are at least as valuable. It would be nice if we always had enough resources and/or time to write the spec and the tutorial in parallel. Of course, often the person writing the spec is also the one to write the tutorial and there's only so many hours in a day.... Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Feb 7 23:47:49 1999 From: marcelo at mds.rmit.edu.au (Marcelo Cantos) Date: Mon Jun 7 17:08:47 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <no.id>; from Paul Prescod on Thu, Feb 04, 1999 at 11:14:32PM -0600 Message-ID: <19990208104624.A4862@io.mds.rmit.edu.au> On Thu, Feb 04, 1999 at 11:14:32PM -0600, Paul Prescod wrote: > "Borden, Jonathan" wrote: > > ...[lots and lots] ... and then ... So lets compare apples to > > apples. Which data access API do you wish to use? > > I don't want an API. I want layers of objects. At the bottom level I > have either storage objects or records in a table. At the higher > layers I have abstractions over those objects. Using objects I can > build a 1-tier, 2-tier, 3-tier or n-tier system. I can have as many > levels of business rules and clients and servers as I need. I can > also query objects and build object schemas using standardized, > multiply-implemented languages. I'm not clear on what you mean here, Paul. When one builds a multi-tier solution in the relational world, the lowest layer is always collections of tuples, usually SQL. Raw, an "dumb". To leverage this "stupid" layer, one will usually build a business layer above this, which may implement objects. This way you have the best of both worlds. You get a nice object oriented layer on top to talk to, and an industrial strength, robust repository underneath. Your comments give me the impression that this is unacceptable to you in the XML/heirarchical universe. You don't want DOM at any level. You insist on going straight to objects. It is not even good enough to build an object layer on top of the DOM layer. I find this a little implausible and hence am certain that you had something else in mind. Is it rather that you simply don't care what the underlying API is, that you are only interested in what happens at the object level? 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 donpark at quake.net Mon Feb 8 00:02:30 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" Message-ID: <005a01be52f6$218ace90$2ee044c6@arcot-main> Tim Bray wrote: >And as regards the namespace spec, I think that some people on this >list are substantially full of shit, and are wilfully refusing to see >how simple it is because it does not meet their own design prejudices. >I think that spec is *way* better than the XML spec. Tim, I am disappointed that you chose to follow this line of thinking. I happened to like the XML spec and found the Namespaces spec confusing. Is this because I am substantially full of shit? Maybe so. Even ignoring your seemingly habitual verbal abuse, I find it disconcerning that you seem to treat genuine feedback from the readers of your specs as some sort of legal arguments or logic problems which you are obligated to punch holes in. Please listen to what we are trying to say rather than how we say it. If some of us seems to criticize your works harshly, it is because we would like to believe that we are not entirely stupid. If we do not understand you fully, should we think that we are too stupid to understand or that your are speaking too high above our heads? Most of the people who took part in this thread of discussion took the middle view: we took as much as blame as possible until we were full of it and then shovel to you the rest. Are we full of it? You are damn right we are. I am pissed because I am full of it. If you are having trouble holding your share, that is too bad. Not really at my 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 bckman at ix.netcom.com Mon Feb 8 00:32:59 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" Message-ID: <003701be52fa$6efe1700$82acdccf@ix.netcom.com> Murray wrote <<In my experience as a technical writer, I have discovered that the act of explaining the application of a technical design can, in many cases, lay bare its flaws. >> I agree with this. The writer of the spec. presumably knows what they want to say, but often don't say it, and it's only in the process of explaining the spec that the flaw is laid bare. For example when I tried to explain this I realised that it was in fact meaningless. <<Non-standard extensions, when used, may change the behavior of functions or facilities defined by this recommendation. In such cases, the implementation documentation must define an environment in which a document can be parsed and rendered with the behavior specified by this recommendation.>> Cooperation between >writers and designers often results in designs that take the >end-user into account. And that surely is the whole idea! Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (March) ----- Original Message ----- From: Murray Maloney <murray@muzmo.com> To: XML-Dev Mailing list <xml-dev@ic.ac.uk> Sent: Sunday, February 07, 1999 6:34 PM Subject: Re: "Clean Specs" >James' has reiterated a suggestion that has been put forward >by others in the past -- notably Dan Connolly and Tim Berners-Lee. >Sadly, professional writers are not always easy to come by, and >when they are they usually expect compensation -- gotta make a >living, dontcha know. A professional technical writer was hired >by W3C for the HTML 4.0 specification. > >The XML WG did have at least one professional writer and one >professional editor on board, and many of those who were not >professional writers/editors could not fairly be categorized >as amateurs given their academic and professional histories. > >In my experience as a technical writer, I have discovered that >the act of explaining the application of a technical design >can, in many cases, lay bare its flaws. Cooperation between >writers and designers often results in designs that take the >end-user into account. > >Regards, > >Murray > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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 paul at prescod.net Mon Feb 8 00:53:45 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:47 2004 Subject: RDF (was Re: Colonialism, SAX, Java, and Namespaces) References: <36BB0D56.EDF427B0@prescod.net> <8025670F.002EF9AD.00@mailhost.agora.co.uk> <199902051513.KAA01453@hesketh.net> <4.1.19990207105247.00c75ca0@steptwo.com.au> <4.1.19990208091613.00b80100@steptwo.com.au> Message-ID: <370BEC9C.2E4DF38B@prescod.net> James Robertson wrote: > > So I'll restate the question: > > * I write an RDF document by hand. > * I receive an RDF document from someone else. > > How do I know it makes sense? How do I know the right > RDF tags have been used, and in a meaningful way? > > In otherwords, since an RDF document doesn't have a DTD > (since it uses namespaces), how do I check it's right? Well you are wrong that an RDF document can't have a DTD. It can. But then you are checking the XML-validity of the document, not the RDF-validity. If the question is how to check an arbitrary RDF that using a particular RDF-described "vocabulary" in the same way that you can check HTML using the HTML DTD, you check the RDF document against its RDF schema. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 8 01:13:57 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:47 2004 Subject: "Clean Specs" Message-ID: <3.0.32.19990207171050.00c2c870@pop.intergate.bc.ca> At 04:01 PM 2/7/99 -0800, Don Park wrote: >I am disappointed that you chose to follow this line of thinking. ... >Not really at my best, Yeah, I wasn't either yesterday. Apologies to everyone here for being nasty. Everyone in the XML activity takes the opinions expressed here very seriously. I gotta say, though, the XML spec now feels to me like a ramshackle compromise that only just barely works, while namespaces do one simple thing and nail it down tight as a drum. Here's how bad it is; I'm working on an Annotated namespaces, just like annotated XML - and I'm having serious difficulty figuring out what to write. -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 jborden at mediaone.net Mon Feb 8 01:13:58 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:47 2004 Subject: XML e-mail viewer was RE: CORBA's not boring yet. / XML in an OS? In-Reply-To: <0d2701be5270$824dbca0$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <000401be52ff$a4cc8ec0$d3228018@jabr.ne.mediaone.net> Thanks to everyone who has sent e-mail to test-xmtp@jabr.ne.mediaone.net ... in response to many requests to provide the "viewer" for this e-mail including in-line images I have put up another demo application which I call the XMTP-Board. To use it, send an e-mail including attached jpeg/gif images to: mailto:xmtp-board@jabr.ne.mediaone.net To view the e-mail using IE5b2 and XSL, browse to: http://jabr.ne.mediaone.net/xmtp/listxmtp.asp?User=xmtp-board I haven't yet had time to test my XSL with XT or LotusXSL and given the current state of XSL incarnations, I expect that this will only work with IE5 ... the intention of course is to conform to legal XSL as this becomes defined. This is the system as described in http://www.xml.com/xml/pub/98/12/consult98a.html Jonathan Borden http://jabr.ne.mediaone.net > > There would be an application, for example, that got mail via POP or IMAP, > represented it in XML and then attached it a particular point in the > uberdocument. XSL could be used to sort the mail. XSL would also > be used to > view the mail. > > It's XML for the sake of it, but I think it would be fun to try out. > > 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 murray at muzmo.com Mon Feb 8 01:44:15 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:08:48 2004 Subject: "Clean Specs" In-Reply-To: <3.0.32.19990207171050.00c2c870@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990207204449.00a4cb9c@pop.uunet.ca> At 08:13 PM 2/7/99 -0500, Tim Bray wrote: >I gotta say, though, the XML spec now feels to me like a ramshackle >compromise that only just barely works, while namespaces do one simple >thing and nail it down tight as a drum. Here's how bad it is; I'm >working on an Annotated namespaces, just like annotated XML - and I'm >having serious difficulty figuring out what to write. -Tim Tim, I trust that the namespace spec makes perfect sense to you. But it does not make sense to me and many others. Take a step back and look/listen again. I sense that you are so close to it that you just don't see the monstrous chasms that others do. Either that "tight drum" is dischordant, or the rest of us are marching to a different one. Either way, it has not been successful in getting us in lock step. >From my point of view, namespaces is a "ramshackle compromise". I give you credit for appreciating that many/most of us aren't stupid. So take a clue from the reported 3:1 anti- vs pro-namespace email ratio. I am telling you, as a friend, colleague and a technical writer, that I cannot satisfactorily explain "Namespaces in XML". If you're having trouble deciding what to write in your annotated namespace spec, you might start with answers to the questions that have been posed on this list. 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 Email: murray@yuri.org 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 jborden at mediaone.net Mon Feb 8 02:03:27 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:48 2004 Subject: "Clean Specs" In-Reply-To: <3.0.1.32.19990207204449.00a4cb9c@pop.uunet.ca> Message-ID: <000901be5306$838bd0c0$d3228018@jabr.ne.mediaone.net> Murray Maloney wrote: > > Tim, I trust that the namespace spec makes perfect sense to you. > But it does not make sense to me and many others. Take a step > back and look/listen again. I sense that you are so close to it > that you just don't see the monstrous chasms that others do. ...> > From my point of view, namespaces is a "ramshackle compromise". > I give you credit for appreciating that many/most of us aren't stupid. > Is the problem here the content of the namespace spec or the way it is written? It seems to me that people who feel that the spec is a compromise, or wish the spec specified something different, are unhappy. If you really don't understand the spec, how can you claim it is a ramshackle compromise? I suspect that you understand it and don't like it. The problem doesn't appear to be the way the spec is written and a professional writer won't solve that problem. 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 uche.ogbuji at fourthought.com Mon Feb 8 02:19:52 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:08:48 2004 Subject: "Clean Specs" In-Reply-To: Your message of "Sun, 07 Feb 1999 11:05:50 PST." <3.0.32.19990207110448.00c1d440@pop.intergate.bc.ca> Message-ID: <199902080222.TAA01694@malatesta.local> > This group is notably and vocally dissatisfied with the specs, I > am watching with attention for concrete suggestions as to how > to make future specs better - the one premise that seems to get > consensus, in this group at least, is "more examples". (Hmm, the > namespace spec has tons). Your polite chastisement is quite warranted: many of us have been complaining about the specs without offering "concrete" suggestions for improvement. I had this in mind when I posted my part, but, you see, the problems do not lie in any particular pattern. Difficulties I have come across in trying to understand the specs have been quite varied. Sometimes it appears the specs rely on several assumptions that might have been well discussed within the WG, but never made it to "paper". The DOM spec often reads that way. At other times, given examples and "clarifying" appendices have instead caused confusion, as in the Namespaces spec. In yet other cases, there appear to be several distinct functions conflated into one spec, for instance, the XSL spec, which is subject of a long, current thread in the XSL list where a large majority favor splitting it into two specs: one concerning transformation and one formatting specs. In the general case, there are many frictions between the various specs: they tend to overlap in some areas, sometimes in conflicting ways, and they tend to leave gaps in other areas. Now some of this might be inveterate whining on the part of non WG members, but I am comforted in seeing that many other intelligent readers have run into the same walls as I have. Certainly, the WG had excellent reasons for making certain choices that were bound to be unpopular. The main problem appears to be lack of communication between the WGs and outsiders. The W3C is certainly not the most inscrutable standards organization I've seen, but considering its influence over the Internet, supposedly a medium characterized by open and loud communication, it can often appear to be some shadowy group dominated by a clutch of large vendors handing down inevitably imperfect specs to outsiders, but not giving the outsiders much say in the improvement of the documents. Yes, I know that the whole "release early/release often" model of the W3C's putting up a series of drafts before the final recommendation is designed to incorporate outside input, and I'm sure feed-back from places such as this group is considered, but there is precious little communication from the W3C, IMHO, as to why some feed-back, regardless of consensus, does not appear to reflect on subsequent documents. To give an example of an even more complex, long-running, and politically charged standards effort, I'll recall the development of the ANSI C++ standard. I followed the standard very closely until I got disenchanted with the language, and with all the problems with that effort, one thing was clear: the public was _very_ involved, and there were very visible effects of this involvement. Tim Bray and James Clark have been admirable ambassadors from the W3C for the WGs with which they are involved, but I haven't felt the same give-and-take from many other members. Most ANSI committe members for the C++ standard, people such as P.J. Plauger, Tom Plum, Dan Saks, and Stroustroup himself, were very highly and visibly involved with C++ developers. Many ideas from outsiders were incorporated throughout the process, and not just from big-nickel companies: if I remember rightly, auto_ptr came from a bright individual. Before the draft was solidified, there was a long period for public comment, and there was much discussion of the comments that were received. I may be biased, but I haven't felt the same level of openness from the W3C, and it seems to me that many of the peopblems that people complain of in the specs have been pointed out many times, and still re-appear in subsequent editions of specs without any visible consideration of the complaints. The W3C often gets press to the effect that it's a small clique massed around the persoanlity of Tim Berners-Lee. I highly doubt that extremity, from what I've observed of people like Tim Bray and James Clark, but I'm not sure the W3C is doing as much as it reasonably can to dispel the (literal) FUD that surrounds many of its efforts. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 8 02:30:33 1999 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:08:48 2004 Subject: "Clean Specs" Message-ID: <001301be530a$d52c4820$2ee044c6@arcot-main> >Yeah, I wasn't either yesterday. Apologies to everyone here for being >nasty. Everyone in the XML activity takes the opinions expressed here >very seriously. Thank you very much for taking my comments positively. I felt bad after writing it. So much for the power of e-mail. I would like to apologize for the flipant tone of my comments. >I gotta say, though, the XML spec now feels to me like a ramshackle >compromise that only just barely works, while namespaces do one simple >thing and nail it down tight as a drum. Here's how bad it is; I'm >working on an Annotated namespaces, just like annotated XML - and I'm >having serious difficulty figuring out what to write. -Tim I do realize that the XML spec is leaky in certain respect but I felt it is very clear as a whole although I am unable to point out exactly what makes it so. Perhaps it was the difference in the the nature of the problems. The namespace problem is indeed very complex as you pointed out before. There are many solutions I can think of but I can't think of a single solution that addresses all the issues without looking awkward in some respect. I look forward to your Annotated Namespaces. Sitting awkwardly, 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 uche.ogbuji at fourthought.com Mon Feb 8 02:36:12 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:08:48 2004 Subject: "Clean Specs" In-Reply-To: Your message of "Sun, 07 Feb 1999 18:23:03 EST." <Pine.BSI.3.96r.990207180946.29147B-100000@shell1.interlog.com> Message-ID: <199902080238.TAA01731@malatesta.local> > The spec is not an introduction. How many people here learnt C++ > by reading the ANSI spec? How many people here learned to tune a > radio by reading the international specifications for radio > frequency allocation? I keep reading these challenges, first aboout Java, and now about C++. Well, just as I first learned Java from Sun's specs, I also happened to have mostly learned C++ from Stroustroup's Annotated Reference Manual, which is as close as C++ had to a spec for quite a while. Now true enough, as Paul Prescod points out, it is quite another matter to learn a completely foreign language from a spec: I was already very familiar with C, Smalltalk and somewhat familiar with Objective-C before tackling C++, and I was very conversant with C++ before tackling Java, but I don't think it's at all freakish to learn a language or system from a well-written spec. I happen to like formalisms, and although it probably takes me much longer to learn a new system as the seven days of the "dummies" books, I am happier in my masochism. Here's an example: I've just spent a good part of today and yesterday wading through the spec for the CORBA object transaction service for implementation in a project (we're using an ORB that doesn't support OTS). My brain might be about to explode, but I think I can get some useful work done now. I'm sure I could have found an intro from Orfali and Harkey somewhere with cute cartoons of aliens explaining the protocol for a two-phase commit, but I'm usually doubtful about what I really know after such tutorials. So in short: there is nothing wrong about trying to learn from a well-written spec. My problem with some W3C specs is not complexity (in fact, they are probably the most straightforward specs I've read). It's more typically, as I've said before, inconsistency, incompleteness, and unclearness (in the sense of "ambiguity" rather than "abstruseness"). -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From uche.ogbuji at fourthought.com Mon Feb 8 02:45:22 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:08:48 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: Your message of "Mon, 08 Feb 1999 10:46:25 +1100." <19990208104624.A4862@io.mds.rmit.edu.au> Message-ID: <199902080247.TAA01750@malatesta.local> > Your comments give me the impression that this is unacceptable to you > in the XML/heirarchical universe. You don't want DOM at any level. > You insist on going straight to objects. It is not even good enough > to build an object layer on top of the DOM layer. I find this a > little implausible and hence am certain that you had something else in > mind. Is it rather that you simply don't care what the underlying API > is, that you are only interested in what happens at the object level? I hope I'm not mis-representing Paul here, but as I've always read him (and agreed), his point is that XML, and the various ancillary technologies such as DOM and XML Schema, are more appropriate for content-exchange than for core business-object modeling. I don't think it makes sense to build a business-object model on top of DOM, but I do think it makes sense to define an exchange protocol that selializes objects to XML representations using DOM as a programmatic interface. Hopefully in this effort, one can leverage the support of such technologies as WDDX and XML-RPC, especially as they develop closer ties with other object technologies, including the locally much-maligned CORBA. I think it also makes sense to use the DOM to develop a user-interface layer for such objects, possibly using the same WDDX or XML-RPC mappings in association with a set of style-sheets (although this is just one of many possible mechanisms). -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Feb 8 03:18:43 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:48 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <199902080247.TAA01750@malatesta.local> Message-ID: <000e01be5311$11ed8200$d3228018@jabr.ne.mediaone.net> > Uche Ogbuji wrote: > > > Your comments give me the impression that this is unacceptable to you > > in the XML/heirarchical universe. You don't want DOM at any level. > > You insist on going straight to objects. It is not even good enough > > to build an object layer on top of the DOM layer. I find this a > > little implausible and hence am certain that you had something else in > > mind. Is it rather that you simply don't care what the underlying API > > is, that you are only interested in what happens at the object level? > > I hope I'm not mis-representing Paul here, but as I've always > read him (and > agreed), his point is that XML, and the various ancillary > technologies such as > DOM and XML Schema, are more appropriate for content-exchange > than for core > business-object modeling. Ah, yes but realize that business object modelling is done at a higher level than the relational table (which is a data structure). XML is the serialization of the DOM tree based data structure. When business object need to employ tree based data structures, they may choose to store these in XML serializations. Another option would be for these business objects to interact with a database through the same DOM interfaces. This way the business object layer is isolated from the details of the storage layer. > > I don't think it makes sense to build a business-object model on > top of DOM, No doubt, if you are dealing with tabular data you ought stick with a relational model and use recordsets. If my business objects find it convenient or otherwise useful to employ DOM interfaces, who are you to suggest otherwise? The issue is one of performance. If a low memory, high performance DOM implementation were to appear I guarentee this would be found quite useful. For example, if you decide to build a business object model on top of ODI's eXcelon, which is described as providing a DOM interface, then you would indeed be building a business-object model on top of DOM. If Microsoft, Oracle, POET, Sybase, IBM, Informix etc etc. come out with high performance native DOM interfaces on their databases then you would have effectively isolated your business-object model from the database vendor. The point is that the existence of the DOM doesn't eliminate the need to built business objects, yet it still has an important place as a standards based interface onto trees (i.e. its the closest thing to groves we are likely to see in widescale use). 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 b.laforge at jxml.com Mon Feb 8 03:24:16 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:08:48 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) Message-ID: <000601be5311$d23e4bc0$c9a8a8c0@thing2> This seems similar to the conclusions I've reached. On the one hand, most processes can be driven by a set of object created directly from the SAX events, just using a filter or two to do the transformation. On the other hand, when there is information which must alternately exist as a set of application objects or an XML document, then the DOM seems to be appropriate for modeling the structure of the document. This is in addition to applications where navigating the document is important. The proposal here is to have a common api, MDSAX or something like it, which can serve as a framework for transforming XML into the appropriate application objects; and to have a set of filters that plug into that framework for creating a DOM, when appropriate. (I have a new hammer. Forgive me if I experiment a bit with nails, screws, pieces of wire, and thumb tacks. I'm not sure what the limits of this tool are just yet.) Bill From: uche.ogbuji@fourthought.com <uche.ogbuji@fourthought.com> >I don't think it makes sense to build a business-object model on top of DOM, >but I do think it makes sense to define an exchange protocol that selializes >objects to XML representations using DOM as a programmatic interface. >Hopefully in this effort, one can leverage the support of such technologies as >WDDX and XML-RPC, especially as they develop closer ties with other object >technologies, including the locally much-maligned CORBA. > >I think it also makes sense to use the DOM to develop a user-interface layer >for such objects, possibly using the same WDDX or XML-RPC mappings in >association with a set of style-sheets (although this is just one of many >possible mechanisms). xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 8 04:24:58 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:08:48 2004 Subject: "Clean Specs" In-Reply-To: <000901be5306$838bd0c0$d3228018@jabr.ne.mediaone.net> References: <3.0.1.32.19990207204449.00a4cb9c@pop.uunet.ca> Message-ID: <3.0.1.32.19990207232539.009b558c@pop.uunet.ca> At 08:58 PM 2/7/99 -0500, Borden, Jonathan wrote: > Is the problem here the content of the namespace spec or the way it is >written? It seems to me that people who feel that the spec is a compromise, >or wish the spec specified something different, are unhappy. If you really >don't understand the spec, how can you claim it is a ramshackle compromise? >I suspect that you understand it and don't like it. > > The problem doesn't appear to be the way the spec is written and a >professional writer won't solve that problem. I can claim that it is a ramshackle compromise because I was witness to its creation. The process stunk to high heaven. The result is an awful compromise, and not because I don't like it. As I have said before, the "Namespaces in XML" spec would have more properly been named "Namespaces in RDF". Then I might be able to understand it. It is not the words in the spec that I do not understand. It is that I cannot fathom the logic that holds it together. For example, an appendix purports to describe a fictional XML namespace in which there exist "global" attributes which *cannot* be found in XML -- I defy you to locate a *global* attribute in XML. Or how about names that do not exist in any namespace? Is there an XML namespace or not? Sure, there are parts of the spec that I do not like. And I have done what I could to effect change. But the spec as a whole is not something that I can explain, justify and motivate. 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 Email: murray@yuri.org 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 cowan at locke.ccil.org Mon Feb 8 04:31:09 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:08:48 2004 Subject: "Clean Specs" In-Reply-To: <3.0.32.19990207171050.00c2c870@pop.intergate.bc.ca> from "Tim Bray" at Feb 7, 99 05:13:16 pm Message-ID: <199902080521.AAA21275@locke.ccil.org> Tim Bray scripsit: > I'm > working on an Annotated namespaces, just like annotated XML - and I'm > having serious difficulty figuring out what to write. -Tim Simple. Explain what namespaces 1) aren't; 2) aren't good for. -- 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 eliot at dns.isogen.com Mon Feb 8 04:49:34 1999 From: eliot at dns.isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:08:48 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <000e01be5311$11ed8200$d3228018@jabr.ne.mediaone.net> References: <199902080247.TAA01750@malatesta.local> Message-ID: <3.0.5.32.19990207224950.00809b00@amati.techno.com> At 10:13 PM 2/7/99 -0500, Borden, Jonathan wrote: > > Ah, yes but realize that business object modelling is done at a higher >level than the relational table (which is a data structure). XML is the >serialization of the DOM tree based data structure. When business object >need to employ tree based data structures, they may choose to store these in >XML serializations. Another option would be for these business objects to >interact with a database through the same DOM interfaces. This way the >business object layer is isolated from the details of the storage layer. If I understand you correctly, you're saying: 1. XML documents are serializations of things (such as business objects) 2. The DOM is the abstraction of that serialization 3. Processing systems may need to turn the serialization back into their original objects 3. Therefore we should pretend that relational databases are really DOM trees. This doesn't make any sense to me. Why use the DOM (or any other abstraction of XML documents--I'm not picking on the DOM in particular here) for direct access to business object data? Why not access those objects directly? Or maybe we're talking about what's happening at different layers in the system. Here's the way I view the scenario: I start with a business object: "airplane". I model it abstractly: airplane => [fuselage, wing, tail, cockpit] I then want to create instances of airplanes: I write IDL (or EXPRESS or ...) definitions of my business objects that directly reflect their properties: // NOTE: Phoney IDL interface Airplane { Part Fuselage; Part Wing; Part Tail; Part Cockpit; }; I then have somebody implement some objects to this interface. How do these objects store their data? Don't care. How do they serialize their data? Don't care. Can I use the DOM to access these objects? Of course not--these are airplanes, not documents--the DOM isn't relevant. Now, I put my object implementor hat on: I have to implement this Airplane interface. I think: what technology do I have to store lots of fiddly bits? Do I think "XML"? Maybe. Do I think "relational databases"? Almost certainly. Do I think "object databases"? Quite probably. If I think "XML", why would I think it and what would I get? One reason might be: "hey, I can serialize this stuff to disk using a standard syntax and abstraction--that could make it really easy to use free tools and protect my data through a standard I don't have to pay for the right to use." But then I think "oh, but XML's model might not be a good match for my data structures--might incur a lot of serialization/deserialization overhead." I ponder for a bit. "Let's look at relational databases again--they're fast. I still have to serialize and deserialize, but that technology is mature and I can hire SQL geeks in a heartbeat." I have a Coke. "But wait--object techology looks pretty good too--I could just implement directly to my interfaces and cut out the middle layer. I could still serialize for interchange--I might even get that for free from the OODB vendor." Ok, object databse it is. I program away, happy as a clam. The system works and it is a joy [this is a story, remember]. Now I say, "hey, let's try this XML serialization jabby the vendor provides, wonder what I'll get?" I push the "dump to XML" button. What does it look like? It's ugly--I've got no idea what they were thinking. Angle brackets are swimming before my eyes. But, I know I can suck it back it in, supposedly without loss. I try it--hey presto, my data's back. Cool. Why is this last bit the case? Because there are infinitely many ways to serialize a given set of abstract objects, so only the serializer knows how to do the deserialization. In any case, it's a strong chance that the gap between the XML structure and the business object structure will be at least two levels of abstraction (depending on whether the serialization is late or early bound), if not more. Thus, (and here's the point I've been trying to make from the beginning, so listen closely)... ...wait for it... ...The XML you get out of such as system isn't your business objects--its an arbitrary serialization of the internal representation of your business objects. Using the DOM (that is, an in-memory abstraction of *documents*) as the basis for direct business object access is simply nuts. This is not to say that fundamentally-hierarchical graph-based data models aren't useful for representing business objects--certainly they are (or we wouldn't be bothering to build generalized grove-management systems nor would we have used groves to prepresent HyTime's own business objects). But the DOM, in particular, is not a generalized data structure--it's a way of representing *XML documents* in memory AND NOTHING ELSE. So unless by "DOM" you mean "any fundamentally hierarchical graph representation of data", it's nonsense to talk about using the DOM as the API for data objects--the most that can mean is that *for your flavor of serialization you've defined functions that do the deserialization as an application of the DOM*. Which is fine, but it's not the same as *USING THE DOME FOR DATA ACCESS*, because it's not different from implementing your business objects on top of some other data storage technology. If you do mean graphs, then the DOM, in particular, isn't what you want because it's not generalized--it's a highly optimized, use-specific object model for XML documents. Good for it's purpose but not generalized. It also lacks a more general model of which it is an application. Or said another way: there's no magic in the DOM (or groves or XML) that will make storing and managing business objects easier. What will help are standardized serialization definitions, such as XMI or the new STEP XML Representation work item. But these only limit the number of instances of translation layers that have to be written--they don't eliminate the need for translation between the business object models and their serializations. Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 8 04:59:53 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:48 2004 Subject: "Clean Specs" Message-ID: <3.0.32.19990207205824.00bed660@pop.intergate.bc.ca> At 11:25 PM 2/7/99 -0500, Murray Maloney wrote: >I can claim that it is a ramshackle compromise because I was >witness to its creation. The process stunk to high heaven. >The result is an awful compromise, and not because I don't >like it. In fact, Murray disagrees so strongly with what the spec *says* (often, and on the record) that he is probably not the best judge of how well it says it. -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 uche.ogbuji at fourthought.com Mon Feb 8 05:30:43 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:08:48 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: Your message of "Sun, 07 Feb 1999 22:49:50 CST." <3.0.5.32.19990207224950.00809b00@amati.techno.com> Message-ID: <199902080533.WAA02032@malatesta.local> > Or said another way: there's no magic in the DOM (or groves or XML) that > will make storing and managing business objects easier. I think this is the crux of the matter, and exactly what the "XML is not a universal hammer" folks (myself included) have been trying to get across. I use XML heavily along-side CORBA, and (by way of weak excuse/apology for my rather ad hominem attack on Dave Winer yesterday) I do get very frustrated when people champion using XML to replace very effective and general object-management systems. As much as I hate analogies, I'll hazard one: if you sell people Aspirin as a panacea, and they later on find out that it doesn't cure warts, cancer, dropsy or a crack habit, they might become sour enough to forget that it was actually a very effective pain-reliever. Then again, as Jonathan Borden put it: who am I? -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Mon Feb 8 06:25:19 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:48 2004 Subject: "Clean Specs" References: <3.0.32.19990207205824.00bed660@pop.intergate.bc.ca> Message-ID: <36BE830B.CBBE6552@infinet.com> Tim Bray wrote: > At 11:25 PM 2/7/99 -0500, Murray Maloney wrote: > >I can claim that it is a ramshackle compromise because I was > >witness to its creation. The process stunk to high heaven. > >The result is an awful compromise, and not because I don't > >like it. > > In fact, Murray disagrees so strongly with what the spec *says* > (often, and on the record) that he is probably not the best judge > of how well it says it. -Tim Well who is the best judge then? I thought that standards bodies were largely in existence to promote concensus on matters which companies and organizations disagree upon. Rather than bring everyone together, this entire "Namespaces in XML" recommendation has splintered the entire XML community. By that fact alone, the W3C is not doing a good job as a standards body for the internet. I am a forgiving person when it comes to making one, maybe two complete blunders (such as the case with "Namespaces in XML"), but many people are not as forgiving as I. Most of these people don't post to this list or even subscribe to it. They would just look at "Namespaces in XML" and then quietly go back to their current vendor specific solution for their web-publishing and e-commerce needs and forget the draft ever existed. The same goes for recommendations like XSL which are polluted with "Namespaces in XML" as well. They are the real "silent majority" that the W3C seems to have complete disdain for. The simple truth is that if the W3C does not behave more sensitive to criticism in the future and conduct itself in a more utilitarian manner, or at least make a change in the leadership of the organization, people like me and many others will clamor for creating another internet standards body that is not as slow in adopting standards as ISO or ANSI, but is not as obstinate as the W3C. Of course "Namespaces in XML" has to me been the only super-major screwup in the W3C's short life as a budding internet standards organization. I guess the question now is whether or not the W3C and its members have the courage to make the necessary changes. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Feb 8 06:38:33 1999 From: jborden at mediaone.net (Borden, Jonathan) Date: Mon Jun 7 17:08:49 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) In-Reply-To: <3.0.5.32.19990207224950.00809b00@amati.techno.com> Message-ID: <001501be532c$ffeed060$d3228018@jabr.ne.mediaone.net> W. Eliot Kimber wrote: > > > At 10:13 PM 2/7/99 -0500, Borden, Jonathan wrote: > > > > Ah, yes but realize that business object modelling is done > at a higher > >level than the relational table (which is a data structure). XML is the > >serialization of the DOM tree based data structure. When business object > >need to employ tree based data structures, they may choose to > store these in > >XML serializations. Another option would be for these business objects to > >interact with a database through the same DOM interfaces. This way the > >business object layer is isolated from the details of the storage layer. > > If I understand you correctly, you're saying: > > 1. XML documents are serializations of things (such as business objects) ok. > 2. The DOM is the abstraction of that serialization not my statement. the DOM is an interface onto a tree structure. You are hung up on the term serialization which is specific to files and other flat persistance formats. What I am talking about is persistence in general. An object implementing a DOM interface may be persisted from a file or HTTP stream in which case it is built from a serialization, it may also be persisted from an ODB in which case it is *not* persisted from a serialization. Both the file and the ODB can be used by the DOM. > 3. Processing systems may need to turn the serialization back into their > original objects processing systems may need to obtain heirarchical data from storage systems. these systems need not store information in serial format. again: persistence. > 3. Therefore we should pretend that relational databases are really DOM > trees. no. if the data is tabular then use a recordset. in the specific cases when 1) we are storing data which is naturally hierarchical. 2) when the data needs to interface with systems which for other reasons employ DOM interfaces e.g. my XSL processor us built on a DOM interface and I wish to query the database using XQL (which happens to be built into my XSL processor in this example), it is more convenient to interface to the data using DOM interfaces than it is using recordsets (i.e. tabular data). I am saying over and over: if the data is relational, use recordsets but when the data is hierarchical DOM interfaces provide less of an impedence mismatch onto the data. > > This doesn't make any sense to me. Why use the DOM (or any other > abstraction of XML documents--I'm not picking on the DOM in particular > here) for direct access to business object data? We are NOT talking about direct access to business objects rather the mechanism by which business object talk to the database. The business object tier is above the data object tier. > Why not access those > objects directly? Or maybe we're talking about what's happening at > different layers in the system. yes! yes! yes! > > Here's the way I view the scenario: > > I start with a business object: "airplane". I model it abstractly: > > airplane => [fuselage, wing, tail, cockpit] > > I then want to create instances of airplanes: I write IDL (or EXPRESS or > ...) definitions of my business objects that directly reflect their > properties: > > // NOTE: Phoney IDL > interface Airplane { > Part Fuselage; > Part Wing; > Part Tail; > Part Cockpit; > }; > :-))) Part fuselage is really a structure: interface Airplane { Fuselage f; Wing wleft; Wing wright; Tail t; Cockput c; }; interface Fuselage { Strut strut; X-assembly x; Y-assembly y; }; interface Wing { ... }; and so on, now suppose each airplane has different Fuselage, Wings, Tails, Cockpits; and suppose each of these are build via 10 sub-parts and so on 50 levels deep until we get to sheet metal, screws and wires. An airplane is a complex piece of equipment. > I then have somebody implement some objects to this interface. > How do these > objects store their data? Don't care. How do they serialize their data? > Don't care. Since you appear to be the CEO of the aircraft company, who cares? Why not just have someone design the plane, implement it, test it and build it. Who cares about databases or even computers? If you don't care you don't have an airplane (or the plans for one). Someone has to care about the details. Objects typically don't just 'store data' into databases. Even with ODBMS there is an interface/API onto the DB (this can be base classes in C++ etc. different for each DB) > Can I use the DOM to access these objects? Of course > not--these > are airplanes, not documents--the DOM isn't relevant. Ok suppose I have a set of airplanes lets try this two ways: First with the DOM (stylized): NodeList airplanes_data = container.getElementsByTagName("airplane"); ok now build your business object (this is where you can spend your time). Now with SQL: Recordset rs = conn.Execute("select * from airplanes,fuselages,wings,tails,cockpits,x-assembly,y-assemblies, .... about 3^10 total tables here (assuming 10 levels deep) .... screws,sheets,wires where .....); Alternatively you can write out 3^10 individual select statements. After a few weeks/months of work you can start working on your business object. Arguably, when using an ODBMS this example would be more straightforward (but you picked RDBMS). The problem is that there is no standard, language independent interface onto ODBMS's. The DOM, while not the perfect interface *is* standard, and this is the big utility. ... > Why is this last bit the case? Because there are infinitely many ways to > serialize a given set of abstract objects, so only the serializer > knows how > to do the deserialization. In any case, it's a strong chance that the gap > between the XML structure and the business object structure will be at > least two levels of abstraction (depending on whether the serialization is > late or early bound), if not more. > > Thus, (and here's the point I've been trying to make from the > beginning, so > listen closely)... > > ...wait for it... > > ...The XML you get out of such as system isn't your business objects--its > an arbitrary serialization of the internal representation of your business > objects. Using the DOM (that is, an in-memory abstraction of *documents*) > as the basis for direct business object access is simply nuts. > Actually not even this. First I'm never actually dealing with XML, I've only shown DOM interfaces. My business objects internally use DOM interfaces to interact with a bit-bucket. Where does an XML document come into play here? > This is not to say that fundamentally-hierarchical graph-based data models > aren't useful for representing business objects--certainly they are (or we > wouldn't be bothering to build generalized grove-management systems nor > would we have used groves to prepresent HyTime's own business > objects). But > the DOM, in particular, is not a generalized data structure--it's a way of > representing *XML documents* in memory AND NOTHING ELSE. Err, no. I am saying that I can use the DOM to represent hierarchical data. This data *can* be expressed, serialized, as an XML document, but between my database and my business object, there need never exist an XML document. Say whatever you please but if I have a piece of code from James Clark (e.g. Jade/SP/groveoa) or Microsoft or IBM, I'm quite free to use it as I see fit. For example, I get to say (using 'extended DOM'): NodeList anotherSet = airplanes.selectNodes("airplane[@color='red' and .//screw/thread/@pitch = 64]"); to select all red airplanes with screws having a pitch=64... Have you written alot of programs which directly access databases? Do you ever have to code the objects which access the databases? If you stay up in la la object modelling land, you may not appreciate what I am saying. In working with this stuff, I am finding that I am more efficient, and I can get work done more quickly using these interfaces. ... > > Or said another way: there's no magic in the DOM (or groves or XML) that > will make storing and managing business objects easier. What will help > are standardized serialization definitions, such as XMI or the > new STEP XML > Representation work item. But these only limit the number of instances of > translation layers that have to be written--they don't eliminate the need > for translation between the business object models and their > serializations. > XMOP for example (http://jabr.ne.mediaone.net/documents/xmop.htm) is a way to serialize arbitrary COM objects using their typeinfo metadata. XMOP is a layer that can persist objects into either a) a stream (serialization) b) direct-to-DOM. When I attempted to design a direct-to-Recordset persistence interface on XMOP I found that I had to essentially develop a DOM<->Relational mapping. This is because arbitrary objects can be modelled in a hierarchical fashion (e.g. serialized to XML). In another example, using the medical imaging DICOM protocol (a complex property based protocol) I have developed a mapping to the Microsoft PropertySet format (used with Index Server). This mapping is not clean (at all given the inability to represent certain DICOM structures as PROPVARIANTs). This causes similar problems in mapping the protocol to a relational database (the workaround is to use binary data). Using XML and the DOM was a piece of cake to solve this difficult problem. So, I'm not saying that this is the cure for all the world's problems or that this is a hammer and all the world is a nail, but on the other hand, when you have a hammer in your hand, and you see a nail, take the shot. The simple fact is that the uses of the DOM interfaces are determined not by their designers rather by the creativity of those individuals who use them. The original CPU was designed to be a calculator. Use your imagination. 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 Mon Feb 8 06:45:15 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:08:49 2004 Subject: "Clean Specs" Message-ID: <3.0.32.19990207224352.00bec800@pop.intergate.bc.ca> At 01:24 AM 2/8/99 -0500, Tyler Baker wrote: >Well who is the best judge then? I thought that standards bodies were largely in existence to >promote concensus on matters which companies and organizations disagree upon. Rather than >bring everyone together, this entire "Namespaces in XML" recommendation has splintered the >entire XML community. Uh, just for the record, Namespaces, like any other W3C recommendation, has been through a *long* formal process with many public drafts, and a final poll of the membership. Yes, there are those who disagree, but this is true of virtually every recommendation; there were those who wanted to send XML 1.0 back for more work - same with every other significant W3C product. Consensus in the pure form is never achieved in any standards organization. Operationally, the closest you can get is a determination that all substantive objections have been thoroughly listened-to, and a finding that an overwhelming majority of the community wants to move forward. >I am a forgiving person It doesn't particularly show. >They are the >real "silent majority" that the W3C seems to have complete disdain for. Well, the Mozilla, perl, Internet Explorer, Oracle, and IBM XML offerings already include namespace support. The majority is awfully silent I guess. -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 murray at muzmo.com Mon Feb 8 07:15:40 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:08:49 2004 Subject: "Clean Specs" In-Reply-To: <3.0.32.19990207224352.00bec800@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990208021503.00ed352c@pop.uunet.ca> At 01:44 AM 2/8/99 -0500, Tim Bray wrote: >Uh, just for the record, Namespaces, like any other W3C recommendation, >has been through a *long* formal process with many public drafts, and a >final poll of the membership. For the record, "Namespaces in XML" did not follow a process like any other W3C recommendation. It is disingenuous to suggest that it did. In fact, this spec was not even subject to the scrutiny of a W3C Working Group from August, 1998. [...] > >Well, the Mozilla, perl, Internet Explorer, Oracle, and IBM XML offerings >already include namespace support. The majority is awfully silent I >guess. And where is all of the content? Hmmm! They do seem to be silent. 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 Email: murray@yuri.org 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 Mon Feb 8 07:15:40 1999 From: murray at muzmo.com (Murray Maloney) Date: Mon Jun 7 17:08:49 2004 Subject: "Clean Specs" In-Reply-To: <3.0.32.19990207205824.00bed660@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990208020443.00ed65ec@pop.uunet.ca> At 11:59 PM 2/7/99 -0500, Tim Bray wrote: >At 11:25 PM 2/7/99 -0500, Murray Maloney wrote: >>I can claim that it is a ramshackle compromise because I was >>witness to its creation. The process stunk to high heaven. >>The result is an awful compromise, and not because I don't >>like it. > >In fact, Murray disagrees so strongly with what the spec *says* >(often, and on the record) that he is probably not the best judge >of how well it says it. -Tim The obverse of that logic would lead one to conclude that Tim is not the best judge either. Let's try a bit harder than that, eh? 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 Email: murray@yuri.org 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 tyler at infinet.com Mon Feb 8 07:57:56 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:49 2004 Subject: "Clean Specs" References: <3.0.32.19990207224352.00bec800@pop.intergate.bc.ca> Message-ID: <36BE98B1.73223E62@infinet.com> Tim Bray wrote: > At 01:24 AM 2/8/99 -0500, Tyler Baker wrote: > >Well who is the best judge then? I thought that standards bodies were largely in existence to > >promote concensus on matters which companies and organizations disagree upon. Rather than > >bring everyone together, this entire "Namespaces in XML" recommendation has splintered the > >entire XML community. > > Uh, just for the record, Namespaces, like any other W3C recommendation, > has been through a *long* formal process with many public drafts, and a > final poll of the membership. Yes, there are those who disagree, but This is interesting. Namespaces in XML went from being a proposal with the PI based approach, to a draft, and then to a recommendation. There was only one draft in the period between proposal and recommendation. This I find puzzling compared to the revisions I saw taking place with XML back in the November of 1997. > this is true of virtually every recommendation; there were those who > wanted to send XML 1.0 back for more work - same with every other > significant W3C product. Consensus in the pure form is never achieved > in any standards organization. Operationally, the closest you can > get is a determination that all substantive objections have been > thoroughly listened-to, and a finding that an overwhelming majority > of the community wants to move forward. This is very true. However, it is hard to believe that the great majority of people on the "Namespaces in XML" WG could have views which are in fundamental disagreement. Since votes on these matters are apparently secret, I guess people like me will never know. Moreover, we will never know who is ultimately accountable for these decisions. It is as if the W3C is this omnipotent force that feels they do not need to answer to the developer community at large because the are not accountable. > >I am a forgiving person > > It doesn't particularly show. I am still here actively using XML and discussing XML issues. If I was truly not forgiving I would not waste any more time discussing these sort of issues that the W3C has brought to our attention. I and other developers, XML users, and those considering using XML in their data-processing infrastructure who constribute to this list do so freely. We don't charge the W3C for our consultation (well I guess some of the people here do) so our comments should be taken objectively. This entire business about us developers making some comments and then hoping that the W3C takes them into consideration is a rather feudal concept if you ask me. > >They are the > >real "silent majority" that the W3C seems to have complete disdain for. > > Well, the Mozilla, perl, Internet Explorer, Oracle, and IBM XML offerings > already include namespace support. The majority is awfully silent I > guess. > -Tim That is not the point. These products may support them (some of them I can say support them in rather useless ways as far as the application developer should be concerned), but the real issue here is whether or not "Namespaces in XML" nicely complements XML or else has an overall negative effect on XML's goals. My opinion is of the latter, hence my opposition to the "Namespaces in XML" recommendation and its inclusion in any other W3C specs or related internet standards such as CORBA (yah I have already stated that I personally don't care much about CORBA these days, so I am only using CORBA as an example). Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shecter at darmstadt.gmd.de Mon Feb 8 10:29:30 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:49 2004 Subject: Component Markup Language References: <A26F84C9D8EDD111A102006097C4CD0D054960@SOHOS002> Message-ID: <36BEBA83.259DF589@darmstadt.gmd.de> Mark Birbeck wrote: > I wrote: > > How about this: Have one XSL document per client side > > scripting language. > > We do something similar for browser types, by generating all XSL > documents through an ASP page. In our case, we detect the browser type, > and change the rules in the stylesheet dynamically. Your scenario would > benefit too, because you wouldn't need to send loads of sylesheets to > the client... Hi, Interesting idea. It reminds me of the IBM Alphaworks "XML Enabler" project, which is a framework for doing the same thing: selecting an appropriate XSL stylesheet based on browser type. ( http://www.alphaworks.ibm.com ) This sounds better to me than what you're doing, actually, because it's pure Java/servlets; not Microsoft/ASP dependent. Anyhow, in my scenario, the server would be run by one organzation, and the clients by others. The clients would be responsible for making their own XSL sheets depending on whatever type of platform they have. So, only the XML User Interface / Component description would come over the wire, not the XSL. - 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 shecter at darmstadt.gmd.de Mon Feb 8 10:34:13 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:49 2004 Subject: Component Markup Language References: <0bec01be526d$42222740$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <36BEBD56.1D80AA73@darmstadt.gmd.de> Just an update: Thanks to everyone for all the pointers to things to check in my search for a UI / Component markup language. By the way, when I'm done doing my survey, I can post a summary here if there's interest. So far, the item that's closest to what I've been looking for is: http://www.pierlou.com/prototype ...This is really an interesting system. The XML UI description seems abstracted enough to be able to generate implementations in various languages, but close enough to Java to make mapping to it easy. The only part that's not there (for my requirements) is something like XSL stylesheets for different client-side scripting languages (only a hard-coded XML->Java conversion is supported at this time). But that wouldn't be too big of a deal. - 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 busterdeniro at hotmail.com Mon Feb 8 10:37:39 1999 From: busterdeniro at hotmail.com (Buster Blues) Date: Mon Jun 7 17:08:49 2004 Subject: Little problem with namespace Message-ID: <19990208103609.2409.qmail@hotmail.com> Hi, I would want some informations on namespaces. I want to put my xml sheet in my browser (IE5). I have specified a style sheet, but if I remove this line : http://www.w3.org/TR/WD-xsl, an error occurs. Is it necessary to put a reference on the W3c web page and how to make differently?? Thanks Pascal ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shecter at darmstadt.gmd.de Mon Feb 8 10:40:48 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:49 2004 Subject: CORBA's not boring yet. / XML in an OS? References: <4EB4281B.662222A5@darmstadt.gmd.de> <36B9FA0C.11FBFBC@infinet.com> Message-ID: <36BEBEA7.DDB98BFB@darmstadt.gmd.de> Tyler Baker wrote: > I wrote: > >...this month's Linux Journal - > > it describes how -both- up and coming desktop environments are basing > > major parts of their architectures on CORBA. KDE's so cool it makes me > > want to learn C++. :) > > > Prediction: In 3 years, half the people on this list will be using a > > corba-based desktop environment. > > Not likely. My biggest problem with CORBA was that it was too huge for the client and > consumed too many resources. Actually, I was implying that half of us will be using Linux, and therefore Corba, because it's now in the desktop environments. I -was- exagerating, but I think it's not extreme to predict that in 2-3 years Linux (with KDE or GNOME) will have broken out of the hacker-only world, and onto the desktop. > > > > Anyhow, this naturally makes me wonder - could XML and related ideas > > like XSL have a place in an operating system? Where would they fit in? > > KDE and Gnome could be great playgrounds for trying something like this > > out. > > They already do if you consider Internet Explorer a fundamental part of the Windows Operating > System (-: > Ouch. :) - 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 shecter at darmstadt.gmd.de Mon Feb 8 10:51:23 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:49 2004 Subject: CORBA's not boring yet. / XML in an OS? References: <0d2701be5270$824dbca0$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <36BEC149.AB389419@darmstadt.gmd.de> James Tauber wrote: > >Anyhow, this naturally makes me wonder - could XML and related ideas > >like XSL have a place in an operating system? Where would they fit in? > >KDE and Gnome could be great playgrounds for trying something like this > >out. > > For a while now, I've been thinking what an OS (or more likely shell) would > look like if it took Unix's "everything as a file" to "everything as an XML > element". Now this is interesting. > > > A system would be a single XML "uberdocument"... Applications ... would operate on other > nodes in the element tree. > > There would be an application, for example, that got mail via POP or IMAP, > represented it in XML and then attached it a particular point in the > uberdocument. XSL could be used to sort the mail. XSL would also be used to > view the mail. > Great ideas. I can see that this would just follow the unix philosophy, and could actually be useful: Just like how today, anyone can use the unix command line tools to pipe together small apps to form "new" app/filters, in this XML/OS, someone could use XML/XSL parsers/apps to connect and filter XML to create new apps and filters. The myriad of programs that operate and manipulate XML could manipulate any OS object, program or data. For example, the IBM Alphaworks "Tree Diff" (a Java program that generates "diff" info between two XML documents) can be applied to anything stored in the OS, in the same way that the conventional diff can operate on any text file. > > It's XML for the sake of it, but I think it would be fun to try out. > Absolutely, but I'd also bet that some convincing arguments could be made for real advantages of this. - 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 rbourret at ito.tu-darmstadt.de Mon Feb 8 11:48:15 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:49 2004 Subject: "Clean Specs" Message-ID: <01BE5360.62756860@grappa.ito.tu-darmstadt.de> Tim Bray wrote: > And as regards the namespace spec, I think that some people on this > list are substantially full of shit, and are wilfully refusing to see > how simple it is because it does not meet their own design prejudices. > I think that spec is *way* better than the XML spec. I've quoted this out of order because I think it is a very important point and one that has bothered me during this whole discussion. Tim is absolutely correct here -- the namespaces spec is *way* better than the XML spec. There is absolutely no comparison, both from an organization and a writing (sentence-level) point of view. I think there are three other things to remember with respect to the namespaces spec. First, no matter how you cut them, namespaces turned out to be far more difficult than any of us could have imagined. We didn't, as is the case in most programming languages, simply get them for free based on where we declared our variables -- we had to decorate variables ourselves. Thus, I think the discussion has often confused frustration about technology with frustration about spec writing. Second, watching a spec evolve is not always the best way to judge how good it is. Throughout this discussion, I have wondered how I would have felt about the namespaces spec had I seen it for the first time in its completed form. No doubt I would have had some confusion, but I also would not have been carrying pre-conceived notions from one version to the next, which is where a lot of my confusion about the relation between attributes and namespaces came from. Finally, we have to remember that namespaces appear to work -- I have yet to hear any examples on this list where they don't. Until such examples arise, I think we have more to gain by agreeing to use namespaces than by going off in our own directions. > This group is notably and vocally dissatisfied with the specs, I > am watching with attention for concrete suggestions as to how > to make future specs better - the one premise that seems to get > consensus, in this group at least, is "more examples". (Hmm, the > namespace spec has tons). OK. Enough being nice. Here's the brickbats :) 1) One idea, one term. The namespaces spec uses three terms (XML namespace, traditional namespace, and namespace) for two ideas -- XML and traditional namespaces. This can lead to confusion, as mail between Mark Birbeck and me shows -- he interprets standalone "namespace" (for example, see the definition of "declared") to mean traditional namespace while I interpret it to mean XML namespace. (Interestingly, the spec can be read using either definition, but it does lead to different conclusions.) A more egregious example is the use of "entity" to mean "general entity" in the XML spec -- this might work for the initiated, but is very confusing for first-time readers. 2) Include negative truths as well as positive truths. In the namespaces spec, an example would be to state that unprefixed attributes are not in any (XML) namespace. Although this can be determined from the fact that there are no statements saying that they *are* in a namespace, it is much easier for the spec to say this than for the reader to work it out themself. The reason this is important is that the definition of an XML namespaces sets the readers expectations by stating that they include attribute names. As another example of negative truths, non-goals are often as useful as goals in setting the reader's expectations. 3) Be explicit about goals. Although the namespaces spec describes its goals in general form in the motivation section, I think spelling these out might have helped a lot. In particular, it would have saved us from having to write "Unique names. Really. Just unique names. Nothing more. Really." in email over and over and over. 4) Organization counts. Organization it is often harder than the writing itself and many writing problems stem from organizational problems. The namespaces spec is very good in this respect. The XML spec is a nightmare. Some easy examples: a) The definition of a document is tucked away in a section on well-formedness. b) DTDs are introduced in the same section as prologs and version numbers, but otherwise spread across the spec, including such things as putting Conditional Sections in section 3 (Logical Structures). c) Section 2.8 tells us that attribute-list declarations in the internal subset take precedence over those in the external subset. This information either belongs in, should be repeated, or should be referenced from the section on attribute list declarations, but is not. 5) Headings matter. They set the reader's expectation for what is to come, and if the section doesn't answer the questions raised in the reader's mind by the heading, the result is confusion even if the section is well-written. Except for Appendix A, the namespace spec does a good job here. My favorite mis-leading heading in the XML spec is "Documents" (section 2), which would have better been titled "Miscellany". 6) Include cross references. Again, the namespaces spec is very good and the XML spec is a nightmare -- trying to find an EBNF definition and the corresponding text when it is not in front of your face is almost impossible without hypertext. 7) As appropriate, include motivation. Admittedly, this is thinner ice, but it can be useful. For example, the motivation for namespace defaults is presumably to reduce the number of prefixed elements. Including this information gives the user something they can immediately grab on to. Similarly, the motivation for allowing namespace declarations on any element is presumably the ability to assemble a document from fragments, as well as the ability to redeclare defaults. Stating this motivation deflects the reader from wondering why on earth anybody would want to keep changing their prefixes. 8) Restate when necessary. This is more thin ice. Succinct statements are useful, but often overly loaded with meaning and difficult to interpret. Maybe I'm just dense, but when I read the statement, "...default namespaces do not apply to directly to attributes", my first reaction was "Huh?" This statement includes two important concepts, neither of which was immediately obvious to me. The first is that: a) The lack of a prefix on an element means it is in the default namespace, if there is one. b) Attributes can also lack a prefix. c) Because attributes can lack a prefix, we are explicitly stating that they behave differently from elements and do not automatically belong in a namespace. The second is that: a) Elements can be in an XML namespace. b) According to the XML spec, elements implicitly have a traditional namespace for their attribute names. c) Thus, defaults apply to attributes indirectly in that they give the (XML) namespace of the element containing the attribute (traditional) namespace. Thus, although the statement is concise and correct, a clarifying sentence or three that restated the same thing would have been very helpful. 9) Emphasize the important stuff; cover the obscure stuff. A spec has an obligation to be thorough, so it must cover everything, no matter how infrequently something is used. However, how it is organized and how much is devoted to each topic strongly influences the reader's perspective. As an example of misleading organization, the XML spec discusses such things as comments, PIs, white space, and CDATA sections before it ever tells us what an element looks like. This gives the impression that these are more important. To the average reader, XML is about elements and attributes and declaring them; white space can be forward-referenced and the rest can be relegated to a later part of the spec without harm. Similarly, the namespace spec could tell us how to use prefixes before telling us how to declare them. This motivates the reader to see the usefulness of namespaces and makes them think, "Cool! Now how do I declare these prefix thingies?" Quantity devoted to a subject can also be misleading. For example, the last example in section 5.2 is the largest in the namespace spec. As a reader, this leads me to believe it is very important, when in fact it covers a seldom-used case. Section 2.12 (Language Identification) is similarly misleading, although the authors in that case might have had good reason to believe it would be more widely used than it has. > Having said all that, people who write specs always have to try to > do a better job next time, so this recent discourse is very very useful. Thanks for listening. I hope this has been helpful. -- 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 rbourret at ito.tu-darmstadt.de Mon Feb 8 12:06:14 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:08:49 2004 Subject: "Clean Specs" Message-ID: <01BE5362.E9115440@grappa.ito.tu-darmstadt.de> Don Park wrote: > I do realize that the XML spec is leaky in certain respect but I felt it is > very clear as a whole although I am unable to point out exactly what makes > it so. If I may venture an opinion, the XML spec is sloppily written, informal, and poorly organized. The namespaces spec is tightly written, well-organized, and relatively formal. I believe it is the informality of the XML spec that makes it clear as a whole -- it certainly isn't the organization. For example, at the end of section 2.8, we are told that an internal DTD is interpreted before an external DTD and that one consequence of this is that attributes in the internal DTD override those in the external DTD. The spec doesn't need to tell us this consequence -- it can be determined from the statements that internal DTDs are interpreted first and that the first attribute declaration wins. However, by telling us this and similar things, we are saved a lot of hard thinking and confusion and therefore are happier with the spec and understand it better. The namespaces spec does this less often, but when it does, feels very approachable. A good example of this is the statement in section 4 about operational difficulties when default attributes are declared in external DTDs. The spec doesn't need to tell us this, but saves us a lot of time and pain when it does. -- 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 Feb 8 12:15:45 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:08:50 2004 Subject: When to use attributes vs. elements In-Reply-To: <5BF896CAFE8DD111812400805F1991F708AAEF3C@RED-MSG-08> Message-ID: <Pine.GHP.4.02A.9902081131000.27539-100000@mail.ilrt.bris.ac.uk> On Fri, 5 Feb 1999, Andrew Layman wrote: > Thank you. Dan asks a reasonable question, which is whether a document that > uses the conventions described in > http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.html needs to > signal somehow that these conventions are in play. > > In case of the "canonical format" I proposed, however, I don't think special > signalling is necessary: The proposal does not add any new interpretations > to the use of elements or attributes beyond what can be described in a DTD > or a schema such as XML-Data or DCD. Elements, attributes, ids and idrefs > are carefully used so that their normal XML interpretation matches the > scoping and linking rules of object graphs or relational databases. So, to be clear on what you're claiming... For any chunk of 'normal' XML, you have a set of interpretation rules that tell us how all the attributes and elements map into "graphs of data such as database tables and relations, nodes and edges from directed labeled graphs, and similar constructions"[1]. This would be enormously useful, if people could be persuaded it were true. > In a general case, if conventions add rules for interpretation above what is > in the structure of a document or above what can be expressed in a DTD, then > this would need to be somehow signalled in order for a reader to process the > document. I'm a little confused in that [1] proposes a canonical framework for interpreting all XML as graph serialisations, but then goes on to discuss "Mapping Abbreviated Syntax to Canonical Syntax": However, the canonical syntax is not the only syntax that could be used to serialize a graph. In many cases, alternative syntaxes may be used, either due to historical or political factors, or to take advantage of compressions that are available if one has domain knowledge. We call all of these "abbreviated syntaxes."[1] This implies that some unknown subset of XML instance data will have been serialised according to one or more alternate serialisation algorithms. Consequently de-serialising such data according to the 'canonical' algorithm will garble your data. In which case we're back in a situation where we need a mechanisms such as <XYZ:SerializationAccordingToAndrew> to tell us which data can be interpreted according to the 'canonical' rules versus some alternate (possibly unknown) serialisation rules. The example alternate serialisation given is: <Class> <name>Western Civilization</name> <taughtBy>Thorsten</taughtBy> <attendedBy>Raphael</attendedBy> <attendedBy>Smith</attendedBy> </Class> Interpreting this according to the "Procedure for XML Instance to Graph Conversion" rule will give garbage data. We simply don't know from looking at the XML above what nodes and edges it creates. The fact that we need to treat such data in a special manner is worrying: how are we supposed to _know_ when there is something else to know? (repeated from above) > In a general case, if conventions add rules for interpretation above what is > in the structure of a document or above what can be expressed in a DTD, then > this would need to be somehow signalled in order for a reader to process the > document. This suggests that the burden is placed upon content creators to flag up when the generic 'canonical' rule wouldn't usefully apply to the interpretation of the XML content. So the default behaviour would be to assume everyone used the rules outlined in [1] unless associated schema, stylesheet or enclosing tags told us otherwise? So... if I'm a 'canonical-format' aware processor building a graph from XML data acquired from a variety of sources, what procedure do I follow to sort XML instance data into the follow categories: a) old XML files which *happen* to have been serialised according to the canonical-format rules b) old XML files which happen *not* to have been serialised according to the canonical-format rules. (for example, the extract above) c) recent XML files created by following the c-f rules for serialising graphs d) recent XML files created using an alternative or abbreviated graph serialisation algorithm as discussed in [1] In particular, I'm concerned that (a) and (b) are mechanically indistinguishable. Dan [1] http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.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 jayadeva at lgsi.co.in Mon Feb 8 12:51:08 1999 From: jayadeva at lgsi.co.in (Jayadeva Babu Gali) Date: Mon Jun 7 17:08:50 2004 Subject: problem Message-ID: <36BEDDED.7A9516BA@lgsi.co.in> hi, how can i call the image (.gif) from XML file through xsl i have written the like below but xml file whe i called from MSIEBeta5 it is not displaying the images. All files is in the same directory with gif's also. /****** xml file *****/ <?xml version="1.0"?> <?xml:stylesheet type="text/xsl" href="test.xsl"?> <items> <item> <param>picture1</param> <picture>green-ball.gif</picture> </item> <item> <param>picture2</param> <picture>yellow-ball.gif</picture> </item> </items> /************** xsl file ***********/ <?xml version="1.0"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" xmlns="http://www.w3.org/TR/REC-html40" result-ns=""> <xsl:template match="/"> <table> <xsl:for-each select="items/item"> <tr> <td> <xsl:value-of select="param"/> </td> <td> <img> <xsl:attribute> <xsl:value-of select="picture"/> </xsl:attribute> </img> </td> </tr> </xsl:for-each> </table> </xsl:template> </xsl:stylesheet> regds.....jayadev xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Feb 8 13:03:05 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:50 2004 Subject: document vs non-document entity (was Re: CORBA's not boring yet. / XML in an OS?) References: <002101be52be$e92480a0$0300000a@othniel.cygnus.uwa.edu.au> Message-ID: <36BEE1B6.8108B0C9@mecomnet.de> This raises the question: "What is the extent of an entity binding?" Assume that is possible to qualify entity names. Since these qualifications are already lexically scoped, why would one need to introduce local entity definitions? The effective entity is already determined by a binding with a lexical scope. One reason could be that the form actually makes explicit a dynamic extent for "local" entity definitions and is set in contrast to an indefinite extent for "global" definitions within the dtd (or elsewhere). I have gathered from discussions, that contemporary implementation techniques already enforce a dynamic extent for entity definitions - they "live" exactly as long as the document. Unless this changes, then local entities are not strictly necessary. With an XML/OS there may well be cause to change the binding semantics. James Tauber wrote: > > Paul Prescod: > >This is a serious problem inherited from SGML. It is my opinion that > >instead of namespace declarations being done through attributes they > >should have been just another form of PI-based declaration. Then in > >version 2.0 of XML, all declarations should have been made "localizable." I don't understand the connection here. Where is the dependancy? > >In particular, there should be a way to declare internal text entities, > >unparsed entities and attribute defaults locally. > > Well this is actually where my thinking has been going. I've been thinking > about whether localizable declarations might be achievable using an > *attribute* mechanism following on from how namespaces ended up. > > ... > > The xmldecl attribute takes the value of the URI of an external parameter > entity. > > To avoid name clashes, it might be an idea to have > xmldecl:foo="local-decl.pen" and then qualify entities with the prefix foo > (ie &foo:SomeEntity;) While I agree that this will ultimately prove necessary, I suggest that qualified entity names render local entity bindings redundant. It is equivalent to mapping each of the definition names into a distinct namespace at the point of definition and using lexically bound prefixes to map the reference name accordingly. Opps! Yea, I forgot, there is no way to bind a prefix in the DTD (ie "the point of definition"). Got to wait for schemas for this. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Feb 8 13:28:21 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:08:50 2004 Subject: "Clean Specs" References: <3.0.32.19990207171050.00c2c870@pop.intergate.bc.ca> Message-ID: <36BEE79E.D85840DF@mecomnet.de> Tim Bray wrote: > ... > > I gotta say, though, the XML spec now feels to me like a ramshackle > compromise that only just barely works, while namespaces do one simple > thing and nail it down tight as a drum. Here's how bad it is; I'm > working on an Annotated namespaces, just like annotated XML - and I'm > having serious difficulty figuring out what to write. -Tim > Please correct or rewrite the equivalent of Appendix A so that neither you, nor the spec, nor other prominent contributors to this forum feel that it is necessary to disavow it. Use the definitions/formalism it then contains to describe the examples in the spec. While this order of exposition is not ideal, the prose in the recommendation has "gotten there first". Introduce additional examples to document the combinations ((default or overridden bindings) X (prefixed or unprefixed element names) X (prefixed or unprefixed attributes names)) which are missing. For this reader, Appendix A would have been the most useful thing to support an implementation. While I have come to accept that one should not expect a definition of a similar form (that is, something at least approximating a denotational definition) for XML proper, it is unfortunate that the spec for namespaces does not include a formal definition. And that the semi-formal description is relegated to "non-normative" status. The difference between XML proper and "Namespaces in XML" is that while XMLdescribes a code, for which the BNF suffices, the namespace spec deals exactly with the relation between the encoded representation and another domain. If there were a formal description of this relation, then it would easier to understand, easier to check for completeness and correctness and, ultimately, easier to produce a conforming implementation. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From uche.ogbuji at fourthought.com Mon Feb 8 13:53:38 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:08:50 2004 Subject: Announcement: 4DOM 0.7.0 Message-ID: <199902081355.GAA02899@malatesta.local> FourThought LLC (http://FourThought.com) announces the release of 4DOM 0.7.0 ----------------------- A CORBA-aware implementation of the W3C's Document Object Model in Python 4DOM is a close implementation of the DOM, including DOM Core level 1, DOM HTML level 1, Node Iterator and Node Filter from DOM Level 2, and a few utility and helper components. 4DOM was designed from the start to work in a CORBA environment, although an orb is no longer required. For using 4DOM in an ORB environment, Fnorb and ILU are supported. 4DOM is designed to allow developers rapidly design applications that read, write or manipulate HTML and XML. New in 4DOM 0.7.0 ----------------- - Added support for "orbless" configuration. Now neither ILU nor Fnorb are requred and 4DOM can be run purely locally, but still with a consist ent interface. Naturally, the orbless config is much faster than the ilu or fnorb configs. - Many fixes to improve consistency over an ORB interface (an example using an ORB has been added to demos). - Fixes to NodeList and NamedNodeMap - Added an Ext package for DOM extensions, and moved many of the existing extensions there. See docs/Extensions.html. - Added to Ext an extensive factory interface for creation of nodes, consistent for local and ORB use. - Added to Ext a ReleaseNode helper function to reclaim unused nodes, necessary for ORB usage, and also for local usage because of circular references. - Added NodeIterators and Node Filters from DOM Level 2 - Added a visitor and walker system (to Ext). These generalize the NodeIterator concept for cases where pre-order traversal is not suitable: for instance printing. - Removed the repr functions from Node interfaces in favor of print walker/visitors. - Added Print and PrettyPrint helper functions to Ext for printing and pretty-printing node trees. - Added Strip helper function to Ext to strip all ignorable white-space text nodes from a node tree. - Moved all tools to construct a DOM tree from XML and HTML text to a Builder module in Ext, with two functions: FromXML and FromHTML. - Added options to FromXML that allow specification of whether to keep ignorable whitespce int he resultant node tree, and options on whether to validate. - Innumerable minor and miscellaneous fixes But what about PyDOM? --------------------- Please note that the XML-SIG is working on a separate DOM implementation, and there is currently discussion regarding the relative roles of 4DOM and PyDOM. PyDOM follows a more Python-like interface, returning a dictionary of nodes, for instance, where the DOM spec specifies an object with NamedNodeMap interface. This was a deliberate choice for the convenience of Python programmers. Also, PyDOM can build and write HTML, but only supports HTML nodes through the DOM core interface. 4DOM strictly follows the DOM interface specs and supports all HTML element capabilities. However, 4DOM is a bit more heavyweight. More info and Obtaining 4DOM ---------------------------- Please see http://OpenTechnology.org/projects/4DOM 4DOM is distributed under the terms of the GNU Library Public License (LGPL). http://www.gnu.org/copyleft/lgpl.html -- Uche Ogbuji uche.ogbuji@fourthought.com Consulting Member, FourThought LLC http://FourThought.com http://OpenTechnology.org xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 8 14:03:35 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:50 2004 Subject: "Clean Specs" In-Reply-To: <36BEE79E.D85840DF@mecomnet.de> References: <3.0.32.19990207171050.00c2c870@pop.intergate.bc.ca> <36BEE79E.D85840DF@mecomnet.de> Message-ID: <14014.60860.129927.264822@localhost.localdomain> james anderson writes: > The difference between XML proper and "Namespaces in XML" is that > while XMLdescribes a code, for which the BNF suffices, the > namespace spec deals exactly with the relation between the encoded > representation and another domain. If there were a formal > description of this relation, then it would easier to understand, > easier to check for completeness and correctness and, ultimately, > easier to produce a conforming implementation. I'm not certain that this is exactly right. "Namespaces in XML" describes a naming scheme that can enable a relation between the encoded representation and another domain, but it specifies neither the relation nor the other domain. I'm going to try a very simple exposition in a separate message. 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 skshirsa at nortelnetworks.com Mon Feb 8 14:25:25 1999 From: skshirsa at nortelnetworks.com (Shekhar Kshirsagar) Date: Mon Jun 7 17:08:50 2004 Subject: problem Message-ID: <3.0.32.19990208092032.006a147c@bl-mail2.corpeast.baynetworks.com> Hi, In your XSL style sheet attribute name (SRC) was missing. Here is the correct XSL rule : <img> <xsl:attribute name="SRC"> <xsl:value-of select="picture"/> </xsl:attribute> </img> Thanks & Regards, Shekhar Kshirsagar Nortel Networks. At 06:21 PM 2/8/99 +0530, Jayadeva Babu Gali wrote: >hi, > >how can i call the image (.gif) from XML file through xsl i have >written the like below but xml file whe i called from MSIEBeta5 it is >not displaying the images. All files is in the same directory with gif's >also. > >/****** xml file *****/ ><?xml version="1.0"?> ><?xml:stylesheet type="text/xsl" href="test.xsl"?> ><items> > > <item> > <param>picture1</param> > <picture>green-ball.gif</picture> > </item> > > <item> > <param>picture2</param> > <picture>yellow-ball.gif</picture> > </item> > ></items> > > >/************** xsl file ***********/ ><?xml version="1.0"?> ><xsl:stylesheet > xmlns:xsl="http://www.w3.org/TR/WD-xsl" > xmlns="http://www.w3.org/TR/REC-html40" > result-ns=""> ><xsl:template match="/"> ><table> ><xsl:for-each select="items/item"> > <tr> > <td> > <xsl:value-of select="param"/> > </td> > <td> > <img> > <xsl:attribute> <xsl:value-of select="picture"/> ></xsl:attribute> > </img> > </td> > </tr> ></xsl:for-each> ></table> ></xsl:template> ></xsl:stylesheet> > > >regds.....jayadev > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon Feb 8 14:28:25 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:50 2004 Subject: CORBA's not boring yet. / XML in an OS? Message-ID: <005b01be536f$869eec70$5ff96d8c@NT.JELLIFFE.COM.AU> From: Robb Shecter <shecter@darmstadt.gmd.de> >James Tauber wrote: >> For a while now, I've been thinking what an OS (or more likely shell) would >> look like if it took Unix's "everything as a file" to "everything as an XML >> element". > >Now this is interesting. This is not so-far fetched. The idea for the XML Encoding PI comes from a University of Hong Kong (or was it the Chinese University of HK) project called HANZIX: a version of UNIX which would accept Chinese text streams in multiple encodings. They came up with the idea "Codeset Announcement"; XML uses an (improved) version of this. I suppose the sgrep tool is an example too: but do you really want to be parsing and serializing XML, unless it is very large text with localized processing? Maybe it would be better to generalize the pipe mechanism so that it connects either text or a DOM object too. 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 Mon Feb 8 14:40:57 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:50 2004 Subject: 19 Short Questions about Namespaces (with Answers) Message-ID: <14014.60982.658099.349181@localhost.localdomain> 19 SHORT QUESTIONS ABOUT NAMESPACES (WITH ANSWERS) by David Megginson Monday 8 February 1999 BACKGROUND ---------- For the full specification of XML 1.0, see [1]; for the full specification of Namespaces in XML, see [2]. This brief review uses James Clark's notation for writing names that contain both a URI part and a local part. For example, if the URI part of a name were "http://www.foo.com/" and the local part were "a", the name would be written {http://www.foo.com/}a This is purely a convenience notation for the sake of documentation; it is not defined by any known specification, and is unlikely to be recognised by any processor. CHAPTER ONE: The XML 1.0 Perspective ------------------------------------ [Example] <a b="x" c="y"/> [Q] What is the name of the element in the example above? [A] The name is "a". [Q] What is the name of the first attribute in the example above? [A] The name is "b". [Q] What is the name of the second attribute in the example above? [A] The name is "c". [Q] What do the names mean? [A] The application determines the meaning of the names. [Q] How do you write a DTD declaration describing the structure of this element? [A] <!ELEMENT a EMPTY> <!ATTLIST a b CDATA #IMPLIED c CDATA #IMPLIED> CHAPTER TWO. The Namespaces Perspective --------------------------------------- [Example 2a] <z:a z:b="x" c="y" xmlns:z="http://www.foo.com/"/> [Q] What is the name of the element in the example above? [A] The name is "z:a" from the XML 1.0 perspective, or "{http://www.foo.com/}a" from the Namespaces perspective. [Q] What is the name of the first attribute in the example above? [A] The name is "z:b" from the XML 1.0 perspective, or "{http://www.foo.com/}b" from the Namespaces perspective. [Q] What is the name of the second attribute in the example above? [A] The name is "c" from both the XML 1.0 and the Namespaces perspectives. [Q] What is the name of the third attribute in the example above? [A] The name is "xmlns:z" from the XML 1.0 perspective; from the Namespaces perspective, this attribute is a declaration. [Q] What do the names mean? [A] The application determines the meaning of the names. [Q] What does the namespace URI "http://www.foo.com/" mean? [A] It has no defined meaning. [Q] How do you write a DTD declaration describing the structure of this element? [A] DTDs use the XML 1.0 perspective: <!ELEMENT z:a EMPTY> <!ATTLIST z:a z:b CDATA #IMPLIED c CDATA #IMPLIED xmlns:z CDATA #FIXED "http://www.foo.com"> [Example 2b] <a b="x" c="y" xmlns="http://www.foo.com/"/> [Q] What is the name of the element in the example above? [A] The name is "a" from the XML 1.0 perspective, or {http://www.foo.com/}a from the Namespaces perspective. [Q] What is the name of the first attribute in the example above? [A] The name is "b" from both the XML 1.0 and the Namespaces perspectives. [Q] What is the name of the second attribute in the example above? [A] The name is "c" from both the XML 1.0 and the Namespaces perspectives. [Q] What is the name of the third attribute in the example above? [A] The name is "xmlns:z" from the XML 1.0 perspective; from the Namespaces perspective, this attribute is a declaration. [Q] What do the names mean? [A] The application determines the meaning of the names. [Q] What does the namespace URI "http://www.foo.com/" mean? [A] It has no defined meaning. [Q] How do you write a DTD declaration describing the structure of this element? [A] DTDs use the XML 1.0 perspective: <!ELEMENT a EMPTY> <!ATTLIST a b CDATA #IMPLIED c CDATA #IMPLIED xmlns CDATA #FIXED "http://www.foo.com"> REFERENCES ---------- [1] http://www.w3.org/TR/REC-xml [2] http://www.w3.org/TR/REC-xml-names All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Mon Feb 8 15:20:51 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:08:50 2004 Subject: Clear specs: suggestions Message-ID: <3.0.32.19990208101713.007bf670@polaris.net> It's been educational, not to say entertaining, to have read the firestorm of opinion over the last week. (Ron Bourret's recent posts on suggestions for clarifying the Namespaces in XML spec, and contrasting it with XML 1.0's, was especially well-done and much appreciated.) I thought of a couple things the W3C might do to help ensure the quality of standards *documents* (vs. the quality of the standards-behind-the-documents). Both of these suggestions would apply only to documents at the WD or later stage -- NOTEs would be exempt. (1) Templates (or at least, guidelines): This seems so obvious that I can't believe it's not already being done; a few comments in the last week imply, however, that each WG sort of goes about the preparation of the document with its own ideas, more or less, of what a spec should look like and how much detail it should contain. I'm thinking here of DTDs for WDs, PRs, and RECs. The content model for the WD level might contain elements like "openissue" that would be absent from the latter two levels -- or relegated to "for future consideration" appendices. I really liked the approach suggested by Ron (I think; apologies if I'm either misattributing the idea or misrepresenting Ron) -- formalism, narrative, examples. That suggests the main content model for each topic and sub-topic in a spec. (2) Establish editorial-review committees at least at the level of the W3C's four "domains": User Interface, Technology & Society, Architecture, and the Web Accessibility Initiative. (Depending on resource requirements and availability, this might better be pushed down to the level of individual activities within those domains.) Because these committees would be familiar with the broad issues as well as, perhaps, some of the details, but not involved at the nitty-gritty level of thinking of the spec writers, I'd think they'd be good stand-ins for the target audience(s). In order not to bog down the drafting process, a given spec's editorial review might be required no sooner than the transition to PR, but definitely before becoming a REC. My apologies if I'm speaking out of turn here. I'm not a member (nor is my employer) of the W3C; these just seemed to be two reasonable, non-onerous approaches to ensuring clarity and consistency in published specs. Best, JES ============================================================= 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 RDaniel at DATAFUSION.net Mon Feb 8 15:37:22 1999 From: RDaniel at DATAFUSION.net (Ron Daniel) Date: Mon Jun 7 17:08:50 2004 Subject: Colonialism, SAX, Java, and Namespaces Message-ID: <0D611E39F997D0119F9100A0C931315C4123B5@datafusionnt1> Tyler Baker says: > The > fact that no one is using this supplement to XML called "Namespaces in > XML" ... I'm sorry Tyler, but that is just not true. I, for one, am using namespaces in a commercial product. Dave Megginson has stated several times on this list that he is using namespaces in things he is selling his customers. Specifications that are getting ready to come out, such as RDF and XSL, are using them. This is because they solve a particular problem - groups can work independently on their specifications without having to establish a centralized registry of element and attribute names. You will see more use of namespaces over time, especially as groups define sets of elements with the intent that people take and reuse them. The basic ideas of the namespaces spec are really simple: 1) In order to prevent name collisions we need a way to uniquify the names, associating a URI with them is one way that fits in well with the web ethos. 2) Simply concatenating the URI and the name to be qualified would be one way to do it, but the names would be very long and they wouldn't be legal XML 1.0. 3) The xmlns: attribute lets us define abbreviations for the URIs (the prefixes) so now we can get pretty short unique names that will be legal. Things get a bit more involved with the scoping and defaulting rules, but not that much. Regards, Ron Daniel Jr. DATAFUSION, Inc. 139 Townsend Street, Ste. 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 david at megginson.com Mon Feb 8 15:42:20 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:08:50 2004 Subject: [corrected] 19 Short Questions about Namespaces (with Answers) In-Reply-To: <14014.60982.658099.349181@localhost.localdomain> References: <14014.60982.658099.349181@localhost.localdomain> Message-ID: <14015.1272.25782.171309@localhost.localdomain> [The inevitable typo showed up -- thanks to Adam Donahue and John Simpson for pointing it out, and even just for reading far enough to find it.] 19 SHORT QUESTIONS ABOUT NAMESPACES (WITH ANSWERS) by David Megginson Monday 8 February 1999 (v.2) BACKGROUND ---------- For the full specification of XML 1.0, see [1]; for the full specification of Namespaces in XML, see [2]. This brief review uses James Clark's notation for writing names that contain both a URI part and a local part. For example, if the URI part of a name were "http://www.foo.com/" and the local part were "a", the name would be written {http://www.foo.com/}a This is purely a convenience notation for the sake of documentation; it is not defined by any known specification, and is unlikely to be recognised by any processor. CHAPTER ONE: The XML 1.0 Perspective ------------------------------------ [Example] <a b="x" c="y"/> [Q] What is the name of the element in the example above? [A] The name is "a". [Q] What is the name of the first attribute in the example above? [A] The name is "b". [Q] What is the name of the second attribute in the example above? [A] The name is "c". [Q] What do the names mean? [A] The application determines the meaning of the names. [Q] How do you write a DTD declaration describing the structure of this element? [A] <!ELEMENT a EMPTY> <!ATTLIST a b CDATA #IMPLIED c CDATA #IMPLIED> CHAPTER TWO. The Namespaces Perspective --------------------------------------- [Example 2a] <z:a z:b="x" c="y" xmlns:z="http://www.foo.com/"/> [Q] What is the name of the element in the example above? [A] The name is "z:a" from the XML 1.0 perspective, or "{http://www.foo.com/}a" from the Namespaces perspective. [Q] What is the name of the first attribute in the example above? [A] The name is "z:b" from the XML 1.0 perspective, or "{http://www.foo.com/}b" from the Namespaces perspective. [Q] What is the name of the second attribute in the example above? [A] The name is "c" from both the XML 1.0 and the Namespaces perspectives. [Q] What is the name of the third attribute in the example above? [A] The name is "xmlns:z" from the XML 1.0 perspective; from the Namespaces perspective, this attribute is a declaration. [Q] What do the names mean? [A] The application determines the meaning of the names. [Q] What does the namespace URI "http://www.foo.com/" mean? [A] It has no defined meaning. [Q] How do you write a DTD declaration describing the structure of this element? [A] DTDs use the XML 1.0 perspective: <!ELEMENT z:a EMPTY> <!ATTLIST z:a z:b CDATA #IMPLIED c CDATA #IMPLIED xmlns:z CDATA #FIXED "http://www.foo.com"> [Example 2b] <a b="x" c="y" xmlns="http://www.foo.com/"/> [Q] What is the name of the element in the example above? [A] The name is "a" from the XML 1.0 perspective, or {http://www.foo.com/}a from the Namespaces perspective. [Q] What is the name of the first attribute in the example above? [A] The name is "b" from both the XML 1.0 and the Namespaces perspectives. [Q] What is the name of the second attribute in the example above? [A] The name is "c" from both the XML 1.0 and the Namespaces perspectives. [Q] What is the name of the third attribute in the example above? [A] The name is "xmlns" from the XML 1.0 perspective; from the Namespaces perspective, this attribute is a declaration. [Q] What do the names mean? [A] The application determines the meaning of the names. [Q] What does the namespace URI "http://www.foo.com/" mean? [A] It has no defined meaning. [Q] How do you write a DTD declaration describing the structure of this element? [A] DTDs use the XML 1.0 perspective: <!ELEMENT a EMPTY> <!ATTLIST a b CDATA #IMPLIED c CDATA #IMPLIED xmlns CDATA #FIXED "http://www.foo.com"> REFERENCES ---------- [1] http://www.w3.org/TR/REC-xml [2] http://www.w3.org/TR/REC-xml-names 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 JEROME.YUROW at hq.doe.gov Mon Feb 8 15:55:00 1999 From: JEROME.YUROW at hq.doe.gov (JEROME.YUROW@hq.doe.gov) Date: Mon Jun 7 17:08:50 2004 Subject: "Clean Specs" Message-ID: <M4286305985.002.uexi1.1.990208155605Z.CC-MAIL*/O=HQ/PRMD=USDOE/ADMD=ATTMAIL/C=US/@MHS> Message authorized by: : paul@prescod.net_at_INTERNET at X400PO -------------- next part -------------- Paul Prescod wrote: >What is a "clean spec?" >People in this discussion are mixing together a variety of things >that I do not consider the same. >Uche Ogbuji wrote: >> I have worked on teams implementing DOM, XSL and parts of XLL. >>Some users > might grant that we have been "succeeding", but let me >>assure you that if so, >> it is despite the W3C specs, not because of them. DOM, especially >>is >> unforgivably inconsistent, incomplete, and unclear for a >>production-ready > (1.0) specification. >There is not a SINGLE person on this mailing list that would say that >it is right to create specifcations that are inconsistent, incomplete >or unclear. It is beyond doubt that specifications in the XML family, >including XML itself, have these problems. The question is how to >avoid that? >* some people say that what the spec needs is "more English". But >much of >the problem with the namespaces specification comes from ambiguity in >the English. >* some people say that we need "more non-normative text" but once >again, >it is a non-normative appendix that is confusing people. >What almost nobody has suggested is that we need more formal >notation. Now if we look at James Clark's "clarifying" document what >we see is *less* English text and *more* notation. >As David Megginson has pointed out, when a spec. invents a notation >to explain its abstract concepts the spec. becomes temporarily harder >to read because you have to learn the notation before the >specification. This will turn people off. I remember that Algebraic >notation turned me off in my first year math classes. But in the >*long run* it makes life easier for everyone. Implementors have >precise definitions of what the hell they are supposed to implement. >End-users get software they can use. People reading the specification >for their own education and edification will understand it better -- >if they perservere through the task of learning the notation. >I know that W3C spec. writers are under pressure to use more >normative English and less normative notation. This is not a vote for >"clean" specifications. It is a vote for messy, hard-to-implement >ones. Where is Dan Connolly when you need him? Let's face it,folks, people do their best work when they're allowed to do what they do best. With this in mind, I would like to make a modest proposal to future standards writing committees: (1) The job of the people actually writing the standard is to concentrate on precision and elegant simplicity, even if this means using the notation of mathematics or symbolic logic. (2) All standards writing committees must have one or more staff members who are technical writers. The staff members' job is to be "intelligent laymen (lay persons? )", to listen to the proceedings, ask questions to help with their own understanding, and to explain and interpret the standards in operational terms to the rest of us (3) All standards will be published as "annotated standards" with the annotations published in alternating blocks of text, perhaps in a different type font. The object of this proposal is that it allows each group of persons to do what it does best and assures that there will be no lag time between the publication of the standard and the publication(s) of interpretations. ______________________________ Forward Header __________________________________ Subject: "Clean Specs" Author: owner-xml-dev@ic.ac.uk_at_INTERNET at X400PO Date: 2/7/99 10:42 AM What is a "clean spec?" People in this discussion are mixing together a variety of things that I do not consider the same. Uche Ogbuji wrote: > I have worked on teams implementing DOM, XSL and parts of XLL. Some users > might grant that we have been "succeeding", but let me assure you that if so, > it is despite the W3C specs, not because of them. DOM, especially is > unforgivably inconsistent, incomplete, and unclear for a production-ready > (1.0) specification. There is not a SINGLE person on this mailing list that would say that it is right to create specifcations that are inconsistent, incomplete or unclear. It is beyond doubt that specifications in the XML family, including XML itself, have these problems. The question is how to avoid that? * some people say that what the spec needs is "more English". But much of the problem with the namespaces specification comes from ambiguity in the English. * some people say that we need "more non-normative text" but once again, it is a non-normative appendix that is confusing people. What almost nobody has suggested is that we need more formal notation. Now if we look at James Clark's "clarifying" document what we see is *less* English text and *more* notation. As David Megginson has pointed out, when a spec. invents a notation to explain its abstract concepts the spec. becomes temporarily harder to read because you have to learn the notation before the specification. This will turn people off. I remember that Algebraic notation turned me off in my first year math classes. But in the *long run* it makes life easier for everyone. Implementors have precise definitions of what the hell they are supposed to implement. End-users get software they can use. People reading the specification for their own education and edification will understand it better -- if they perservere through the task of learning the notation. I know that W3C spec. writers are under pressure to use more normative English and less normative notation. This is not a vote for "clean" specifications. It is a vote for messy, hard-to-implement ones. Where is Dan Connolly when you need him? Let me point out: the CSS and HTML specifications are easy to read because everyone who wants to read them already understands the basic concepts of web pages and layout. They are concrete implementations of ideas we already understand. The same goes for Java. (and yes, I read the Java specification, but AFTER I already knew Java) I wonder if anyone on this list has ever learned a language that was radically different from what they already knew through the language specification: Scheme, Prolog, APL? Technical writing is damn hard. When you do it right, you must make certain decisions about ordering of concepts and revelations that are the exact opposite of what you do in writing a specification. When you write a spec., you need to present things in the order of fundamental building blocks to high level concepts. In technical writing you will put your students to sleep if you zoom in on details before explaining the general framework. I've told people who want to read the DSSSL specification to start at the back and work forwards. Of course once they become implementors then they read it the opposite way around. Life is hard for implementors. I'd rather be forced to implement the entire suite of XML specifcations over HTML/CSS 2. That isn't a slight against HTML/CSS, it's just an attempt to put things in perspective. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Mon Feb 8 15:55:16 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:51 2004 Subject: CORBA's not boring yet. / XML in an OS? References: <4EB4281B.662222A5@darmstadt.gmd.de> <36B9FA0C.11FBFBC@infinet.com> <36BEBEA7.DDB98BFB@darmstadt.gmd.de> Message-ID: <36BF0850.D0E15914@infinet.com> Robb Shecter wrote: > Tyler Baker wrote: > > > I wrote: > > > >...this month's Linux Journal - > > > it describes how -both- up and coming desktop environments are basing > > > major parts of their architectures on CORBA. KDE's so cool it makes me > > > want to learn C++. :) > > > > > Prediction: In 3 years, half the people on this list will be using a > > > corba-based desktop environment. > > > > Not likely. My biggest problem with CORBA was that it was too huge for the client and > > consumed too many resources. > > Actually, I was implying that half of us will be using Linux, and therefore Corba, because it's > now in the desktop environments. I -was- exagerating, but I think it's not extreme to predict > that in 2-3 years Linux (with KDE or GNOME) will have broken out of the hacker-only world, and > onto the desktop. After not using Linux since my college days, I bought I copy of RedHat 5.2 last weekend. I would be using Linux already except that the JDK for Linux (Kaffe) has not been up to speed with Java 2 (that I think is mostly SUN's fault). Kaffe is a great VM and the work that TransVirtual is doing with Java has been very impressive. I am not so sure about your latter statement though. That is more a function of marketing than anything. Linux is a lot easier to install and is a lot easier to use, but it still is not what I would consider "dumb" enough for the masses who use Windows 98 and the IMac. Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon Feb 8 16:01:08 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:08:51 2004 Subject: "Clean Specs" Message-ID: <000001be537c$742ed930$4ff96d8c@NT.JELLIFFE.COM.AU> From: Ronald Bourret <rbourret@ito.tu-darmstadt.de> Tim Bray wrote: >> I think that (namespace) spec is *way* better than the XML spec. I think the XML Spec is pretty good, actually. Tim and the others did a great job. >I've quoted this out of order because I think it is a very important point >and one that has bothered me during this whole discussion. Tim is >absolutely correct here -- the namespaces spec is *way* better than the XML >spec. The first draft-parts of the namespace spec (Appendix A) are lousy. And I think they are incorrect. I am attaching the comment I sent in to the namespace effort (alas too late), in the hope that some people might find it interesting or useful. I would don't want to put it on a public website, because, having had my chance and having had my opinion not taken up, I think it is poor sportsmanship to continue whinging. I pushed hard early on for the PI approach. But I changed my mind for one reason only: the need to support HTML-in-XML and XML-in-HTML. The major application of namespaces may well be embedding things in HTML: the PI option is not realistic for a couple of years. To be honest, I don't think Namespaces would have been acceptable to HTML users with the PI option. The need to support HTML developed as a goal during the namespace discussions, and I consider it the key tradeoff factor. >> This group is notably and vocally dissatisfied with the specs, I >> am watching with attention for concrete suggestions as to how >> to make future specs better - the one premise that seems to get >> consensus, in this group at least, is "more examples I am attaching my comment. Appendix A.2. and A.3 are poor in thought, and close off nice doors that should be kept open. >> Having said all that, people who write specs always have to try to >> do a better job next time, so this recent discourse is very very useful. > >Thanks for listening. I hope this has been helpful. At ISO now, you have to have a user model for who you are writing the spec for. Having a target education and technical background for your readers is a great discipline. Perhaps specs should clearly include at their head a notice stating the intended readers. Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990208/21e122a9/namespacecomment.html From shecter at darmstadt.gmd.de Mon Feb 8 16:11:13 1999 From: shecter at darmstadt.gmd.de (Robb Shecter) Date: Mon Jun 7 17:08:51 2004 Subject: CORBA's not boring yet. / XML in an OS? References: <4EB4281B.662222A5@darmstadt.gmd.de> <36B9FA0C.11FBFBC@infinet.com> <36BEBEA7.DDB98BFB@darmstadt.gmd.de> <36BF0850.D0E15914@infinet.com> Message-ID: <36BF0C18.3B27D6D1@darmstadt.gmd.de> Tyler Baker wrote: > Robb Shecter wrote: > > ... I think it's not extreme to predict > > that in 2-3 years Linux (with KDE or GNOME) will have broken out of the hacker-only world, and > > onto the desktop. > > ... I am not so sure about your latter statement though. That is > more a function of marketing than anything. Linux is a lot easier to install and is a lot easier > to use, but it still is not what I would consider "dumb" enough for the masses who use Windows 98 > and the IMac. > I can see this. I think that the number of "dumb" masses is diminshing, though. There was an -excellent- article a couple of years back in CACM: "The Anti-Mac Interface". The authors' premise was that when the Mac was first made, it was the perfect interface. It was developed for people who had never used a computer before, and who would manage several applications and a few dozen documents. However, that doesn't work anymore for the new generation of computer users: They are growing up with a Nintendo in their hands, and want to use a computer to manipulate dozens of applications, and thousands of documents. In this environment, WYSIWYG breaks down to "what you see is all you get". It essentially sends us back to pre-civilization when, instead of using language, we had to just point with a finger. In this new context, and with KDE getting easier to use, the Linux era will be starting sooner rather than later. I also think that this implies that we shouldn't be afraid to make "complex" solutions. But anyhow, I do share some of your scepticism, and will be -extremely- happy if Linux can go where only Windows and Mac are today. - 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 lauren at sqwest.bc.ca Mon Feb 8 16:14:36 1999 From: lauren at sqwest.bc.ca (Lauren Wood) Date: Mon Jun 7 17:08:51 2004 Subject: "Clean Specs" In-Reply-To: <4.1.19990208091225.00bbbca0@steptwo.com.au> References: <36BDAF1D.A908F8EF@prescod.net> Message-ID: <199902081614.IAA02859@sqwest.bc.ca> On 8 Feb 99, at 9:14, James Robertson wrote: > Well, has anyone considered employing real, professional technical > authors to write the specifications? As chair of the DOM WG, I (and I think the editors of the specs) would be overjoyed were someone to volunteer the services of a real, professional technical author who could help in the process of getting good specs out the door. However, as has been pointed out by others on this list, this support is difficult to find, as W3C seldom has these resources available. Lauren xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Mon Feb 8 16:29:02 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:08:51 2004 Subject: "Clean Specs" References: <01BE5360.62756860@grappa.ito.tu-darmstadt.de> Message-ID: <36BF1055.CBB1D9EF@infinet.com> Ronald Bourret wrote: > Tim Bray wrote: > > > And as regards the namespace spec, I think that some people on this > > list are substantially full of shit, and are wilfully refusing to see > > how simple it is because it does not meet their own design prejudices. > > I think that spec is *way* better than the XML spec. > > I've quoted this out of order because I think it is a very important point > and one that has bothered me during this whole discussion. Tim is > absolutely correct here -- the namespaces spec is *way* better than the XML > spec. There is absolutely no comparison, both from an organization and a > writing (sentence-level) point of view. > > I think there are three other things to remember with respect to the > namespaces spec. First, no matter how you cut them, namespaces turned out > to be far more difficult than any of us could have imagined. We didn't, as > is the case in most programming languages, simply get them for free based > on where we declared our variables -- we had to decorate variables > ourselves. Thus, I think the discussion has often confused frustration > about technology with frustration about spec writing. > > Second, watching a spec evolve is not always the best way to judge how good > it is. Throughout this discussion, I have wondered how I would have felt > about the namespaces spec had I seen it for the first time in its completed > form. No doubt I would have had some confusion, but I also would not have > been carrying pre-conceived notions from one version to the next, which is > where a lot of my confusion about the relation between attributes and > namespaces came from. > > Finally, we have to remember that namespaces appear to work -- I have yet > to hear any examples on this list where they don't. Until such examples > arise, I think we have more to gain by agreeing to use namespaces than by > going off in our own directions. Well, that depends on what you define the word "worK" is. If you define working as being able to run some pregenerated example, then I guess they work. If you define working as being manageable at the application level then "Namespaces in XML" is totally broken. Take for example some of the current DOM implementations, for instance Oracle and SUN's. Both allow you to build a DOM Document from a file using namespaces, but if you want to mutate the DOM tree, you are in a quandary because the node name (which in namespaces parlance is a QName) has no context to resolve the prefix. Furthermore, if you copy a node and insert it somewhere else in the document. The DOM Element and Attr interface would need to have a method such as: void setNodeName(String prefix, String namespace, String localPart) as a hack just to make things barely work. In effect "Namespaces in XML" either makes using the DOM completely useless. In fact, in order for the DOM to be made useful in the presence of "Namespaces in XML" you would have to make a lot of changes that are not backwards compatible with the Level 1 recommendation. This in practical terms would make using the DOM in an XSL Processor pretty much pointless (all XSL Processors I know of other than XT use the DOM as the source tree, and some even use it as the stylesheet tree as well). If you mutate the source tree, then everything is hosed. Beyond the DOM, in application frameworks which have some serialization to XML mechanism for components or whatever, you now will have output with random prefixes which makes XML about as attractive to use as EDI transactions. Just to figure out what the heck you are working with requires hunting the entire document for instances of "xmlns:". Some may shrug this off as "so what" but if someone is using someone else's data and some problem is encountered, manually mapping these prefixes to something tangible like a namespaces is quite a chore. It is almost the same has hunting down memory memory leaks when using languages with pointers. Java does not include pointers for the main purpose of removing memory management from the programmer. "Namespaces in XML" now gives us prefix management or even namespaces management depending on how you look at it. As someone else pointed out earlier, we'll see if anyone "that is end-users and web sites" will ever bother making their lives more difficult by using "Namespaces in XML" for developing web-site content. My odds on bet is everyone will be marching in lock-step to support namespaces, but no one will ever actually use it (kind of like what happened with the "push" and "channels" craze between MS and Netscape in 1996). Tyler xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Mon Feb 8 16:32:15 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:08:51 2004 Subject: Clear specs: suggestions Message-ID: <014101be5380$3ceae960$a5addccf@ix.netcom.com> John wrote: <<(2) Establish editorial-review committees at least at the level of the W3C's four "domains":>> I think we need to distinguish between authors, technical editors, and English editors. Usually a committee is a complete disaster for the last group, and produces the kind of compromised documents that we have been complaining of. Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com CoAuthor: XML applications from Wrox Press, www.wrox.com Author: Using XML on the Web (March) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From f.lindgren at upright.se Mon Feb 8 16:55:20 1999 From: f.lindgren at upright.se (Fredrik Lindgren) Date: Mon Jun 7 17:08:51 2004 Subject: CORBA's not boring yet. / XML in an OS? References: <4EB4281B.662222A5@darmstadt.gmd.de> <36B9FA0C.11FBFBC@infinet.com> <36BEBEA7.DDB98BFB@darmstadt.gmd.de> <36BF0850.D0E15914@infinet.com> <36BF0C18.3B27D6D1@darmstadt.gmd.de> Message-ID: <36BF15A9.AD87CEEB@upright.se> Robb Shecter wrote: > [snip] > > I think that the number of "dumb" masses is diminshing, though. There was an -excellent- article a > couple of years back in CACM: "The Anti-Mac Interface". The authors' premise was that when the Mac > was first made, it was the perfect interface. It was developed for people who had never used a > computer before, and who would manage several applications and a few dozen documents. > The article I guess you are refereing to was written by Don Gentner and Jakob Nielsen and can be found at: http://www.acm.org/cacm/AUG96/antimac.htm It's been a while since I last read it, but I remember liking it. /Fredrik Lindgren Upright Engineering AB. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From avirr at LanMinds.Com Mon Feb 8 16:57:46 1999 From: avirr at LanMinds.Com (Avi Rappoport) Date: Mon Jun 7 17:08:51 2004 Subject: "Clean Specs" In-Reply-To: <3.0.5.32.19990207174048.007c69c0@amati.techno.com> References: <4.1.19990208092325.00c4bc30@steptwo.com.au> <3.0.32.19990207124243.00ba7eb0@pop.intergate.bc.ca> Message-ID: <v04104603b2e4c5fd3f49@[207.33.50.55]> Perhaps in this modern world, some of the rather large fees charged by W3C for membership could go towards hiring some technical writers to address this issue. IMNSHO, the amount of time that we've all spent thrashing about with namespaces is an example of intelligence, time and energy that could have been avoided by a standard that addressed some of the issues better. If standards are the way we'll do business (and I'm all for that!) then why not invest in the best possible standards up front? Just because IETF and other traditions made do without, doesn't mean that we should be penny wise and pound foolish now. Clarity is a net gain for W3C members, and for the larger community, as the cost of incompatible implementations is significant. Avi At 5:40 PM -0600 2/7/99, W. Eliot Kimber wrote: > The XML WG was an all-volunteer project, as are most standards efforts. > Those of us who participated did so primarily as a personal commitment, not > as something our employers (those of us who have them) pay us to do. > > Standards development is not a commercial process--there is no budget from > which technical writers might be hired. The W3C only administers, it does > not fund. Same for ISO. Some national bodies do fund some standards > development (BSI, the British Standards Institute), but that funding will > tend to be used to support the technologists developing the standard and > not writers crafting the words. > > So while it's true that most, if not all, specifications could benefit from > professional writers, it usually isn't an option for standards developers. ________________________________________________________________ Avi Rappoport, Search Tools Maven: <mailto:avirr@lanminds.com> Guide to Site Indexing and Local Search Engines: <http://www.searchtools.com> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Feb 8 17:00:54 1999 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:08:51 2004 Subject: Clear specs: suggestions Message-ID: <3.0.32.19990208115621.007bf2c0@polaris.net> At 11:29 AM 2/8/99 -0500, Frank Boumphrey wrote: >[I] wrote: > ><<(2) Establish editorial-review committees at least at the level of the >W3C's four "domains":>> >I think we need to distinguish between authors, technical editors, and >English editors. That's a good distinction to make. >Usually a committee is a complete disaster for the last group, and produces >the kind of compromised documents that we have been complaining of. "Committee" really wasn't a good word choice. (Sheesh, where's an editor when I need one...?) What I'm thinking of is actually more like a *pool* of individuals for each of the problem domains/activities who could be drawn upon, one for each spec, to clarify and smooth out the rough-hewn bits in the verbiage. Best, JES ============================================================= 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 clark.evans at manhattanproject.com Mon Feb 8 17:24:16 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:51 2004 Subject: Clear specs: Audience References: <014101be5380$3ceae960$a5addccf@ix.netcom.com> Message-ID: <36BF1CC1.5ABA71A8@manhattanproject.com> If it's of any value, I've always seen 4 types of documentation (partitioned by audience): a) Business Process Documentation This type of documentation describes what the business purpose for the system/specification is. This is, essentially, a white paper that introduces the primary ideas in a understandandable way to a general audience. It serves as a good introductory document for newbies. For XML, this type of documentation should describe the goals. What XML is intended to be, and what it is _NOT_ intended to be. b) User Documentation This type of document presents the material in a way that is understandable by a user of the software system / specification. This type of documentation tends to be more of a tutorial guiding the user through actual practice exercises. This documentation usually also has a reference summary. AKA, teach via example. c) System Administration Documentation This type of documentation is aimed at people who administer the usage of the software/spec by a body of people. It is concerned with concurrency, collaboration, maintanence, standards, scaleability, configuration, etc. d) Programmer's Documentation This type of documentation discusses the design of the system and discusses how the/a given implementation would/does work. Assume that this type of reader has a good understanding of formal systems... and leverage the power that comes from formal language. Use predicate logic, pre/post conditions, petri-nets, state transition diagrams, what ever helps. To be nice, footnote the language with a book/url to help the reader get up to speed. Categorically ignore any complaints by "programmers" that can't understand the formal language. By dumbing down this type of documentation you strip away the essence of the field and further lower the quality standards in the industry. -- I have always found that by dividing my documentaion into these four audience categories has _always_ helped a great deal. When you mix the audience for the documentation, you end up with something that is painful to read for all parties. With SGML, you could *even* store everything in a single file, and then extract the parts to create the various documents. I havn't tried this, but I'm theorizing that it would help to improve consistency among the documents... which is always a problem. My $.02, :) Clark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Mon Feb 8 17:47:41 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:08:51 2004 Subject: =?iso-8859-1?Q?an_initial_idea_for_an_XML_=FCberdocument_shell__=28was_Re?= =?iso-8859-1?Q?:_CORBA's_not_boring_yet._/_XML_in_an_OS=3F=29?= Message-ID: <008801be538b$3326e860$0300000a@othniel.cygnus.uwa.edu.au> [Isn't it funny they way you can carry around a crazy idea in your head for ages and then, out of nowhere comes just the discussion to trigger externalisation] AN INITIAL IDEA FOR AN XML ?BERDOCUMENT SHELL What I would like to see initially, is a shell-like application that has an interactive command-line that takes shell-like notions such as a working directory (and the ability to change same), starting of applications, redirecting of input/output to/from files, piping to other application and applies them to an XML ?berdocument. So this "shell" would have the notion of a working element (command 'pwe' (=pwd) will tell you what the working element is). You can change working element with the command 'ce' (=cd) followed by an XPointer. Elements contain XML content *or* they could reference an unparsed entity (for the issue of whether by ENTITY attribute or XLink see below). Some unparsed entities (perhaps with an appropriate NOTATION) are applications that can be "run". Instead of files, these applications work on nodes in the ?berdocument element tree. I imagine that applications would be a lot more modular as most of them would be working on exposed data structures. Rather than a monolithic email/PIM application, you'd have simple applications (applets? no; how about application elements => "applements"). One applement would POP your mail and graft in on to an element in the ?berdocument. Another (perhaps just XT running an XSL stylesheet) would list the subject headings. Another would enable you to read email. An editor applement would let you compose a reply message and then a final applement would send the mail via SMTP. A GUI can come later, but for now, I'd love to see an implementation of what I've just described. In something like Python it should take no time at all to do. <SideBar> Is the ?berdocument a single XML document with multiple entities or more than one XML document? At first I thought that entities would provide the perfect mechanism for an XML ?berdocument to be spread over multiple files. For at least two reasons, I now suspect XLink might be the way to go: 1) you can give the links semantics which might prove to be very useful 2) you avoid the document entity != legal external parsed entity problem I raised in an early post That having been said, it is important to note that the whole point of the "?berdocument" notion is that it is logically treated (perhaps not at the XML parser level but at a level not too higher up) as a single document. Changing working element involves giving an XPointer *not* URI+XPointer. </SideBar> James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Associate Researcher, Electronic Commerce Network Curtin University of Technology, Perth, Western Australia Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Feb 8 17:49:15 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:51 2004 Subject: document vs non-document entity (was Re: CORBA's not boring yet. / XML in an OS?) References: <002101be52be$e92480a0$0300000a@othniel.cygnus.uwa.edu.au> <36BEE1B6.8108B0C9@mecomnet.de> Message-ID: <370CD761.81C6D890@prescod.net> james anderson wrote: > > This raises the question: "What is the extent of an entity binding?" > > Assume that is possible to qualify entity names. Since these qualifications > are already lexically scoped, why would one need to introduce local entity > definitions? The effective entity is already determined by a binding with a > lexical scope. The reason for local definitions is simple. Because of maintenance, visibility and usability concerns it makes sense to have an entity declaration as close as possible to the logical use of that declaration. If a "chapter entity" is to be independently authored then its entity declarations should travel with it. This is MUCH more convenient with local entities. > Opps! Yea, I forgot, there is no way to bind a prefix in the DTD (ie "the > point of definition"). Got to wait for schemas for this. I don't believe that entity declarations have any place in schemas. It seems to me that the identification of resources is a separate issue from the validation of structure. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From spreitze at parc.xerox.com Mon Feb 8 18:04:49 1999 From: spreitze at parc.xerox.com (spreitze@parc.xerox.com) Date: Mon Jun 7 17:08:51 2004 Subject: A New Hope (was Re: Storing Lots of Fiddly Bits (was Re: What is XML for?)) In-Reply-To: ""Rick Jelliffe" <ricko@allette.com.au>'s message of Fri, 5 Feb 1999 08:00:22 PST" Message-ID: <99Feb8.100345pst."834439"@idea.parc.xerox.com> > HyTime lets you label edges too... The > question is, should such labelling be part of the language at the > lexical level (which XML deals with) or a further layer. The nature of XML instances is fairly fixed now; the nature of XML schemas is being designed as we speak. I willing to conceive of an XML schema language that can express schemas against a higher-level data model, plus a mapping of that data model into XML instances. > It is the old > tradeoff that a general purpose system will (probably) be worse at any > specific task than a specific system. I didn't think we were debating whether XML instances or schemas will be general purpose --- of course they will! That's beside the point of what level(s) of abstraction and representation will be addressed by those formalisms. > But Mike's comments do betray a wish that XML operated on > some other level than the strictly lexical: but it doesn't, except by > chance. I think I've heard a number of people use the term "XML" to describe a data model independent of textual expression (and others tell them they're wrong). It's the richness of that data model (and/or its textual expressions) that I'm addressing. We've already lost the battle for XML instances; for schemas, the outcome is as yet undetermined. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Feb 8 18:47:08 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:52 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <19990208104624.A4862@io.mds.rmit.edu.au> Message-ID: <370CE4A4.76D43491@prescod.net> Marcelo Cantos wrote: > > ... [best of both worlds] ... > You get a nice object oriented layer on > top to talk to, and an industrial strength, robust repository > underneath. > > Your comments give me the impression that this is unacceptable to you > in the XML/heirarchical universe. You don't want DOM at any level. > You insist on going straight to objects. It is not even good enough > to build an object layer on top of the DOM layer. I find this a > little implausible and hence am certain that you had something else in > mind. Is it rather that you simply don't care what the underlying API > is, that you are only interested in what happens at the object level? If I had evidence that a bottom-level XML/"DOM" layer would "buy me" an industrial strength, robust repository then I would go for it. As you have pointed out, I can cover up the ugliness with objects. But to me, an industrial strength, robust repository implies sophisticated tree-smart *and* link-smart ad hoc query support. The DOM isn't a query language and doesn't (AFAIK) have a query interface. It might be okay as an API to the results of a query but even there I'm leery... Since trees can be built as a special case of links, I tend to look for such a beast to come out of the OO world (where links are usually primary) instead of the text processing world (where the tree is usually primary). Maybe you guys at rmit.edu can surprise me though. But note that a DOM-on-the-bottom is the opposite of the architecture that I am speaking out against. I'm concerned about people who want to layer the DOM on "top" of things that do not look substantially like XML. In that case you are covering up an optimized, purpose-built abstaction with a homogenized "dumb tree" layer. That's a step backwards. Note that even the DOM creators do not view an XML-DOM as a "universal tree API." That's why there are several variants of the DOM -- for XML, HTML, CSS etc. -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Mon Feb 8 18:55:20 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:08:52 2004 Subject: Fw: "Clean Specs" Message-ID: <002101be5384$04a31e20$5402a8c0@oren.capella.co.il> Tyler Baker <tyler@infinet.com> wrote: >In effect "Namespaces in XML" either makes using the DOM completely useless. In fact, in >order for the DOM to be made useful in the presence of "Namespaces in XML" you would have to >make a lot of changes that are not backwards compatible with the Level 1 recommendation. This >in practical terms would make using the DOM in an XSL Processor pretty much pointless (all XSL >Processors I know of other than XT use the DOM as the source tree, and some even use it as the >stylesheet tree as well). If you mutate the source tree, then everything is hosed. What's wrong with doing the '^' expansion when building the DOM? Names would become context independent, but still unique, using the current interfaces. Then a bit of magic to the output module: (i) keep track of 'xmlns' attributes, and emit names accordingly and (ii) either throw an exception of invent a prefix on the fly if you encounter a namespace which wasn't declared yet. Is re-working the DOM _really_ necessary? I _really_ wish this whole namespace recommendation was specified this way from the start. Have fun, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clark.evans at manhattanproject.com Mon Feb 8 19:10:55 1999 From: clark.evans at manhattanproject.com (Clark Evans) Date: Mon Jun 7 17:08:52 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <19990208104624.A4862@io.mds.rmit.edu.au> <370CE4A4.76D43491@prescod.net> Message-ID: <36BF35E7.D6FF0E5E@manhattanproject.com> Paul Prescod wrote: > But note that a DOM-on-the-bottom is the opposite of the architecture that > I am speaking out against. I'm concerned about people who want to layer > the DOM on "top" of things that do not look substantially like XML. In > that case you are covering up an optimized, purpose-built abstaction with > a homogenized "dumb tree" layer. That's a step backwards. Note that even > the DOM creators do not view an XML-DOM as a "universal tree API." That's > why there are several variants of the DOM -- for XML, HTML, CSS etc. The only time you may want to take this step backwards is if you are providing an generic drill down tool for database navigation... Once you have the primary-key/oid for the object in question, you would most likely want to switch to a smarter, class specific interface. :) Clark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Feb 8 19:25:08 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:08:52 2004 Subject: Storing Lots of Fiddly Bits (was Re: What is XML for?) References: <199902080247.TAA01750@malatesta.local> Message-ID: <370CE837.DB8E5EFC@prescod.net> uche.ogbuji@fourthought.com wrote: > > I hope I'm not mis-representing Paul here, but as I've always read him (and > agreed), his point is that XML, and the various ancillary technologies such as > DOM and XML Schema, are more appropriate for content-exchange than for core > business-object modeling. I agree! > I don't think it makes sense to build a business-object model on top of DOM, > but I do think it makes sense to define an exchange protocol that selializes > objects to XML representations using DOM as a programmatic interface. I agree. I'll point out, however, that it is REALLY EASY to generate XML directly. In your opinion does the DOM actually make it easier? If you use a "reverse SAX" interface (instead of a DOM-building interface) then you could pipe together data consumers and if any of them ever needed a DOM, it could build it. > I think it also makes sense to use the DOM to develop a user-interface layer > for such objects, possibly using the same WDDX or XML-RPC mappings in > association with a set of style-sheets (although this is just one of many > possible mechanisms). Yes, it makes sense to use XML as an "interchange language" between your business objects and your user interface. On the other hand, if that interface is meant to be editable the information loss associated with "dumbing down" to XML may not be acceptable. Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco "Remember, Ginger Rogers did everything that Fred Astaire did, but she did it backwards and in high heels." --Faith Whittlesey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at weblogic.com Mon Feb 8 19:38:54 1999 From: peter at weblogic.com (Peter Seibel) Date: Mon Jun 7 17:08:52 2004 Subject: What Clean Specs Achieve, WAS: Colonialism, SAX, Java, and Namespaces In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D054976@SOHOS002> Message-ID: <19990208194627350.AAA267@ashbury.weblogic.com@lawton> At 09:53 AM 2/6/99 , you wrote: >Bill la Forge wrote: >> One of the big advantages of Java is that a small shop can >> tackle significant projects. With clean specs, the same will >> be true for XML. >> > >Hands up, who has read the Java spec (and that's not the same as reading >the nice clear instructions given to you by the people who wrote the >compiler)? I don't know if that was rhetorical or not, but I have. Language Spec and VM Spec. And I don't develop compilers or VMs for a living -- I'm just a random Java hacker. FWIW, they are quite readable with most of the problems of interpretation coming in places that were tacked on as part of the 1.1 release and not part of the spec proper. I'd encourage would-be spec writers to read the language spec as a example of good spec writing. And I'd encourage developers -- "average" or otherwise -- to read the specs of the technologies they use on a daily basis. -Peter -- Peter Seibel Perl/Java/English Hacker peter@weblogic.com Is Windows98 Y2K compliant? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Mon Feb 8 19:41:26 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:08:52 2004 Subject: When to use attributes vs. elements Message-ID: <5BF896CAFE8DD111812400805F1991F708AAEF4E@RED-MSG-08> Dan Brickley asks several questions in a mail of 1999-02-08 having to do with serializing graphs of data per the "canonical format" recommendations in http://www.w3.org/TandS/QL/QL98/pp/microsoft-serializing.html. Since his mail was lengthy, I have not copied it here. Let me take another stab at explaining the idea. XML has two principal ways to explicitly express a relationship among elements: containment and idrefs. Idrefs always express a directed, labeled relationship between two elements; they always have this meaning and they never have any other meaning. If elements all have ids, and the relationships between the elements in a document are all expressed via idrefs, then the document -- per normal XML rules -- corresponds to a graph in which elements match nodes and attributes match edges. Given this, one can make the suggestion that graphs _should_ be serialized in this way, nodes as elements and edges as idrefs. A reader, knowing no more conventions than the ordinary meaning of idrefs, will observe the correct graph structure. Of course, XML permits a great deal more flexibility than this. One can, for example, take advantage of contextual knowledge and use containment to imply certain kinds of edges. If one does this, then a naive reader will only observe the explicit edges, and will not be able to reconstruct the implied ones. But -- to answer Dan's second question -- this does not mean that a reader needs to have complete knowledge of the implications of the abbreviations employed. Even a naive reader will decode the graph correctly to whatever extent it is explicit, that is, to whatever extent it uses the conventions advocated in the "canonical format." The same point stated differently: If an XML instance uses a different set of conventions, a naive reader will find