From david at megginson.com Wed Sep 1 00:40:52 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:32 2004 Subject: Namespace handling in XML Processors In-Reply-To: <4454C011BDE5D211B6C800609776E54016CCFE@master.design-intelligence.com> References: <4454C011BDE5D211B6C800609776E54016CCFE@master.design-intelligence.com> Message-ID: <14284.22970.976266.372801@localhost.localdomain> Marc.McDonald@Design-Intelligence.com writes: > I did find the use of namespaces an elegant solution to the > backquote problem of Lisp, separating code to assemble a data structure from > the data structure itself. Wow! That's a very interesting analogy. I'm not entirely certain it holds water (I'm a little off analogies this week after my legal-name bogosity), but the LISP programmer in me likes it. By the way, anyone else who actually gets this analogy (i.e. you've touched LISP and haven't run away screaming) should take a look at DSSSL and OpenJade for some of your XML processing needs -- you'll be happier. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 1 00:45:18 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:32 2004 Subject: why distinctions within XHTML? In-Reply-To: <000101bef3ed$12c8c9a0$5199fea9@w21tp> References: <000b01bef3db$fa07dfc0$f3f6b5cf@zippy> <000101bef3ed$12c8c9a0$5199fea9@w21tp> Message-ID: <14284.23128.864289.81427@localhost.localdomain> Don Park writes: > 1. We are diverging into W3C-as-evil-empire topic here. Lets focus > and remain on topic. Agreed. After all, when the W3C screws up, the world just shrugs and ignores it (again, look at http://www.w3.org/TR/#Recommendations and count how many are actually in widespread use). > 2. The scene looks like a gang of rowdy engineers ganging up on one woman. That's hardly how I'd describe Paul Prescod (though he is gentle and soft-spoken when he's not talking about Python). 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 mettlus at yahoo.com Wed Sep 1 00:47:22 1999 From: mettlus at yahoo.com (vishal sharan) Date: Mon Jun 7 17:14:32 2004 Subject: XML Schema!! Message-ID: <19990831225127.6413.rocketmail@send205.yahoomail.com> Hello Everyone! I need help of the Gurus to correct with the schema I have attempted to write in XML. The schema is ------------------------- --------------------------- The XML Doc composed on that basis is ========================================= googoo abracadabra open sesame baboom break on through to the other side =============================================== Please help __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Sep 1 00:52:10 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:32 2004 Subject: Why namespaces? References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <14284.7346.468420.438279@localhost.localdomain> Message-ID: <37C9A9C8.FEAF5F7A@prescod.net> > Who said that they cannot be mixed? The XHTML specification: "Future work by W3C will address ways to specify conformance for documents involving multiple namespaces." > XHTML documents cannot (yet) > contain markup from other Namespaces, but anyone else designing a > document type is free to include HTML markup in theirs (say, for > documentation in a schema). What is the point of referencing a specification if you cannot define conformance? I would say that it is downright a bad idea to "mix in" HTML until there are rules for what is legal or not legal in doing so. Right now, this is perfectly legal: Cheaper by the Dozen

This is also <table>available <a href="http://www.w3.org/">online</a> </table>.... .

I personally don't think that the XHTML specification should even mention the possibility of mixing in without defining contraints or semantics. > In fact, without a global naming scheme, I cannot even reliably answer > the following question for an arbitrary XML document (say, text/xml): > > "Is this an HTML document?" > > The DOCTYPE declaration doesn't help at all here, as Eliot has > repeatedly (and convincingly) pointed out -- DTDs are for > guided-authoring and for validation, not for recognition. It helps to the exactly the same degree that the namespace declaration does. You aren't supposed to use the XHTML doctype on a document that isn't HTML. That can't be checked entirely by any software short of a full HTML validator but that's not the point: it's a societal/legal declaration, not something computer-checkable. That's exactly the same case with namespaces. There is no off-the-shelf software that can check that a document "conforms" to the rules of its namespace (if indeed there are any such rules). Unfortunatley, proper use of either XHTML declaration must be enforced in courts, not software. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Sep 1 01:07:30 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:32 2004 Subject: Who needs XHTML Namespace? References: <14283.53021.904985.100176@localhost.localdomain> Message-ID: <37C9AD73.3CB19C76@prescod.net> David Megginson wrote: > > While we're still a ways away from having schemas that allow > document-type assembly from other schemas, the most important task for > XHTML (other than saying that XHTML should be well-formed XML, which > is a bit of a truisim), is to establish an XHTML Namespace so that > processors can discover HTML markup in arbitrary XML documents. We > don't need Namespace-aware schemas or anything else to do that. What is the virtue in discovering XHTML data in an arbitrary document if there are *no rules* about what that information will look like? Are you really going to write processors that do not care whether images occur within titles or tables within images? XHTML has only two virtues: common semantics and a well-defined grammar. The former are not useful without the latter. You cannot even write a stylesheet without an (explicit or implied) schema. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Sep 1 01:12:12 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:32 2004 Subject: Why namespaces? References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <015401bef3e9$7f939320$4602a8c0@capella.co.il> Message-ID: <37C9AC65.2096A2AB@prescod.net> Oren Ben-Kiki wrote: > > There's so much churn going about distinguishing between three things: > > 1. Unique naming - making sure that one can call "areElementsTheSame(name1, > name2)". > 2. Grammar/Syntax/Structure constraints - "isDocumentValid(rootElement, > DTD)", "addDefaultsToDocument(rootElement, DTD)". > 3. Semantics - doing whatever the application is for. > > I would like to think that the intention was for namespaces to live > exclusively in level 1 (call it "lex"), DTDs/Schemas in level 2 (call it > "yacc"), and level 3 is the application itself. This is maybe simplistic but > I found it to be a great help in figuring out my position on some of the > issues raised in the relevant threads. This three level view is great. It also helps me to figure out my position: but it is the opposite of yours. Going back to lex and yacc: once you have the parse tree you don't care what tokens you used to get there. The application should only look at level 2. It is *level 1* that it should not care about. Therefore I disagree with your next sentence: > In the XHTML multi-namespace issue, > for example, I'd rather the three XHTML variants were defined at level 2 - > possible sets of constraints and defaults for a document, such that the > application (say, the browser) should not in principle have to worry about > which variant was used. First, the browser doesn't care whether the differentiation was made at level 1 or 2. Using your own model, it sees only level 2. Second, note that an XHTML browser *does* need to worry about what variant of HTML was used. The browser must decide which of its implicit stylesheets to apply. Each stylesheet has hard-coded knowledge of content models embedded within it. With HTML this is not a big deal because we have become used to presuming that all HTML will be "loose". In general, as a model, we should adhere to your model strictly: the browser should see only level 2. Level 2 validation should be driven by the unique names in level 1. It would be perfectly legal and useful to make an application that only worked at the "lexical" level. But let's not pretend that that is the norm. It is not. Most applications care about the overall "parse tree" (content models etc.). Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Sep 1 01:22:09 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:32 2004 Subject: Namespace handling in XML Processors In-Reply-To: <37CB7B3E.897B57C0@isogen.com> from "W. Eliot Kimber" at Aug 31, 99 01:50:38 pm Message-ID: <199908312356.TAA21702@locke.ccil.org> W. Eliot Kimber scripsit: > While logically there is no difference between the internal and external > subsets, XML defines slightly different rules for how the internal and > external subsets must be processed. This reflects common (although > misguided, IMNSHO) practice and makes things easier for processors that > don't do validation and therefore don't need to process the > declarations. Even non-validating XML processors need to process at least some of the declarations. In particular, notation and unparsed-entity declarations must be passed to the application, and ATTLIST declarations must be used and understood. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 1 01:25:18 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:32 2004 Subject: Who needs XHTML Namespace? In-Reply-To: <37C9AD73.3CB19C76@prescod.net> References: <14283.53021.904985.100176@localhost.localdomain> <37C9AD73.3CB19C76@prescod.net> Message-ID: <14284.25191.594088.269222@localhost.localdomain> Paul Prescod writes: > What is the virtue in discovering XHTML data in an arbitrary > document if there are *no rules* about what that information will > look like? Are you really going to write processors that do not > care whether images occur within titles or tables within images? Sure -- a search engine is a very good example of one. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Sep 1 01:49:59 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:32 2004 Subject: Who needs XHTML Namespace? References: <14283.53021.904985.100176@localhost.localdomain> <37C9AD73.3CB19C76@prescod.net> Message-ID: <37CC6AB2.BA1A7308@pacbell.net> Paul Prescod wrote: > > David Megginson wrote: > > > > While we're still a ways away from having schemas that allow > > document-type assembly from other schemas, the most important task for > > XHTML (other than saying that XHTML should be well-formed XML, which > > is a bit of a truisim), is to establish an XHTML Namespace so that > > processors can discover HTML markup in arbitrary XML documents. We > > don't need Namespace-aware schemas or anything else to do that. > > What is the virtue in discovering XHTML data in an arbitrary document if > there are *no rules* about what that information will look like? Are you > really going to write processors that do not care whether images occur > within titles or tables within images? Where does "no rules" come from, though? I think the argument is just that the choice of rules has no business being tightly coupled to the element (and attribute) vocabulary being used ... the rules get provided separately, by choice of DTD or schema. We know that in the future composite vocabularies are coming. If each different set of rules gets its own namespace ID, applications have a rather significant combinatoric explosion to suffer through; bad design. Consider a chunk of "strict" XHTML (sans namespaces). It can be validated using any of three DTDs. There's no benefit from doing any early binding of the elements to a "strict" namespace; the next component doing the processing may need to add a frame. That logic extends to other cases. What's the virtue in coupling the semantics of a "p" element to one of the several grammars which discuss its use? If there is one, I've not yet seen it described. On the other side of the argument, not buying into a combinatoric explosion in the number of namespace identifiers seems virtuous to me. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 1 02:03:02 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:32 2004 Subject: How much extra code for multiple Namespaces? In-Reply-To: References: <14283.53548.481057.494235@localhost.localdomain> Message-ID: <14284.26355.567402.660937@localhost.localdomain> schen@falconwing.com writes: > As there is no defined mechanism for namespace processing and it seems > that with xmlns and contained elements "inheriting" namespaces, you would > still need some mechanism to recognize namespaces and it would be folly to > use current non-recognizing parsers anyway. There is no defined mechanism for the processing per se, but there are several models for the result of the processing; see http://www.w3.org/TR/xml-infoset http://www.w3.org/TR/xpath#namespace-nodes http://www.w3.org/TR/xslt#data-model http://www.w3.org/TR/WD-DOM-Level-2/namespaces.html (These are the public versions -- internal, in-progress versions may differ.) While there are significant variations in the details, all of these adhere to a basic model: for every element or attribute name in a document, you are able to obtain at least the following information: 1. The Namespace URI, if any. 2. The local part of the name. Some of these go further, and make available additional information: 3. The original prefix that was mapped to the Namespace URI. 4. The original attributes used for the Namespace declarations. Nevertheless, just 1 and 2 together provide a pretty clear picture of how Namespace processing works. If SAX were being designed now, it would probably have void startElement (String uri, String name, AttributeList atts); void endElement (String uri, String name); etc. If you're working directly in a procedural programming language like Perl or Java, it's fairly straight-forward (if somewhat inefficient) to check for three qualified names instead of one: boolean isAnHTMLNamespace (String uri) { return uri.equals("http://www.w3.org/TR/xhtml1/strict") || uri.equals("http://www.w3.org/TR/xhtml1/transitional") || uri.equals("http://www.w3.org/TR/xhtml1/frameset); } In Java, especially, you might take a hit for doing so, though, if your interface happens to deliver the names in a single string: "{http://www.w3.org/TR/xhtml1/strict}a" Furthermore, there's a deployment problem. If the next version of XHTML also has a different Namespace, then you'll need boolean isAnHTMLNamespace (String uri) { return uri.equals("http://www.w3.org/TR/xhtml1/strict") || uri.equals("http://www.w3.org/TR/xhtml1/transitional") || uri.equals("http://www.w3.org/TR/xhtml1/frameset) || uri.equals("http://www.w3.org/TR/xhtml1.1"); } Some software will have this, and some will still have only the old ones, so the only safe way to work will be to keep using the original XHTML Namespaces forever and ever. Things get even nastier in higher-level languages like template languages or search/query languages, where it's no longer possible to define your own subroutines to factor out the complexity. 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 ejfreed at infocanvas.com Wed Sep 1 02:05:09 1999 From: ejfreed at infocanvas.com (Erik James Freed) Date: Mon Jun 7 17:14:32 2004 Subject: XML Parsers for Java -- Recommendations? In-Reply-To: <020901bef3fc$abacf6a0$ce0c440a@Lepley> Message-ID: <000301bef40e$54cd6920$f3f6b5cf@zippy> Be a little careful with the datachannel parser. After I submitted source code for a few simple but showstopping bugs and was led to believe that fixes would be coming soon, a DC sales person informed me that unless we payed the $5K yearly service agreement, they would not make bug fixes available to me. Of course they are well within their rights to want to charge money, but not only do they price themselves out of the market by a light year, they come off seeming a little shady at least to me (YMMV) I personally am porting off of it to the IBM XML/XSL packages. Which I wish existed when I got started... cheers, erik > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Mike Lepley > Sent: Tuesday, August 31, 1999 3:04 PM > To: xml-dev@ic.ac.uk > Subject: XML Parsers for Java -- Recommendations? > > > I'm going to use an XML parser for my code. I was interested in different > XML to DOM parsers for Java, and wondered if anyone had some > recommendations > / non-recommendations. > > Is there a parser that you couldn't live without? Or how about a parser > that makes you want to kill the programmer? :-) > > Thanks in advance, > 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) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Sep 1 02:25:09 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:32 2004 Subject: Why namespaces? References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <015401bef3e9$7f939320$4602a8c0@capella.co.il> <37C9AC65.2096A2AB@prescod.net> Message-ID: <37CC72EE.9153E4DC@pacbell.net> Paul Prescod wrote: > > Oren Ben-Kiki wrote: > > > > There's so much churn going about distinguishing between three things: > > > > 1. Unique naming - making sure that one can call "areElementsTheSame(name1, > > name2)". > > 2. Grammar/Syntax/Structure constraints - "isDocumentValid(rootElement, > > DTD)", "addDefaultsToDocument(rootElement, DTD)". > > 3. Semantics - doing whatever the application is for. > > > > I would like to think that the intention was for namespaces to live > > exclusively in level 1 (call it "lex"), DTDs/Schemas in level 2 (call it > > "yacc"), and level 3 is the application itself. This is maybe simplistic but > > I found it to be a great help in figuring out my position on some of the > > issues raised in the relevant threads. > > This three level view is great. It also helps me to figure out my > position: but it is the opposite of yours. > > Going back to lex and yacc: once you have the parse tree you don't care > what tokens you used to get there. The application should only look at > level 2. It is *level 1* that it should not care about. Not all applications will be working with parse trees, but I'll accept that model for this discussion. However, I won't accept that level 1 should be a "don't care". Consider an XSL/T pattern match; one certainly needs to know if the element names are the same. And the same applies in a variety of other applications as well: something is actually looking at the elementnames to determine how they get processed. (Where the "names" are tuples with a namespace URI and local part, of course!) > Therefore I disagree with your next sentence: > > > In the XHTML multi-namespace issue, > > for example, I'd rather the three XHTML variants were defined at level 2 - > > possible sets of constraints and defaults for a document, such that the > > application (say, the browser) should not in principle have to worry about > > which variant was used. > > First, the browser doesn't care whether the differentiation was made at > level 1 or 2. Using your own model, it sees only level 2. See above ... I won't speak for Oren, but for me that's clearly wrong. > Second, note that an XHTML browser *does* need to worry about what > variant of HTML was used. The browser must decide which of its implicit > stylesheets to apply. Each stylesheet has hard-coded knowledge of > content models embedded within it. With HTML this is not a big deal > because we have become used to presuming that all HTML will be "loose". Perhaps you could clarify this for me: why would an XHTML content model imply a stylsheet? The need doesn't naturally follow; maybe I missed something in one of the hundreds of earlier messages! Code handling the "frameset" model handles "transitional" and "strict" as simple subsets -- right? > In general, as a model, we should adhere to your model strictly: the > browser should see only level 2. Level 2 validation should be driven by > the unique names in level 1. Now you're bringing validation into this. Browsers validating? Hmm. It's mandatory neither in XML nor in XHTML. I can imagine an editor (not browser!) needing to validate, but that's just a case of testing against a DTD or schema. Normally, validation would be done as part of constructing the parse tree you've assumed. Also, XHTML 1.0 specifies XML's validity -- gotta include a doctype, and validate against it iff you claim to validate. So the unique names don't really matter, it's lowercase HTML vocabulary names (with no namespace stuff necesary). > It would be perfectly legal and useful to make an application that only > worked at the "lexical" level. But let's not pretend that that is the > norm. It is not. Most applications care about the overall "parse tree" > (content models etc.). I really don't see why the parse tree would need to expose content models, particularly in the case of the render-only application you describe. - Dave > Paul Prescod > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mettlus at yahoo.com Wed Sep 1 02:26:22 1999 From: mettlus at yahoo.com (vishal sharan) Date: Mon Jun 7 17:14:32 2004 Subject: Schema!!(XML) Message-ID: <19990901003054.18865.rocketmail@send205.yahoomail.com> Can anyone please help me correcting my xml doc(generated) on the basis of schema described.... =============================================================== microsoft sears macys aol ========================================== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Wed Sep 1 02:42:04 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:32 2004 Subject: Reducing the level of violence - XHTML References: <199908301924.PAA31715@hesketh.net> <4.1.19990830141430.04694f00@mail.webgeek.com> <199908301801.OAA26560@hesketh.net> <4.1.19990830133705.0481b3c0@mail.webgeek.com> <199908301728.NAA24745@hesketh.net> <199908311515.LAA10351@hesketh.net> Message-ID: <37CC763B.5D11@hiwaay.net> Simon St.Laurent wrote: Hi Simon: Looks like everyone over here is having a fun season. > Discussing W3C issues on the XML-dev list seems to produce some remarkable > levels of firepower. Goodness. These look a lot like some discussions on other lists. People are passionate about their tools and their languages. > Simon St.Laurent > XML: A Primer (2nd Ed - September) > Building XML Applications > Inside XML DTDs: Scientific and Technical > Sharing Bandwidth / Cookies I feel as if I need to write a book so I will have something to put in my sig for techCreds. But .... Namespaces looked to me on the surface as the solution to a problem we had in SGML: aggregates. Forever it seems, the world of markup was dominated by extremelyComplicatedDTDs in order to stick it all under a root with inclusions and exclusions to do the nasty bits where the tree just wouldn't be... hierarchical. As an author, I hated these DTDs. As a system implementor, I hated these DTDs. As a DTD designer who did not like to be told at every turn which element types were mine to define and which would be available when the CommitteeOfCompetitors finished their deliberations and published their results six months after their companies implemented them, I HATED THESE DTDs. That is as much violence as I can commit today. From other work that tries to apply XML: 1. They aren't worrying about namespaces. They are worrying about how to get components to work cross-platform. (don't say java. it just starts a different fight.) They thought XML would help with software components. So did I. Wrong? 2. They are criticizing the flatness of XML with respect to datatypes and frankly, wonder what XML buys them if anything. (syntax-unification is not something most grad programmers have accepted since the curly brackets defeated the round brackets and were then challenged by the pointy brackets. Dr Seuss would be so proud.) Ummm.. the datatype spec? Where is it? Should I just go ahead and say, "screw it; let's get back to familiar ground and let Microsoft win"? Seems like the choices aren't mine to make because given the draggggggggggin feet, that is the only good game for meat and potatoes developers, eg, no deep science; just code it test it, field it, mod it. Get the Check. 3. The inability to reconcile the definition of what markup does and doesn't with respect to semantics seems to frustrate almost anyone who ever designed an interoperable system. (don't say framework, it just starts another fight.) We can tell them that semantics are something only applications define and we will be right. That leads them back to #2 and arguments about if the DOM is good for anything when you need real time performance given that they all know how to write a parser. (the desperatePerlHacker is a myth it seems. They aren't desperate. They are contentious.) I was hoping that namespaces would indeed provide the indirection to code, be it classes, perl, or script. Even if only by winking and nudging, it seems appropriate that XML have a means to do what other languages do so easily: use a URL to point to SOMETHING. It seems XML just can't make up its mind what it is good for in that respect. Instead of cleaning up the touted mess of SGML, it seems to be replacing it. OK. The problems really are tougher than admitted. OTOH, no relational programmer has any problem at all creating views which are aggregates from SQL statements that use unambiguous names for table resources. They do consider that OUTPUT and do specify a lot of rules for naming and getting pieces of the recordset. As a result, in this part of my career, building dynamic document databases is trivial. A memo field is a wonderful thing if combined with a standard set of markup object-handlers. I like IE5 with data islands, XSL stylesheets, DOM scripts. Tasty! Hybrid systems are good. Store it in an optimized relational system, schlep out the text into whatever form the next handler wants, then play it. Neat! Neat! More of that! As for the W3C processes, they turned the heat on themselves when they closed discussions to the public. It was inevitable given the origins and myths that surrounded its founders. As the twig is bent. OTOH, I wouldn't be the person on the shortlist of every programmer sociopath or technoTyrant for any amount of fame, glory, or money. Not worth it. So if they have to hunker down to do it, so be it. I agree with the fellow who said, "standards organizations have to be accountable". That is so. The W3C was supposed to be a "technology enabler" and unfortunately, some thought standards were a way to do that. They aren't. Standards are legal contracts. Engineers are lousy lawyers usually and do not understand that manipulating process is nine tenths of a legal practice. The other tenth is an incredibly thick skin and a loving spouse. Last thought: wasn't the USE of namespaces supposed to evolve in the application semantics? IOW, what happened to running code and rough consensus? len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Wed Sep 1 03:23:21 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:32 2004 Subject: Why namespaces? References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> Message-ID: <016a01bef418$41d62be0$0300000a@cygnus.uwa.edu.au> > This raises a major question about the utility of namespaces in a > vocabulary that cannot be mixed with other vocabularies. Exactly. As I suggested on the XML Plenary list, "we would only need separate namespaces for each flavour of XHTML if people are going to want to mix the three flavours in the one document and distinguish the different usages of the element/attributes names in the intersection." James (who's feeling in a one-namespace mood today) -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net Ceci n'est pas une pipe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Wed Sep 1 03:22:38 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:32 2004 Subject: Apples and Oranges Message-ID: <01b701bef419$3ee55810$f9d7f0cf@javadev.cwi.cablew.com> [advance apology for undue familiarity in using the first names of the participants, should you find that offensive.] -----Original Message-----BEGIN From: Ann Navarro Date: Tuesday, August 31, 1999 5:19 PM The Namespaces rec was as controversial then as it is now, and opinions are still widely divided. Ann (personal view) -----Original Message-----END Hello Ann, This begs the question of why W3C would choose to utilize this "controversial" technology (XML-NS) as a building block of XHTML. Your post above doesn't elaborate on _what_ is causing the divergent views in W3C. (Having followed this thread, I think that it is fair to say that many veteran XML-DEV participants have been fairly articulate on why they are not enamored of XML-NS: they think it is broken; I tend to agree.) If I may contribute my views on XHTML: As Orin has effectively pointed out, the XTHML 1.0 spec (which I have read ;) is trying to squeeze 3 logical layers into one (the namespace); and unfortunately, XML-NS is not up to the task. My (perhaps naive) reading of the spec. tells me that there are actually 4 distinct (i.e. orthogonal) logical spaces which need to be mapped in order to achieve the goals of this architecture; i.e. in my opinion, you (W3C) are trying to map a 4 dimensional space with a one dimensional space. (And a flat one at that.) For example, the spec presents the following 3 'types' of XHTML_1.0 document: tS: {(T)ransitional, (S)trict, (F)rameset}. // << {T, S, F} with corresponding dS: {T.dtd, S.dtd, F.dtd}. The problem here is that tS is not a homogenous set: -The relationship between T & S (T<->S) is NOT AT ALL analogous to T<->F, or to S<->F! -Both T<->F & S<->F are morphological relations. F is NOT a subset of either T or F. Rather F is a morphological extension of T and S. (And this is true for all future 'modules' as well.) - T<->S is a _dialectal_ relationship. A completely different relationship. [tS is (somewhat) analogous to, say, {Verse, Prose, Romanticism}.] So while _I agree with you_ that differentiation is just as important as 'commonalities', I also agree with David (& others) that have taken issue with the _strategy_ that you (W3C) have chosen to achieve your goals. This flattening of orthogonal relational spaces into _one_ space will promote ambiguity and _unnecessary_ complexity (whatever its magnitude; +3 or *3) in the processing software. Because in essence, **XHTML 1.0 delegates infrastructural duties to the application layer.** Sure it can be done. The question is why? It lacks clarity which quite likely will diminish its utility. In my opinion W3C should first complete the design of the _foundations_ of ubiquitous information exchange architecture, AND THEN attempt to build lovely structures on top of that foundation. In that spirit, the efforts put in to produce XHTML 1.0 are not in vain: the spec clearly exposes the anemic foundations on which W3C is trying to build this grand edifice. Unless there is a fire out there that XHTML 1.0 (and only XHTML 1.0) can put out, IMO it would be more fruitful for W3C to regroup and nail down the _prerequisite_ technologies first. Given that, I think XHTML (and XMLese objects in general) will (minimally) need robust mechanism which allow a given instance of the object to be mapped to: 1 - A Naming context, // namespace proper, though currently flat 2 - A Revision context, // which is NOT a namespace 3 - A Morphological context, // which is NOT a namespace 4 - A Dialectal context. // which is NOT a namespace Thanks for listening. /Best Regards/ Joubin _____________________________________________________________________ member, alphazero LLC 202.462.1655 dc PS: Bodies which make decisions which affect the collective should be OPEN, given what we know of human nature. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 1 07:07:18 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:14:32 2004 Subject: etymology of "XSDL" Message-ID: <01BA10F0CD20D3119B2400805FD40F9F277CF0@MDYNYCMSX1> Is "XSDL" an official way to refer to the W3C's schema language proposal? The acronym is used a few times in http://www.w3.org/1999/05/06-xsdl/WD-xsdl.dtd, but never spelled out. Can I assume that it stands for "XML Schema Development Language"? It's never used in Part 1 of the Schema proposal itself, and it's only used in Part 2 in Appendix A, which reproduces (as far as I can tell) http://www.w3.org/1999/05/06-xsdl/WD-xsdl.dtd. Where did the acronym come into being--in the working group discussions? thanks, Bob DuCharme www.snee.com/bob "The elements be kind to thee, and make thy spirits all of comfort!" Anthony and Cleopatra, III ii xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Wed Sep 1 13:49:51 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:32 2004 Subject: why distinctions within XHTML? Message-ID: David Brownell wrote: > Mark Birbeck wrote: > > > > 6. There are three variants of HTML 4.0 so we need three variants > > of 'HTML 4.0 as XML' (let's call it XHTML). > > Isn't that assertion pretty core to this debate? That is, it's > not a generally accepted assumption. If you want to write something that transforms current HTML into XML, you need to go via an XML version of HTML. Since there are three versions of HTML, then you need three 'XML versions of HTML'. To me that says nothing about the future direction of XHTML, or what future browsers will do, etc. It just says if you want to manipulate current documents, you have to accept they are in one of three dialects of the same language. > This is the "commonality" argument -- we're striving for common > vocabularies and reuse, broadening markets not restricting them, > making software general purpose (while allowing specialization > in those few cases it's needed). That's good - and I'm sure 'modular' XHTML will address all those issues. But what about dealing with current problems? We need a mark-up for transforming current HTML documents to XML. And when I say this, I don't mean converting: The Thin Red Line 1998 To: The Thin Red Line 1998 That is converting it to an XML version of HTML, but there is no meta-information. I mean converting it to: The Thin Red Line 1998 To do this efficiently is a two-stage process. First 'tidy' the HTML into something that is XML, but still 'looks like' HTML. If possible make it always do the same thing if faced with ambiguities. Then, once in tidyHTML you can parse it into whatever you like. Of course you could write your own messHTML to filmXML converter, and then I could write my own messHTML to addressBookXML converter, and so on. But as you say, we want "reuse" and "commonality". We therefore need two things to be defined by those rogues at W3C: - a tidyHTML - an xmlHTML The first plays the role I have explained above - allowing us to convert legacy HTML into lovely, succulent, marked-up data (that thing that we were all so excited about last week, remember?). The second plays the role of defining a format for future browsers, such that HTML can be validated. This is necessary because the HTML may appear inside other mark-up languages, or may itself contain other mark-up languages. But we need schemas for this. It *cannot* be done with DTDs, since it is very, very difficult to have elements from different namespaces in the same document. A stop-gap today is to embed the documents as you need, but lose validation. If you do this, at least you have the namespace to help you, if you are doing any post-parsing processing. I think that XHTML completely solves the problem of tidyHTML, and it *begins* to look at the issue of xmlHTML. However, the latter will not be complete until modularization comes along. So I think the whole 'how many lines of code must a man walk down' issue is a red herring, because by the time we come to actually do the things that people are suggesting will be a problem, they won't be. Best regards, Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Wed Sep 1 14:13:56 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:32 2004 Subject: Fw: Why namespaces? Message-ID: <002701bef472$69fe5fc0$4602a8c0@capella.co.il> Paul Prescod wrote: > I wrote: > > > > There's so much churn going about distinguishing between three things: > > > > 1. Unique naming - making sure that one can call "areElementsTheSame(name1, > > name2)". > > 2. Grammar/Syntax/Structure constraints - "isDocumentValid(rootElement, > > DTD)", "addDefaultsToDocument(rootElement, DTD)". > > 3. Semantics - doing whatever the application is for. > > > > I would like to think that the intention was for namespaces to live > > exclusively in level 1 (call it "lex"), DTDs/Schemas in level 2 (call it > > "yacc"), and level 3 is the application itself. This is maybe simplistic but > > I found it to be a great help in figuring out my position on some of the > > issues raised in the relevant threads. > > This three level view is great. It also helps me to figure out my > position: but it is the opposite of yours. Aha! An alternative view! Which is, exactly? I'm afraid that the following does not explain it to me: > Going back to lex and yacc: once you have the parse tree you don't care > what tokens you used to get there. The application should only look at > level 2. It is *level 1* that it should not care about. You lost me here. Yes, the output of level two is a complete parse tree - that is, validated with default values expanded, and the application should not (typically) care whether an attribute value came from a default or was explicitly given, which namespace prefix was used for specifying the element, and so on. However, I fail to see how the application can do anything with this parse tree unless it can grab a node and ask it "who are you?". Which means, in effect, it needs to perform the level 1 "areElementsTheSame" call. As David Brownell pointed out, you can't do _anything_ without this capability. Think of an XSLT processor as a sample application. Again, note this is different then what happens when compiling programming languages; this information is typically encoded into the class of the tree node element. When dealing with XML, with don't have this option - a DOM node is a DOM node, period. > Therefore I disagree with your next sentence: > > > In the XHTML multi-namespace issue, > > for example, I'd rather the three XHTML variants were defined at level 2 - > > possible sets of constraints and defaults for a document, such that the > > application (say, the browser) should not in principle have to worry about > > which variant was used. Well, I'm not sure exactly why you disagree - it boils down to not exactly understaing your view, I guess. > First, the browser doesn't care whether the differentiation was made at > level 1 or 2. Using your own model, it sees only level 2. Yes. In my view, the idea is that the difference between the variants is only in validation and default attribute assignment. Once this is done, all three variants are translated into a single "format"/"language"/"set of possible trees in memory", which the browser then processes. > Second, note that an XHTML browser *does* need to worry about what > variant of HTML was used. The browser must decide which of its implicit > stylesheets to apply. Each stylesheet has hard-coded knowledge of > content models embedded within it. With HTML this is not a big deal > because we have become used to presuming that all HTML will be "loose". Which I claim would be simpler/better done by assigning a default "the implicit stylesheet to use is" attribute at level 2. > In general, as a model, we should adhere to your model strictly: the > browser should see only level 2. Level 2 validation should be driven by > the unique names in level 1. Yes. I have a problem in that I agree with all your "high level" statements but reach an opposite conclusion when it comes to concrete features. I find it hard to pinpoint the exact issue we disagree on - is it something to do with the in-memory data model (the DOM)? I admit that I didn't study the DOM interfaces as I should have - I use SAX for all my applications. Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Wed Sep 1 14:37:47 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:32 2004 Subject: Why namespaces? References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <015401bef3e9$7f939320$4602a8c0@capella.co.il> <37C9AC65.2096A2AB@prescod.net> <024201bef44a$2215e4d0$4602a8c0@capella.co.il> <37CD08C5.3D348A7B@prescod.net> Message-ID: <003901bef475$c502f950$4602a8c0@capella.co.il> (We'd better return this to the mailing list - could you forward it there?) > Oren Ben-Kiki wrote: > > > > However, I fail to see how the application can do anything with this parse > > tree unless it can grab a node and ask it "who are you"? Which means, in > > effect, it needs to perform the level 1 "areElementsTheSame" call. As David > > Brownell pointed out, you can't do _anything_ without this capability. Think > > of an XSLT processor as a sample application. > > The important point to note is that to *level two*, htmlstrict:P is not > the same as htmlloose:P. I think this might be the source of our disagreement. I claim it these two are the same; the difference is in the DTD applied to them. > After all, it is level two that takes advantage > of the distinction between the two. Only in that that one document is built according to one DTD and another document is built according to another DTD. It is OK to have multiple DTDs which use elements from the a shared namespace, right? > Therefore how can level 3 go back to > treating them as the same?? It can if _all_ the difference between the variants can be expressed in a DTD or an XSchema. This, IMVHO, should be a design goal of XHTML - bury all the differences between the variants in the DTD, so that the application should stay the same. AFAIK, this was the state of affairs in the previous draft, but that's just hearsay. Concretely: Given an XHTML document, it might be in either LooseDTD or StrictDTD. In both cases, the element would be named "{html-namespace-url}p". However, the default attributes which level two (the XML valiadting parser) assigns to this element would depend on the DTD being used. So would the list of valid sub elements, etc. Once this has been done by level two, level three (e.g. the XSLT processor, or the browser) can ignore the issue. All it knows about is that an element is an "{html-namespace-url}p", that it has a certain set of attributes specified for it, and certain elements contained in it. What it does to this element (e.g., if we are talking about an XSLT processor, which templates match it; if its a browser, how to display it) does not depend on which DTD was used in obtaining the element; it just depends on the values of the attributes and the contained elements. Now, I'm not saying this is the only way to do this, but I'm saying that this is how I would like it to be done for XHTML. What I didn't see is a simple explanation of the alternate view .I appreciate that this is hard to do, as witnessed by me not being able to convey the above in my previous post. > You advocate a layered view but then claim > that layers three and one should have the same idea of "element type > same-ness" and layer two should have a different idea. No; level two is simply making use of DTD specific information. That's its job; to apply the DTD to the document so that the application will not have to worry about DTD related issues, right? For example, the application can trust that the structure of the document follows at least one of the supported DTDs; it doesn't need to know what the DTD specified defaults are - they are given to it as explicit defaults, and so on. Maybe the problem is that you see level two as a non validating parser, where I see a validating parser as an essential part of an XML application? > > Again, note this is different then what happens when compiling programming > > languages; this information is typically encoded into the class of the tree > > node element. WHen dealing with XML, with don't have this option - a DOM > > node is a DOM node, period. > > Actually the DOM isn't relevant. The DOM is an ugly hack. The > Information Set is more relevant. To my shame, I never got around to reading it. But I suspect my claim holds there. It is in the basic nature of XML. 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 paul at prescod.net Wed Sep 1 14:57:58 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:32 2004 Subject: Who needs XHTML Namespace? References: <14283.53021.904985.100176@localhost.localdomain> <37C9AD73.3CB19C76@prescod.net> <14284.25191.594088.269222@localhost.localdomain> Message-ID: <37CD0E78.2A9344EF@prescod.net> David Megginson wrote: > > Paul Prescod writes: > > > What is the virtue in discovering XHTML data in an arbitrary > > document if there are *no rules* about what that information will > > look like? Are you really going to write processors that do not > > care whether images occur within titles or tables within images? > > Sure -- a search engine is a very good example of one. Really? Search engines don't care whether s have images in them? Or whether <h1>'s have <table>'s in them? I'm sure that there are some that don't but I'm equally sure that there are some that do. You didn't address my main point: XHTML mixed with other namespaces is not ready for prime time. There is no definition of conformance for either documents or processors. Until it is ready for prime time namespaces are superflurous. They don't tell you anything you couldn't have got from the DOCTYPE. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Sep 1 14:58:01 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:32 2004 Subject: Why namespaces? In-Reply-To: <016a01bef418$41d62be0$0300000a@cygnus.uwa.edu.au> References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> Message-ID: <199909011300.JAA25393@hesketh.net> At 09:17 AM 9/1/99 +0800, James Tauber wrote: >"we would only need separate namespaces for each flavour of XHTML if people >are going to want to mix the three flavours in the one document and >distinguish the different usages of the element/attributes names in the >intersection." Simple, clean, cuts to the heart of the matter. This explanation focuses on what namespaces are best at doing, without getting caught up in the murk of what namespaces 'might' be used for (or 'mean') in the future, if indeed that ever gets specified. Of course, maybe I'll have some fun by creating documents that mix all three flavors of XHTML... No - don't think so. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 elharo at metalab.unc.edu Wed Sep 1 15:03:13 1999 From: elharo at metalab.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:14:32 2004 Subject: why distinctions within XHTML? In-Reply-To: <4.1.19990831101616.047b8f00@mail.webgeek.com> References: <37CB7F58.4760FB83@pacbell.net> <4.1.19990830113418.047d8550@mail.webgeek.com> <199908301516.LAA18797@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <199908301432.KAA16791@hesketh.net> <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <4.1.19990830120842.047ebb00@mail.webgeek.com> Message-ID: <v03102805b3f2cb6042dc@[168.100.203.234]> >>Ann Navarro wrote: >>> >While there are certainly the large industry players on there, there's lots >of little guys -- and indeed my own constituency (the HTML Writers Guild), >effectively represents 100,000 individual little guys. We're not >"accountable to vendors....". We act on our own behalf, and have the same >power as any other participant. Our Microsoft participant doesn't get his >way any more than anyone else does :) > I don't know how the HTML Writers Guild is structured, but Section 5g of the W3C membership agreement <http://www.w3.org/Consortium/Agreement/Full.html> states: If the Member is itself a consortium, user society, or otherwise has members or sponsors, the rights and privileges granted under this Agreement extend only to the paid employees of the Member, not to its members or sponsors. This essentially excludes many non-profit organizations based around talented volunteers such as WWWAC. In other words, WWWAC can pay our $15,000 for the required 3-year membership. but none of us will actually be allowed to participate since none of us are employees of WWWAC. +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | Java I/O (O'Reilly & Associates, 1999) | | http://metalab.unc.edu/javafaq/books/javaio/ | | http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Sep 1 15:05:26 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:33 2004 Subject: Why namespaces? References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <015401bef3e9$7f939320$4602a8c0@capella.co.il> <37C9AC65.2096A2AB@prescod.net> <37CC72EE.9153E4DC@pacbell.net> Message-ID: <37CD0CD4.5575B8DA@prescod.net> David Brownell wrote: > > > Second, note that an XHTML browser *does* need to worry about what > > variant of HTML was used. The browser must decide which of its implicit > > stylesheets to apply. Each stylesheet has hard-coded knowledge of > > content models embedded within it. With HTML this is not a big deal > > because we have become used to presuming that all HTML will be "loose". > > Perhaps you could clarify this for me: why would an XHTML content > model imply a stylsheet? The need doesn't naturally follow; maybe I > missed something in one of the hundreds of earlier messages! Code > handling the "frameset" model handles "transitional" and "strict" as > simple subsets -- right? But not vice versa. A program written for strict will not work with a frameset or transitional document. If the validation layer sees two things as distinct then any layer built on top of the validation layer should continue to see them as distinct. To me that is a no-brainer. In this case the validation layer sees htmlloose:P and htmlstrict:P as completely different documents. To the validator they are as distinct as Docbook:article and xsl:stylesheet! > > In general, as a model, we should adhere to your model strictly: the > > browser should see only level 2. Level 2 validation should be driven by > > the unique names in level 1. > > Now you're bringing validation into this. That's because validation is vital. It's central to the whole thing. An application author can only write code that assumes the data has been validated and has passed. If you presume that any mix of HTML tags is equally likely to appear in the input then you are back to the legacy HTML tag soup. > Browsers validating? Hmm. > It's mandatory neither in XML nor in XHTML. Whether or not some computer code does the validation is irrelevant. The concept of validity is central to XHTML and to almost every application built on top of it. David Megginson mentioned one of a very few exceptions: a search engine. But the vast majority of applications will make many assumptions about the input data based on the presumption that the input *will be valid*. Without that you have nothing. This is the central point. The namespace specification says that validity is irrelevant and at that level they are right. But at the application level it is NOT irrelevant -- it is the foundation of everything else. Whether the actual validation occurs on the client side or the server side doesn't matter. Whether it was done in code or in someone's head doesn't matter. The whole system depends on the fact that it has been done. Therefore if the validator sees two elements as distinct then the application needs to know that so it can know what input structure it should expect. > I really don't see why the parse tree would need to expose content > models, particularly in the case of the render-only application you > describe. How can you write a stylesheet that makes no assumptions about the structure and hierarchy of the data? It's impossible. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 1 15:43:54 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:33 2004 Subject: Why namespaces? In-Reply-To: <003901bef475$c502f950$4602a8c0@capella.co.il> References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <015401bef3e9$7f939320$4602a8c0@capella.co.il> <37C9AC65.2096A2AB@prescod.net> <024201bef44a$2215e4d0$4602a8c0@capella.co.il> <37CD08C5.3D348A7B@prescod.net> <003901bef475$c502f950$4602a8c0@capella.co.il> Message-ID: <14285.10902.788782.809665@localhost.localdomain> Oren Ben-Kiki writes (quoting Paul Prescod, I think): > > The important point to note is that to *level two*, htmlstrict:P > > is not the same as htmlloose:P. > > I think this might be the source of our disagreement. I claim it > these two are the same; the difference is in the DTD applied to > them. This is the fundamental source of pretty much all of the disagreement on this thread. The problem is that a DTD does (and XML Schemas will do) two entirely different things: a) supply default values and types; and b) specify a set of validation rules. (a) is an essential layer in the interpretation of a document (assuming that the document author takes advantage of it); (b) is simply one of many processes that can be applied to an XML document, and calling it a layer is rather confusing. As far as I know, the three HTML 4.0 variants differ only in (b), not in (a), so the differences are not really an essential part of interpretation -- they affect only one specific type of process, structural validation. Applying a structural schema (DTD or otherwise) to a document should be no different than applying a stylesheet -- in the former case, the output is a truth value, and in the latter, it is some sort of rendition. You can apply many different stylesheets to the same XML document, and likewise, you should be able to apply many different structural schemas to an XML document. This is something that SGML got wrong and XML got right -- SGML assumed that there was always a *single* DTD that applied to any existing document (though that never worked in practice, so we always had to invent kludges for non-trivial systems), so that a document instance could not exist independently of its schema and vice-versa (external DTD subsets are not independent objects in SGML, but simply part of the document that includes them). By allowing documents without explicit DOCTYPE declarations, XML (and, eventually, WebSGML) acknowledged that document instances can exist independently of schemas, and thus, that there can potentially be *many* schemas applied to any existing document. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Wed Sep 1 15:41:19 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:14:33 2004 Subject: Why namespaces? Message-ID: <c=US%a=_%p=Cromwell_Media%l=ODIN-990901134156Z-571@odin.cromwellmedia.co.uk> Paul Prescod wrote, > Therefore if the validator sees two elements as > distinct then the application needs to know that so it > can know what input structure it should expect. Apologies for taking this out of context, but I can't agree with the general point you seem to be making here. I can't see any reason why an *application* couldn't want to treat distinct elements as equivalent for its *application-level* purposes. In those cases an application might well prefer that a lower level validation layer *not* propagate distinctions which are relevant to validation. Maybe all it'd want is a yea or nay on validity (which is enough to guarantee that its getting its expected input structure) and a stream of possibly equivalence- class-munged elements and character data. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 1 16:05:18 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:33 2004 Subject: Required Reading (was Re: Who needs XHTML Namespace?) In-Reply-To: <37CD0E78.2A9344EF@prescod.net> References: <A26F84C9D8EDD111A102006097C4CD0D0E8F29@sohos002.ied-support.net> <14283.53021.904985.100176@localhost.localdomain> <37C9AD73.3CB19C76@prescod.net> <14284.25191.594088.269222@localhost.localdomain> <37CD0E78.2A9344EF@prescod.net> Message-ID: <14285.11787.599045.73085@localhost.localdomain> Paul Prescod writes: > You didn't address my main point: XHTML mixed with other namespaces is > not ready for prime time. There is no definition of conformance for > either documents or processors. Until it is ready for prime time > namespaces are superflurous. They don't tell you anything you couldn't > have got from the DOCTYPE. [etc.] Essentially, Paul and I are arguing two classic positions, both of which are better described in the section "The Rise of Worse is Better" in Richard Gabriel's "LISP: Good News/Bad News/How to Win Big". Paul's position is what Gabriel calls "The MIT approach" and my position is what Gabriel calls "The New Jersey approach". The MIT approach ("the right thing") dominated standards, software, and systems development from the IBM days of the 50's and 60's until the late 80's, and the New Jersey approach ("worse is better") became the clear leader by the mid 1990's when the Internet and the worse-is-better Web so thoroughly trumped the entire computer establishment. Who knows what the next decade will bring? The MIT approach tends (perhaps unfairly) to be associated with waterfall development and with top-down management; the New Jersey approach tends to be associated (again, perhaps unfairly) with incremental development and bottom-up innovation. In any case, it's unlikely that Paul and I will be able to change each-others' minds, so anyone who would like to see what we would have written if we had continued this thread is encouraged to read Gabriel's article; it's one of a tiny handful of paper's that essential reading for anyone working with the Web. 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 oren at capella.co.il Wed Sep 1 16:27:19 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:33 2004 Subject: Why namespaces? References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <015401bef3e9$7f939320$4602a8c0@capella.co.il> <37C9AC65.2096A2AB@prescod.net> <37CC72EE.9153E4DC@pacbell.net> <37CD0CD4.5575B8DA@prescod.net> Message-ID: <000f01bef484$fc45dd10$4602a8c0@capella.co.il> Paul Prescod <paul@prescod.net> wrote: > If the validation layer sees two things as distinct then any layer built > on top of the validation layer should continue to see them as distinct. > To me that is a no-brainer. In this case the validation layer sees > htmlloose:P and htmlstrict:P as completely different documents. To the > validator they are as distinct as Docbook:article and xsl:stylesheet! I think this is the source of our disagreement (I hope it is!), and - obviously - I disagree. The short argument is by example: Consider a C compiler. The parser obviously distinguishes between "a[i]" and "*(a + i)". However, once the parser is done, the rest of the compiler does not. A different longer argument is as follows: I have DTD1 and DTD2 which are identical except for a single default attribute "A" value to a single element "E". In DTD1, it has a default value of "1", in DTD2, it has a default value of "2". I have an application working on top of a validating parser. The application accepts documents in either DTD. Extending this to the full XHTML case is left as an exercise to the reader :-) I have two documents, D1 according to DTD1 and D2 according to DTD2. They are identical except that whenever an "E" element in D1 has a "2" value in attribute "A", the attribute is ommited in the matching "E" element in D2, and vice versa. The validating parser must treat "E" elements in D1 differently then "E" elements in D2; it must attach different default values to the "A" attribute. It follows by your argument that the application must also distinguish between these elements. But the output of the validating parser is _identical_ for the two documents. The application _can't_ make this distinction. Solution 1: the application could query the parser as to whether the attribute is a default one or an explicitly specified one. Accepting this, one should have no objection to using the same XHTML namespace and using three DTDs - because the browser could ask the parser which DTD was used to make whatever distinctions are necessary. So assuming this isn't good enough... Solution 2: It is illegal to write applications which accept more then one DTD. This rules our XSLT processors, browsers, search engines, XML pretty printers, etc. Obviously unacceptable. It is a cope out, anyway; it renders the whole issue of distnguishing between two "things" moot. Solution 3: It is illegal to have two DTDs which contain the same "{namespace}element". Now, you could go this way. Make a 1-1 mapping between namespaces and DTDs. It has its advantages. If we go this way, some things would be simpler. For example, the namespace URL could be that for the DTD, and so on. I personally don't like this, and the current W3C recommendations take great care not to imply this conclusion. So, we are left with: Solution 4: Give up on this requirement. It _is_ possible for the validating parser to make distinctions which are invisible to the application. Now, what is so bad about that? After all, why _should_ the application care? Solution 5: None that I can think of at the moment, but maybe you can? <WildSpeculation> BTW, while writing this, I hit upon a notion on why the W3C XHTML WG would specify three namespaces into XHTML. (Second guessing comitees is a fun game :-) Assume that they don't want to make a decision wrt. solution 3. This is reasonable; it isn't their mandate, after all - they are concerned with XHTML, not namespaces and DTDs. If they forced the issue, they would suffer justified critisism from whoever holds the opposing view. So, if they release XHTML with one namespace, they are forcing the issue. You'd have to specify multiple DTDs for a single namespace. Oops. But, if they specify three namespaces, they avoid the issue. Whetever is decided in the future, they are safe. All very reasonable up to a point. But this is wrong. It means that until this is decided, we'll see a proliferation of namespaces invented just to avoid this decision. It would then cause momentum in favor of accepting solution 3 - all these multi-namespace recommendations would look pretty bad if it was rejected. And implementations would probably be built making this assumptions in some level. So, this is imply another way of forcing the issue. I wouldn't have minded much if it didn't force it in the wrong direction :-) How about someone simply making a decision on this? If not the XHTML WG, then some other one? And _soon_, so we could start adjusting to whatever the decision is, instead of thinking up convoluted ways to avoid making it? </WildSpeculation> 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 ann at webgeek.com Wed Sep 1 16:30:13 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:33 2004 Subject: Why namespaces? In-Reply-To: <016a01bef418$41d62be0$0300000a@cygnus.uwa.edu.au> References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98> Message-ID: <4.1.19990901102902.042d8530@mail.webgeek.com> At 09:17 AM 9/1/99 +0800, James Tauber wrote: >Exactly. As I suggested on the XML Plenary list, > >"we would only need separate namespaces for each flavour of XHTML if people >are going to want to mix the three flavours in the one document and >distinguish the different usages of the element/attributes names in the >intersection." I admit to not having seen this argument on Plenary, but it's probably one of the more cogent arguments I've seen on the topic (rather than the more ethereal "you're ruining everything!" :) ) Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Wed Sep 1 16:30:31 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:33 2004 Subject: why distinctions within XHTML? Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFE28@cc20exch2.mobility.com> > From: Mark Birbeck [mailto:Mark.Birbeck@iedigital.net] > David Brownell wrote: > > Mark Birbeck wrote: > > > > > > 6. There are three variants of HTML 4.0 so we need three variants > > > of 'HTML 4.0 as XML' (let's call it XHTML). > > > > Isn't that assertion pretty core to this debate? That is, it's > > not a generally accepted assumption. > > If you want to write something that transforms current HTML into XML, > you need to go via an XML version of HTML. Since there are three > versions of HTML, then you need three 'XML versions of HTML'. > To me that > says nothing about the future direction of XHTML, or what future > browsers will do, etc. It just says if you want to manipulate current > documents, you have to accept they are in one of three dialects of the > same language. <?email snip?> > That's good - and I'm sure 'modular' XHTML will address all those > issues. But what about dealing with current problems? We need > a mark-up > for transforming current HTML documents to XML. And when I say this, I > don't mean converting: > > <TD ALIGN=LEFT>The Thin Red Line <B>1998</td> > > To: > > <TD ALIGN="LEFT">The Thin Red Line <B>1998</B></TD> > > That is converting it to an XML version of HTML, but there is no > meta-information. I mean converting it to: > > <Film> > <Title>The Thin Red Line > 1998 > > I think this post is slightly off topic, for talking about XHTML. The debate here is: a) Although there are currently three flavours of HTML 4, *should* those three flavours also be mapped into three flavours of XHTML 1, or *should* we strive for one flavour? b) *If* we *should* use three flavours of XHTML, is namespaces the way to do it? What you're describing above is not XHTML, but is some other XML vocabulary. (That is, there is no tag.) If you want to convert the HTML above to some other XML vocabulary, go ahead. There is nothing stopping you from doing that today. But if we want to convert that HTML above to XHTML, with XHTML's defined set of tags, *then* you have to worry about whether XHTML should be using three namespaces or not. Even if you want to take your other XML vocabulary and display it directly in a browser you can do that; CSS can do that today. But it still isn't XHTML. David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From als2000 at postmaster.co.uk Wed Sep 1 16:43:14 1999 From: als2000 at postmaster.co.uk (Alastair Sumner) Date: Mon Jun 7 17:14:33 2004 Subject: XML parser using lex & yacc Message-ID: I want to develop an XML parser in C or maybe C++ for an undergraduate university project. My approach will be to prototype the parser using flex and bison. As I understand it, flex won't be able to handle all of the character encodings required in the the 1.0 spec. Therefore my approach will then be to rewrite the lexer by hand to support the different character encodings. Has anyone taken a similar approach? Is it feasible? Also, is the XML EBNF an LR grammar so that yacc/bison can handle it? Cheers Alastair Sumner xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 1 16:54:04 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:33 2004 Subject: Why namespaces? In-Reply-To: <000f01bef484$fc45dd10$4602a8c0@capella.co.il> References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <015401bef3e9$7f939320$4602a8c0@capella.co.il> <37C9AC65.2096A2AB@prescod.net> <37CC72EE.9153E4DC@pacbell.net> <37CD0CD4.5575B8DA@prescod.net> Message-ID: <199909011456.KAA30296@hesketh.net> At 04:19 PM 9/1/99 +0200, Oren Ben-Kiki wrote: >Paul Prescod wrote: >> If the validation layer sees two things as distinct then any layer built >> on top of the validation layer should continue to see them as distinct. >> To me that is a no-brainer. In this case the validation layer sees >> htmlloose:P and htmlstrict:P as completely different documents. To the >> validator they are as distinct as Docbook:article and xsl:stylesheet! > >I think this is the source of our disagreement (I hope it is!), and - >obviously - I disagree. Oren goes on to make some excellent points about the relationships between parsers, DTDs, and namespaces. The general problem seems to me to be that XML (and namespaces as well) were written without a clear processing model in mind. XML is a big ol' block of rules, with no real suggestion of how those rules might be broken down into smaller parts. The distinction between well-formed and validating parsers doesn't really create a 'validation' module with well-defined functions, and when you throw in the other things that can happen during XML processing - attribute defaulting, entity expansions, etc. - it's pretty difficult to see where one set of functions ends and another begins. Add namespaces to that large block, and the potential complexity grows exponentially. (2 specs -> 4x complexity). It isn't clear how namespaces is supposed to fit with the rest of what we already have - all that's clear is what namespaces do: provide unique identifiers. The rest of it remains completely up in the air. While I'm looking forward to the Infoset WG defining lots of these parts, I'm not sure they'll be able to get us out of the woods on these kinds of issues where how XML is processed is just as important as what it contains. Frustrating, to say the least. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 oren at capella.co.il Wed Sep 1 17:04:12 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:33 2004 Subject: Why namespaces? References: <4.1.19990830100716.0479f220@mail.webgeek.com><027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au><199908301432.KAA16791@hesketh.net><4.1.19990830105549.047d0840@mail.webgeek.com><14282.40586.795647.930495@localhost.localdomain><37C95E98.D5E54957@prescod.net><015401bef3e9$7f939320$4602a8c0@capella.co.il><37C9AC65.2096A2AB@prescod.net><024201bef44a$2215e4d0$4602a8c0@capella.co.il><37CD08C5.3D348A7B@prescod.net><003901bef475$c502f950$4602a8c0@capella.co.il> <14285.10902.788782.809665@localhost.localdomain> Message-ID: <004401bef48a$37d431b0$4602a8c0@capella.co.il> David Megginson wrote: >... The problem is that a DTD does (and XML Schemas will > do) two entirely different things: > > a) supply default values and types; and > b) specify a set of validation rules. > > (a) is an essential layer in the interpretation of a document > (assuming that the document author takes advantage of it); (b) is > simply one of many processes that can be applied to an XML document, > and calling it a layer is rather confusing. Is there's no practical way to specify them separately? For example, suppose that it was possible to use some form of PIs embedded in the document to specify (a), while keeping (b) in a separate DTD document. > As far as I know, the three HTML 4.0 variants differ only in (b), not > in (a), so the differences are not really an essential part of > interpretation -- they affect only one specific type of process, > structural validation. ?!%!%$# If that's true, then why on earth would one even consider using three separate namespaces, instead of just three alternate DTDs? I thought the problem was that all sort of defaults were different in each variant (even if these defaults boil down to "which stylesheet to use"). Otherwise, what's the point? > This is something that SGML got wrong and XML got right -- SGML > assumed that there was always a *single* DTD that applied to any > existing document (though that never worked in practice, so we always > had to invent kludges for non-trivial systems), so that a document > instance could not exist independently of its schema and vice-versa > (external DTD subsets are not independent objects in SGML, but simply > part of the document that includes them). > > By allowing documents without explicit DOCTYPE declarations, XML (and, > eventually, WebSGML) acknowledged that document instances can exist > independently of schemas, and thus, that there can potentially be > *many* schemas applied to any existing document. Doesn't this contradict (a)? That is, must all these schemas agree on the default values? Or is it intentional that you can replace the default values as well? 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 Mark.Birbeck at iedigital.net Wed Sep 1 17:18:01 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:33 2004 Subject: why distinctions within XHTML? Message-ID: It's exactly on topic!! I am arguing that one of the main uses for XHTML *today* is as an intermediary between old HTML and squeaky-clean new XML. That's why we need three variants - because there's three (ish) HTMLs. If you want to validate you have three DTDs to choose from, and if you want to mix document types you have three namespaces to help you. What you can't do is validate the mixed documents - but then who can ... yet? Mark > -----Original Message----- > From: Hunter, David [mailto:dhunter@Mobility.com] > Sent: 01 September 1999 15:30 > To: XML-Dev Mailing list > Subject: RE: why distinctions within XHTML? > > > > From: Mark Birbeck [mailto:Mark.Birbeck@iedigital.net] > > David Brownell wrote: > > > Mark Birbeck wrote: > > > > > > > > 6. There are three variants of HTML 4.0 so we need > three variants > > > > of 'HTML 4.0 as XML' (let's call it XHTML). > > > > > > Isn't that assertion pretty core to this debate? That is, it's > > > not a generally accepted assumption. > > > > If you want to write something that transforms current HTML > into XML, > > you need to go via an XML version of HTML. Since there are three > > versions of HTML, then you need three 'XML versions of HTML'. > > To me that > > says nothing about the future direction of XHTML, or what future > > browsers will do, etc. It just says if you want to > manipulate current > > documents, you have to accept they are in one of three > dialects of the > > same language. > > > > > That's good - and I'm sure 'modular' XHTML will address all those > > issues. But what about dealing with current problems? We need > > a mark-up > > for transforming current HTML documents to XML. And when I > say this, I > > don't mean converting: > > > > The Thin Red Line 1998 > > > > To: > > > > The Thin Red Line 1998 > > > > That is converting it to an XML version of HTML, but there is no > > meta-information. I mean converting it to: > > > > > > The Thin Red Line > > 1998 > > > > > > > > I think this post is slightly off topic, for talking about XHTML. The > debate here is: > > a) Although there are currently three flavours of HTML 4, > *should* those > three flavours also be mapped into three flavours of XHTML 1, > or *should* we > strive for one flavour? > > b) *If* we *should* use three flavours of XHTML, is > namespaces the way to > do it? > > What you're describing above is not XHTML, but is some other > XML vocabulary. > (That is, there is no tag.) If you want to > convert the HTML > above to some other XML vocabulary, go ahead. There is > nothing stopping you > from doing that today. But if we want to convert that HTML > above to XHTML, > with XHTML's defined set of tags, *then* you have to worry > about whether > XHTML should be using three namespaces or not. > > Even if you want to take your other XML vocabulary and > display it directly > in a browser you can do that; CSS can do that today. But it > still isn't > XHTML. > > David Hunter > david.hunter@mediaserv.com > MediaServ Information Architects > http://www.MediaServ.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From yiminz at timberline.com Wed Sep 1 17:14:36 1999 From: yiminz at timberline.com (yimin zhu) Date: Mon Jun 7 17:14:33 2004 Subject: canonical form Message-ID: <2D722CFF0999D111AB860001FA375F1002FB7141@laposte.timberline.com> While mapping graphs, say UML models into XML-data schema, what will happen if I do not use "canonical form"? I mean entity properties are mapped to subelements rather than attributes? Does anyone ran into the same problem before? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 1 17:39:36 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:33 2004 Subject: Why namespaces? Message-ID: Simon St.Laurent wrote: > At 09:17 AM 9/1/99 +0800, James Tauber wrote: > >"we would only need separate namespaces for each flavour of > > XHTML if people are going to want to mix the three flavours > > in the one document and distinguish the different usages > > of the element/attributes names in the intersection." > > Simple, clean, cuts to the heart of the matter. 'fraid I don't agree. For the *legacy* HTML you may still need to distinguish where it came from when it is being processed as XHTML. You might have a MathML document that contains an element that can contain some XHTML, but the source of that XHTML could be any of the three variants of HTML. Or you might want to convert data in a table in an HTML 4.0 strict document to one XML tag, and data in a table in an HTML 4.0 transitional document to another XML element, but treat the rest of the tags the same, *and* only write one XSL stylesheet. Obviously when everything has been tidied up, and modules of XHTML are being used, then you will only need the namespaces for the modules you want to use, and there will be no need for three. Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Wed Sep 1 17:45:01 1999 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:14:33 2004 Subject: XML parser using lex & yacc In-Reply-To: Alastair Sumner's message of Wed, 01 Sep 1999 15:45:37 +0100 Message-ID: <4801.199909011547@doyle.cogsci.ed.ac.uk> > I want to develop an XML parser in C or maybe C++ for an > undergraduate university project. My approach will be to prototype > the parser using flex and bison. As I understand it, flex won't be > able to handle all of the character encodings required in the the > 1.0 spec. Using your own lexer may be the best approach, but all the "syntax characters" of XML are plain ASCII, so it might well be possible to use [f]lex to tokenise it. For UTF-8 it is straightforward: the lexer doesn't have to even know that the multibyte-characters are not just multiple characters - the next level up can translate them. Or you might be able to replace the lexer's input functions and change its character type to integer (if it isn't already); this would work for UTF-16 (the other required encoding) too. The most obvious problem with using yacc/lex type tools for XML is that keywords aren't always keywords. For example, in some places in the DTD "SYSTEM" is a keyword and in others it would just be a name. You can have the parser switch the lexer between states but it's not pretty. -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david.power at fms.ie Wed Sep 1 17:46:22 1999 From: david.power at fms.ie (David Power) Date: Mon Jun 7 17:14:33 2004 Subject: No subject Message-ID: <199909011552.QAA16909@tribble.medianet.ie> Please remove my E-mail address in subscription list. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Wed Sep 1 18:17:09 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:34 2004 Subject: why distinctions within XHTML? Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFE2F@cc20exch2.mobility.com> But it's not. The purpose of XHTML today and tomorrow is the same as the purpose of HTML was yesterday and today: to convey information to a human. Period. (Usually visually, i.e. in a browser.) That has nothing to do with transforming HTML to another XML vocabulary, as in your previous email. It doesn't really even have anything to do with transforming other XML vocabularies into XHTML, although you can, since XHTML is a vocabulary of XML. It *does* have to do with changing our ways, at some point, and writing XHTML instead of HTML. XHTML is not an "intermediary", until we're ready to write everything in another XML vocabulary. When we're talking about displaying information to a human, XHTML is the *destination*. Or rather, XHTML is *a* destination; as I said before, XML in other vocabularies can also be presented to a human, using CSS or other technologies. The idea here isn't that we develop XHTML as a stop-gap solution, to be eventually replaced. XHTML is supposed to be a standard XML vocabulary that people can use from this point on, whenever they want something to be presented to a human. Just like MathML is a standard vocabulary that people can use from this point on whenever they have information of a mathematical nature [he said, having never even looked at MathML...]. Which is why the important issue of "should we use three namespaces, or one namespace, or many namespaces, or no namespaces" should be settled now. If this vocabulary is going to take off, we should try to eliminate the mistakes in it. (If any.) David -----Original Message----- From: Mark Birbeck [mailto:Mark.Birbeck@iedigital.net] Sent: Wednesday, September 01, 1999 11:24 AM It's exactly on topic!! I am arguing that one of the main uses for XHTML *today* is as an intermediary between old HTML and squeaky-clean new XML. That's why we need three variants - because there's three (ish) HTMLs. If you want to validate you have three DTDs to choose from, and if you want to mix document types you have three namespaces to help you. What you can't do is validate the mixed documents - but then who can ... yet? Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Wed Sep 1 18:32:20 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:34 2004 Subject: XHTML & Schemas Message-ID: <37CD441A.1FF39F6E@prescod.net> Let me try to put this argument on a practical footing. Namespaces are triggers for various things. Stylesheets, validators, etc. For better or worse XHTML has three different grammars. I could probably be convinced that this is a bad idea (and on another day might even argue vociferously that way). But anyhow, XHTML has three grammars. This probably has more to do with politics than technology: "our mandate is to blah blah blah". That means that when we get namespace-aware validators there will be three schemas. Schemas are namespace-triggered: * not "version attribute" triggered * not DOCTYPE triggered They are namespace triggered. (and for good reason...trying to bring attributes into it makes the validation model much more complicated) It follows that we need three namespaces to attach the three grammars to. Next year we will want to introduce parts of XHTML into our various other document types. By that time we will hopefully have a schema language that allows us to validate "HTML islands." Great! But which grammar do we validate against? With only one namespace we either have no choice or we must use the most loose of the three. Now as a purist I don't think that it should be possible to use the XHTML namespace until the W3C describes what conformance means. So I would vote to do away with the namespaces altogether until that time comes around. But given that this is not politically feasible I think that the current status of three namespaces makes sense as a required hook for future schema-based validation. The alternative is to let "loose" become the defacto standard! Ack. Better that we should either (temporarily) banish namespaces, banish "loose" or make three namespaces so that we do not paint ourselves into a corner. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at goon.stg.brown.edu Wed Sep 1 18:33:18 1999 From: richard at goon.stg.brown.edu (Richard L. Goerwitz) Date: Mon Jun 7 17:14:34 2004 Subject: XML parser using lex & yacc References: <4801.199909011547@doyle.cogsci.ed.ac.uk> Message-ID: <37CD55D9.36EBF3AA@goon.stg.brown.edu> This note is only for people really interested in low-level parser im- plementation details; others, please ignore. Richard Tobin wrote: > > > I want to develop an XML parser in C or maybe C++ for an > > undergraduate university project. My approach will be to prototype > > the parser using flex and bison. > Using your own lexer may be the best approach Probably not for an undergraduate project. Too error prone and time consuming, I'd wager. And in fact, if XML had to be approached this way I'd say that it was fundamentally mis-designed. It would be a very bad mistake to design a modern markup language this way. I don't know if the XML designers though about these issues, but it is possible, with a few kludges, to parse it with Flex and Bison. > Or you might be able to replace the lexer's input functions and change > its character type to integer (if it isn't already); this would work > for UTF-16 (the other required encoding) too. Get the flex source at prep.ai.mit.edu (/pub/gnu/flex or whatever) and patch the source with James Lauth's Unicode patches: ftp://ftp.lauton .com/pub/flex-2.5.4-unicode-patch.tar.gz. Override the default Flex input routine with one that checks the file format (all it has to do is parse the first few chars of the XML decl as per the relevant appendix to the XML spec, then read the entire XML decl for an encoding decl; you then rewind the file, store the file's format and other important information in a lookup table, then use that lookup table when reading in characters to determine what translation to use for that file; convert everything to UCS-4, or perhaps UTF-16, internally, so the above Flex patches will work; only need to do the format check once for every file, since thereafter the lookup table may be consulted). > The most obvious problem with using yacc/lex type tools for XML is > that keywords aren't always keywords. For example, in some places > in the DTD "SYSTEM" is a keyword and in others it would just be > a name. Just make sure that all your keywords can be both keywords and Name sequences (you'll see what I mean when you read the spec). Then write your syntax rules so that wherever you need an Nmtoken sequence in the parser it will accept a Name or a Nmtoken sequence (this can easily be accomplished by having a rule, NameOrNmtoken : Name | Nmtoken, and by then using NameOrNmtoken wherever you'd be inclined to use Nmtoken). You'll see what I mean once you start writing the parser. Would have been a lot easier if XML had introduced the notion of re- served words. Would also have been easier if the XML spec had aban- doned the notion of whitespace as a grammatically significant token inside of markup. Inside markup it should essentially be ignored at the parser's (as opposed to lexer's) level. It's the way virtually all modern languages are designed. And I gather (Handbook, 65 [371:16]) that it's largely how SGML should work as well. -- 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 1 18:40:50 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:34 2004 Subject: Schema problems In-Reply-To: <004401bef48a$37d431b0$4602a8c0@capella.co.il> References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <015401bef3e9$7f939320$4602a8c0@capella.co.il> <37C9AC65.2096A2AB@prescod.net> <024201bef44a$2215e4d0$4602a8c0@capella.co.il> <37CD08C5.3D348A7B@prescod.net> <003901bef475$c502f950$4602a8c0@capella.co.il> <14285.10902.788782.809665@localhost.localdomain> <004401bef48a$37d431b0$4602a8c0@capella.co.il> Message-ID: <14285.21833.48890.49301@localhost.localdomain> Oren Ben-Kiki writes: > > By allowing documents without explicit DOCTYPE declarations, XML (and, > > eventually, WebSGML) acknowledged that document instances can exist > > independently of schemas, and thus, that there can potentially be > > *many* schemas applied to any existing document. > > Doesn't this contradict (a)? That is, must all these schemas agree > on the default values? Or is it intentional that you can replace > the default values as well? That's a very messy question. Personally, I'd be happy to accept a schema spec that *didn't* specify default values. I don't think that most client-side XML is going to use schemas, whatever standard emerges, because schemas introduce non-constant-time problems and (with default values) security issues into the equation. Non-constant-time ----------------- A schema is a separate resource that may reference other schemas recursively, so I cannot safely predict how much parser (and, more seriously, how much network activity) will be required to process a document. Security -------- If schemas contain default values, those default values might compromise the security of my document (say, by providing a default value of 'public' for an 'access' variable that was unspecified in the original document). Again, since schemas can reference other schemas, they're only as secure as the entire tree -- for example, if the schema refers to another at the w3.org Web site, and someone cracks w3.org, they've effectively cracked my schema (and my document) 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 david-b at pacbell.net Wed Sep 1 18:47:58 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:34 2004 Subject: Why namespaces? References: <4.1.19990830100716.0479f220@mail.webgeek.com> <027701bef28d$1d59fda0$0300000a@cygnus.uwa.edu.au> <199908301432.KAA16791@hesketh.net> <4.1.19990830105549.047d0840@mail.webgeek.com> <14282.40586.795647.930495@localhost.localdomain> <37C95E98.D5E54957@prescod.net> <015401bef3e9$7f939320$4602a8c0@capella.co.il> <37C9AC65.2096A2AB@prescod.net> <37CC72EE.9153E4DC@pacbell.net> <37CD0CD4.5575B8DA@prescod.net> Message-ID: <37CD593F.885234E@pacbell.net> Paul Prescod wrote: > > David Brownell wrote: > > > > > Second, note that an XHTML browser *does* need to worry about what > > > variant of HTML was used. The browser must decide which of its implicit > > > stylesheets to apply. Each stylesheet has hard-coded knowledge of > > > content models embedded within it. With HTML this is not a big deal > > > because we have become used to presuming that all HTML will be "loose". > > > > Perhaps you could clarify this for me: why would an XHTML content > > model imply a stylsheet? The need doesn't naturally follow; maybe I > > missed something in one of the hundreds of earlier messages! Code > > handling the "frameset" model handles "transitional" and "strict" as > > simple subsets -- right? > > But not vice versa. A program written for strict will not work with a > frameset or transitional document. There's a notion lurking here that I've not heard before. Namely that this artifact (too many namespace URIs :-) may be a nudge to actively discourage people from writing software that handles any part of XHTML other than the "strict" bits. Otherwise, people would normally do what they do now: build software that accepts the whole "frameset" package. After all, most HTML out there is close to that ruleset ... it's got frames, HTML-3.2isms, and so on. It's the "strict" HTML-4.0isms (thead, tbody, etc) that have negligible real-world support. (Yes, the need for everyone to _speculate_ about why the heck the W3C suddenly did a volte-face on this issue is galling. You'd really expect that such a change would have a visible rationale.) > If the validation layer sees two things as distinct then any layer built > on top of the validation layer should continue to see them as distinct. > To me that is a no-brainer. In this case the validation layer sees > htmlloose:P and htmlstrict:P as completely different documents. To the > validator they are as distinct as Docbook:article and xsl:stylesheet! I think other people disagreed with this too. The XML 1.0 spec says that validation only causes reporting of "validity" errors, and does not (to my reading) imply any "seeing as distinct". (That gets into those discussions of identity again -- let's avoid learning how fine it's possible to slice distinctions ... ;-) So, to me it's a no-brainer that validation is only a pass/fail, and is otherwise invisible. If I have some markup that follows the HTML "strict" rules, it validates against all three DTDs ... it really doesn't matter which one the application thinks was used. It passes validation by all three rulesets, and that's all that matters. > > > In general, as a model, we should adhere to your model strictly: the > > > browser should see only level 2. Level 2 validation should be driven by > > > the unique names in level 1. > > > > Now you're bringing validation into this. > > That's because validation is vital. It's central to the whole thing. An > application author can only write code that assumes the data has been > validated and has passed. If you presume that any mix of HTML tags is > equally likely to appear in the input then you are back to the legacy > HTML tag soup. I didn't assume "tag soup" at all -- I was commenting on the way you were bringing in the notion, namely assuming clients did it. Which appears not to have been what you intended to imply. To the extent that I assumed anything, it was what we know from the (X)HTML specification: everything at least conforms to the "frameset" rules. That's a clearly defined set of rules, and many applications know how to deal with it. > Therefore if the validator sees two elements as distinct then the > application needs to know that so it can know what input structure it > should expect. But validating processors just report more errors than non-validating ones, so I don't see a place for this "sees two elements as distinct" notion you keep repeating. > > I really don't see why the parse tree would need to expose content > > models, particularly in the case of the render-only application you > > describe. > > How can you write a stylesheet that makes no assumptions about the > structure and hierarchy of the data? It's impossible. Go back to the example I keep using: the stylesheet knows the "frameset" rules. It has _that_ set of assumptions about structure and hierarchy. The "frameset" rules match most folks' understanding of what HTML is, in any case -- forcing a lesser set of rules would be confusing. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at docuverse.com Wed Sep 1 18:54:42 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:34 2004 Subject: Why namespaces? In-Reply-To: Message-ID: <000001bef49b$089d7e40$5a2bfea9@w21tp> >'fraid I don't agree. For the *legacy* HTML you may still need to >distinguish where it came from when it is being processed as XHTML. You >might have a MathML document that contains an element that can contain >some XHTML, but the source of that XHTML could be any of the three >variants of HTML. Or you might want to convert data in a table in an >HTML 4.0 strict document to one XML tag, and data in a table in an HTML >4.0 transitional document to another XML element, but treat the rest of >the tags the same, *and* only write one XSL stylesheet. Fine, but why do you have to use the namespace for this? You can wrap your XHTML fragments with another element, introduce version attribute in tag, or use a ugly-but-true processing instruction? >Obviously when everything has been tidied up, and modules of XHTML are >being used, then you will only need the namespaces for the modules you >want to use, and there will be no need for three. Namespaces for individual modules? Where did this idea come from? XHTML modularization is done by building DTDs using the modules as components. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From hoxford at dtai.com Wed Sep 1 19:19:27 1999 From: hoxford at dtai.com (Hank Oxford) Date: Mon Jun 7 17:14:34 2004 Subject: etymology of "XSDL" References: <01BA10F0CD20D3119B2400805FD40F9F277CF0@MDYNYCMSX1> Message-ID: <37CD620A.968A5D05@dtai.com> I don't know if it's official but I've been using it. I believe it stands for XML Schema Definition Language. >From the Abstract in the working draft: "XML Schema: Structures is part one of a two part draft of the specification for the XML Schema definition language." "DuCharme, Robert" wrote: > > Is "XSDL" an official way to refer to the W3C's schema language proposal? > The acronym is used a few times in > http://www.w3.org/1999/05/06-xsdl/WD-xsdl.dtd, but never spelled out. Can I > assume that it stands for "XML Schema Development Language"? It's never used > in Part 1 of the Schema proposal itself, and it's only used in Part 2 in > Appendix A, which reproduces (as far as I can tell) > http://www.w3.org/1999/05/06-xsdl/WD-xsdl.dtd. Where did the acronym come > into being--in the working group discussions? -- Hank Oxford DTAI, Incorporated hoxford@dtai.com 2815 Camino del Rio South 1-619-542-7229 San Diego, CA 92108 1-888-222-3824 x229 http://www.dtai.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Wed Sep 1 19:33:02 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:14:34 2004 Subject: Required Reading (was Re: Who needs XHTML Namespace?) In-Reply-To: <14285.11787.599045.73085@localhost.localdomain> (message from David Megginson on Wed, 1 Sep 1999 10:06:54 -0400 (EDT)) References: <14283.53021.904985.100176@localhost.localdomain> <37C9AD73.3CB19C76@prescod.net> <14284.25191.594088.269222@localhost.localdomain> <37CD0E78.2A9344EF@prescod.net> <14285.11787.599045.73085@localhost.localdomain> Message-ID: <199909011735.MAA01310@bruno.techno.com> [David Megginson:] > The MIT approach ("the right thing") dominated standards, software, > and systems development from the IBM days of the 50's and 60's until > the late 80's, and the New Jersey approach ("worse is better") became > the clear leader by the mid 1990's when the Internet and the > worse-is-better Web so thoroughly trumped the entire computer > establishment. Who knows what the next decade will bring? My money's on the MIT approach. The New Jersey approach was right only briefly, and then only because it was needed to resolve the most significant and paralyzing crisis that ever struck the telecommunications and information technology industries. The crisis was that everyone could see that there was a sumptuous feast on the table, and everyone was standing around waiting to see who would sit down, and where, to start eating. Nobody wanted to be among the first. The problem was that those who sat down first would almost certainly turn out not to have chosen the richest seats at the table. CompuServe, for example, was an early sitter. Remember CompuServe? By handing each standee a spoon, the Web allowed the feeding frenzy to begin in earnest. Nobody even had to sit down in order to start eating. The Web was needed just to get everyone to start eating, and it didn't matter that it wasn't sophisticated or anything. Much of the food on the table could be sampled by everyone. Brilliant! But now people are noticing that a lot of food can't be eaten with spoons, and the spoons that the Web provided aren't really optimal ways to convey food into their mouths. It's very hard to get people to agree to use new implements, or to agree about what a new implement might be. New spoon designs have to make sense to everyone now, not just the spoon's original inventors, who only needed an approximate solution to get people to start eating. The right thing will prevail. The success of the New Jersey approach during the '90s will turn out to have been an extraordinary blip in the history of IT. Now that the public is well and truly involved, public consensus is essential. There is no substitute for doing the right thing, and there is no other basis for public consensus about how to convey food into mouths. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 fax +1 972 994 0087 pager (150 characters max): srn-page@techno.com 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 andrewl at microsoft.com Wed Sep 1 19:42:56 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:14:34 2004 Subject: canonical form Message-ID: <5BF896CAFE8DD111812400805F1991F712E171BC@RED-MSG-08> By 'canonical form' I assume you mean the style of XML described in the paper I co-authored showing how graphs of objects could be serialized in XML using elements to represent objects/nodes and attributes for properties/edges. I should clarify something: This paper shows only one possible way to serialize graphs, and serializing graphs is only one possible use of XML. The particular choices in that paper were motivated by the fact that, if one wishes to describe the syntax using a DTD, elements do not provide local scoping of property names while attributes do. It is perfectly reasonable to choose other styles of XML usage for serializing graphs. The style you indicate (properties as subelements) can be made to work, though describing the resulting syntax in a DTD is either not possible or requires some munging of property names. (This awkwardness is relieved in the drafts of the new schema language under discussion at the W3C.) I hope this is helpful, Andrew Layman Microsoft -----Original Message----- From: yimin zhu [mailto:yiminz@timberline.com] Sent: Wednesday, September 01, 1999 8:17 AM To: xml-dev Subject: canonical form While mapping graphs, say UML models into XML-data schema, what will happen if I do not use "canonical form"? I mean entity properties are mapped to subelements rather than attributes? Does anyone ran into the same problem before? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe 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 wunder at infoseek.com Wed Sep 1 19:54:49 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:14:34 2004 Subject: Who needs XHTML Namespace? In-Reply-To: <37CD0E78.2A9344EF@prescod.net> References: <14283.53021.904985.100176@localhost.localdomain> <37C9AD73.3CB19C76@prescod.net> <14284.25191.594088.269222@localhost.localdomain> Message-ID: <3.0.5.32.19990901105242.03ea8100@corp.infoseek.com> At 07:31 AM 9/1/99 -0400, Paul Prescod wrote: >David Megginson wrote: >> >> Paul Prescod writes: >> >> > What is the virtue in discovering XHTML data in an arbitrary >> > document if there are *no rules* about what that information will >> > look like? Are you really going to write processors that do not >> > care whether images occur within titles or tables within images? >> >> Sure -- a search engine is a very good example of one. > >Really? Search engines don't care whether s have images in them? >Or whether <h1>'s have <table>'s in them? I'm sure that there are some >that don't but I'm equally sure that there are some that do. Ours doesn't. It recognizes some tags as a place to break sentences for natural language processing, and it looks for the first undecorated text in the document to use as a summary. It also saves text from inside an <a> tag to index with the referenced document (no, Google didn't do it first). But it doesn't care whether <title> has an image, or which kind of sentence-breaking tag is used (<p>, <blockquote>, <td>, ...). Hmm, the "strict" variant makes looking for undecorated text more difficult. I doubt that we'll interpret a stylesheets in order to index text. So anbody who wants to use "strict" had better be ready to put in "description" meta tags. wunder -- Walter R. Underwood wunder@infoseek.com wunder@best.com (home) http://software.infoseek.com/cce/ (my product) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Sep 1 20:25:10 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:34 2004 Subject: Required Reading (was Re: Who needs XHTML Namespace?) References: <A26F84C9D8EDD111A102006097C4CD0D0E8F29@sohos002.ied-support.net> <14283.53021.904985.100176@localhost.localdomain> <37C9AD73.3CB19C76@prescod.net> <14284.25191.594088.269222@localhost.localdomain> <37CD0E78.2A9344EF@prescod.net> <14285.11787.599045.73085@localhost.localdomain> <199909011735.MAA01310@bruno.techno.com> Message-ID: <37CD6FDD.6D78D785@pacbell.net> I don't think I saw any URL for the reading that's required: http://www.naggum.no/worse-is-better.html And there are other copies too, some with dates that I suspect may be more accurate. Section 2.1 is the "worse is better" that's so often taken out of context. It really is a classic -- read it! "Steven R. Newcomb" wrote: > > My money's on the MIT approach. The New Jersey approach was right > only briefly ... I'll disagree, for all the reasons in that paper! :-) Don't be misled by some of the labels that were applied. It's unfair in a major way to characterize the "MIT approach" as "the right thing", or to accept the "worse is better" labeling without understanding the biases that were being explicated by that paper. A more balanced characterization is "overengineering" (or perhaps even "academic research") versus "making tradeoffs for simplicity". Or, as it was expressed in that paper, the "big complex system" (MIT approach) versus the "diamond-like jewel" (New Jersey). Remember, you need to understand that the author of that piece was from the MIT crowd and was trying to explain to that group just what had gone wrong. What made the LISP community lose so thoroughly to the UNIX/C community -- just as it seemed victory was in reach? Somehow he neglected to mention some fairly major issues (LISP needed expensive hardware, vs off-the-shelf UNIX boxen; and also, many people have an illogical aversion to parenthesis :-), though he did tease out some more subtle issues tied to the way UNIX/C prioritized simplicity and usability (== adoptability). - 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 uche.ogbuji at fourthought.com Wed Sep 1 21:01:09 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:14:34 2004 Subject: No subject Message-ID: <199909011703.NAA02603@malatesta.local> FourThought LLC (http://FourThought.com) announces the release of 4DOM 0.8.0 ----------------------- An implementation of the W3C's Document Object Model in Python 4DOM is a close implementation of the DOM recommendation, 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 can work in a CORBA* enviroment, or in a purely local set-up. 4DOM is designed to allow developers rapidly design applications that read, write or manipulate HTML and XML. News ---- There have been many changes to 4DOM since the last major release, 0.7.0. There were two more releases, which were only bundled with 4XSL. For a complete listing, please see ftp://FourThought.com/pub/4Suite/4DOM/ChangeLog But some highlights: * Support for non-CORBA usage * Improved performance * DOM Level 2 NodeFilters and NodeIterators * Pythonic interface for NodeLists and NamedNodeMaps * XML Namespace support (proprietary until W3C decides chooses between the proposed Level 2 interfaces) * Several interface changes in Ext * Re-organized module structure * Explicit garbage-collection method * Better-tested Fnorb and Ilu support * Many bug-fixes More info and Obtaining 4DOM ---------------------------- Please see http://FourThought.com/4Suite/4DOM Or you can download 4DOM from ftp://FourThought.com/pub/4Suite/4DOM 4DOM is distributed under a license similar to that of Python. *For CORBA users, 4DOM directly supports ILU and Fnorb. -- 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 Mark.Birbeck at iedigital.net Wed Sep 1 21:14:30 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:34 2004 Subject: Philosophy behind XHTML (Was RE: why distinctions within XHTML?) Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F44@sohos002.ied-support.net> David Hunter wrote > It [XHTML] *does* have to do with changing our ways, at > some point, and writing XHTML instead of HTML. But XHTML will eventually not be a single vocabulary, it will be a collection of modules. If you are really concerned about 'changing our ways' you are better off waiting for XHTML to be completed. Anything else is, no matter how much people puff and pant, a stop-gap. Can parts of XHTML 1.0 be used in compact devices like mobile phones or toasters? No - until it's modularised you have to take the whole damn lot. Can parts of it be used in other grammars when you want a table but don't want to re-invent the wheel? Well, yes if you can live without validation, but no, otherwise. Can I include other grammars in an XHTML document? Again, only if I forgo validation. Yet all of these things are stated goals in the XHTML proposals. So, it is (a) nowhere near complete (b) nowhere near its stated goal (c) a stop-gap. (Or as Dr. Evil would say, "Stop-gap, stop-gap, stop-gap. That's W W W dot stop-gap.") > XHTML is not an "intermediary", until we're ready to > write everything in another XML vocabulary. In the context of my last email, by 'intermediary', I meant conduit, rather than evolutionary stage. Just as you might convert XML to 'XSLFO' and then convert it to postscript or HTML, so you might go HTML->XHTML->FliXML. You seem to think I mean that HTML and its variants will disappear, and that instead, XML will be used everywhere with CSS or something to display it. Actually I don't, but I think it will eventually only exist as fragments in stylesheets that are applied to XML, and very small devices that have not got an XML parser, but have got parsers for various XHTML modules. > But it's not. The purpose of XHTML today and tomorrow is the > same as the purpose of HTML was yesterday and today: to convey > information to a human. > Period. (Usually visually, i.e. in a browser.) > > That has nothing to do with transforming HTML to another XML > vocabulary, as in your previous email. Why should the joys of HTML be preserved for humans? Why shouldn't my server take your web pages and re-format them as marked-up data? Seems a pretty good use of XHTML to me. Eventually the whole world will be marked-up data, you won't be able to move for it. But that's a long way off, so XHTML is crucial in the meantime. You seem to be saying that I should wait until someone comes up with weather forecasts in XML before I can put weather on my site, but I'm saying that I could take one of the thousands of web sites currently dishing up weather, tidy up the HTML to XHTML, and then run XSL on it to get weather forecasts in WeatherXML (or whatever). If you insist that this is not a valid use for XHTML 1.0 then why bother having it? Any other use of XHTML 1.0 will be superseded by the modular version of XHTML which will be a far better thing to use if you are writing a web browser. Your XHTML 1.0 documents will still work, but they won't be 'best practice'. And you will also need the schema proposals to be completed so that namespaces can be mixed in the same document (and validated). And while we're at it, we would need fragment proposals to be complete too. One last thing. You say: > It [XHTML] doesn't really even have anything to do with > transforming other XML vocabularies into XHTML but that is not true. In fact, one of the good things about XHTML is that it gives us a standard to transform XML to, when we want it displayed. Since XSL is meant to output XML, then you aren't really supposed to be outputting HTML (although I notice that XSLT lets you do it now). Over the last year we all adopted slightly different ways of getting round this, when we sought to generate XML structured HTML pages without causing browsers to squeal. Now we can all adopt the same format. (As to the namespace issue, I've voted for 3 already.) Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 1 21:24:38 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:34 2004 Subject: Required Reading (was Re: Who needs XHTML Namespace?) In-Reply-To: <37CD6FDD.6D78D785@pacbell.net> References: <A26F84C9D8EDD111A102006097C4CD0D0E8F29@sohos002.ied-support.net> <14283.53021.904985.100176@localhost.localdomain> <37C9AD73.3CB19C76@prescod.net> <14284.25191.594088.269222@localhost.localdomain> <37CD0E78.2A9344EF@prescod.net> <14285.11787.599045.73085@localhost.localdomain> <199909011735.MAA01310@bruno.techno.com> <37CD6FDD.6D78D785@pacbell.net> Message-ID: <14285.31601.749873.502013@localhost.localdomain> David Brownell writes: > A more balanced characterization is "overengineering" (or perhaps > even "academic research") versus "making tradeoffs for simplicity". > Or, as it was expressed in that paper, the "big complex system" > (MIT approach) versus the "diamond-like jewel" (New Jersey). Actually, both are MIT, or "the right thing" scenarios; from the paper: How does the right thing stack up? There are two basic scenarios: the big complex system scenario and the diamond-like jewel scenario. The big complex system scenario goes like this: First, the right thing needs to be designed. Then its implementation needs to be designed. Finally it is implemented. Because it is the right thing, it has nearly 100% of desired functionality, and implementation simplicity was never a concern so it takes a long time to implement. It is large and complex. It requires complex tools to use properly. The last 20% takes 80% of the effort, and so the right thing takes a long time to get out, and it only runs satisfactorily on the most sophisticated hardware. The diamond-like jewel scenario goes like this: The right thing takes forever to design, but it is quite small at every point along the way. To implement it to run fast is either impossible or beyond the capabilities of most implementors. We're tending more to the big complex system side these days in the XML Activity, but XHTML itself is probably more of a diamond-like jewel (small but hard to implement efficiently). > Remember, you need to understand that the author of that piece was > from the MIT crowd and was trying to explain to that group just what > had gone wrong. What made the LISP community lose so thoroughly to > the UNIX/C community -- just as it seemed victory was in reach? This lesson needs to be learned over and over and over again, apparently. > Somehow he neglected to mention some fairly major issues (LISP needed > expensive hardware, vs off-the-shelf UNIX boxen; and also, many people > have an illogical aversion to parenthesis :-), though he did tease > out some more subtle issues tied to the way UNIX/C prioritized > simplicity and usability (== adoptability). He doesn't mention the groundless aversion to parenthesis (obviously, some fools try to use editors other than Emacs), but he does mention hardware in a few places besides the one quoted above: Half the computers that exist at any point are worse than median (smaller or slower). Unix and C work fine on them. The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven't they? Unix and C are the ultimate computer viruses. A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus. Users today, who've been brainwashed to think of Unix as something big and bloated rather than small and lean, might be surprised by this perspective, but I have done most of my development work this decade on badly underpowered hardware using Linux, where Windows would have laughed at me for even trying to boot (I have better hardware now, thanks, and can actually run Windows 95 for hours without a crash). 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 Mark.Birbeck at iedigital.net Wed Sep 1 21:44:11 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:34 2004 Subject: Why namespaces? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F46@sohos002.ied-support.net> Don Park wrote: > Mark Birbeck wrote: > > Obviously when everything has been tidied up, and modules of > > XHTML are being used, then you will only need the namespaces > > for the modules you want to use, and there will be no need > > for three. > > Namespaces for individual modules? Where did this idea come > from? XHTML modularization is done by building DTDs using the > modules as components. If you are using modules within other documents and want to validate, you need schemas and namespaces. The current discussion document (on modularization) suggests a way of using DTDs, but it's pretty crude, and will fail in many situations (as the document acknowledges). Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Wed Sep 1 22:44:40 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:34 2004 Subject: why distinctions within XHTML? Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFE34@cc20exch2.mobility.com> From: Mark Birbeck [mailto:Mark.Birbeck@iedigital.net] Sent: Wednesday, September 01, 1999 2:30 PM> To: XML-Dev Mailing list > > In the context of my last email, by 'intermediary', I meant conduit, > rather than evolutionary stage. Just as you might convert XML > to 'XSLFO' > and then convert it to postscript or HTML, so you might go > HTML->XHTML->FliXML. > > You seem to think I mean that HTML and its variants will > disappear, and > that instead, XML will be used everywhere with CSS or something to > display it. Actually I don't, but I think it will eventually > only exist > as fragments in stylesheets that are applied to XML, and very small > devices that have not got an XML parser, but have got parsers for > various XHTML modules. [rest of email snipped, in which Mark points out some good uses for XHTML, and points out a glaring error on my part, where I stated that XHTML isn't about transforming other XML vocabularies into XHTML, when this is obviously one of its likely uses. Ahem. :-) ] Yes, I did in fact misinterpret your last [couple of?] emails as saying that XHTML would disappear in favour of XML+CSS, or some other formatting technologies. And I love the idea of being able to embed XHTML fragments into other XML vocabularies, such as <order> <customer>Fred Jones</customer> <comments xmlns="xhtml-namespace"> <p>Bought <em>500</em> units!</p> </comments> </order> I can even see the utility of transforming from HTML to XHTML to other XML vocabularies in many circumstances. (Such as cases where you want to use XSL to go from the XHTML to the other vocabulary, since XSL needs XML as input.) What I don't see is why any of this means that we need to distinguish the three flavours of XHTML with separate namespaces. <aside>As to why we need separate flavours of XHTML in the first place, I'll go with the explanation given by Ann Navarro in an earlier email, that XHTML *1* is just meant to just put HTML 4 into XML syntax, and that *future* versions may or may not combine them. This works for me, since I happen to like the versioned approach.</aside> Using three namespaces conceptually makes XHTML three distinct languages, instead of one language that can be used in three ways. I'm hoping very much that the W3C will eventually bring XHTML back to one flavour, instead of three. Eventually, I would like to be able to just do what I've done above, and say "this is XHTML", without having to specify that "this is XHTML, and it's strict" etc. I'm worried that if the three current flavours are distinguished by namespaces, it makes it much harder to bring them all back to one eventually, but that instead there will always be a strict, and a loose, and a frameset. On the other hand, if the three flavours are distinguished by an attribute, or a processing instruction, then they can just come up with *one* XHTML namespace, which can be used from now on whenever someone needs to author XHTML. In other words, any application which is working with XML can just look for that namespace and say "oh, this element is using XHTML. I'll hand it off to the XHTML application to process". If we use separate namespaces, then any application which may have XHTML to process will have to know about all of those namespaces. Perhaps not a big deal, if only those three namespaces are ever used, but perhaps a huge deal if more flavours of XHTML are created, or the namespaces are versioned. (That is, a namespace for XHTML-strict-1.0, and one for XHTML-strict-1.1...) Now, instead of just being able to mix XHTML into my documents and not worry about it, my application needs to look for a number of namespaces which could denote XHTML, and be updated any time new XHTML namespaces are introduced. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 1 23:33:33 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:34 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <805C62F55FFAD1118D0800805FBB428D02BBFE34@cc20exch2.mobility.com> References: <805C62F55FFAD1118D0800805FBB428D02BBFE34@cc20exch2.mobility.com> Message-ID: <14285.37768.371687.892071@localhost.localdomain> Hunter, David writes: > In other words, any application which is working with XML can just > look for that namespace and say "oh, this element is using XHTML. > I'll hand it off to the XHTML application to process". If we use > separate namespaces, then any application which may have XHTML to > process will have to know about all of those namespaces. Perhaps > not a big deal, if only those three namespaces are ever used, but > perhaps a huge deal if more flavours of XHTML are created, or the > namespaces are versioned. In fact, there could end up being an exponential explosion of XHTML-related Namespaces, depending on how the HTML WG intends to proceed (it's not explicit in the publicly-available XHTML documents, and I hear contradictory things from the WG members). What happens when a vendor wants to create a new element that will appear in, say, an HTML paragraph? Obviously the new element itself (such as <ms:spreadsheet> or <ra:videoclip>) will have to be in a different Namespace -- that's the whole point -- but will the containing paragraph have to be in a different Namespace as well? In other words (assuming that XHTML is the default Namespace) can we have <p>Today, President Clinton visited the finger lakes. <ra:videoclip src="clinton.ram" />.</p> <p>Economic indicators are down. <ms:spreadsheet src="stuff.xls" />.</p> or does it have to be this? <ra:p>Today, President Clinton visited the finger lakes. <ra:videoclip src="clinton.ram" />.</ra:p> <ms:p>Economic indicators are down. <ms:spreadsheet src="stuff.xls" />.</ms:p> (And, of course, an <ms:li> to hold the <ms:p>, and an <ms:ul> to hold the <ms:li>, and an <ms:body> to hold the <ms:ul>, and an <ms:html> to hold the <ms:body> -- it will always necessarily bubble to the top <html> element). If the HTML WG takes this (terrifying) path, then what happens when a Web author wants both extensions in the same paragraph? <ra:p> doesn't allow <ms:spreadsheet>, and <ms:p> doesn't allow <ra:videoclip>, so it looks like she's somehow expected to invent yet another Namespace herself: <my:p>Today, President Clinton visited the finger lakes. <ra:video-popup src="clinton.ram" />. Economic indicators are down. <ms:spreadsheet src="stuff.xls" />.</my:p> My math sucks, but as far as I can figure out, that means that the number of possible HTML-related Namespace URIs will end up being not only three, but about two to the power of the number of parties who decide to create extensions (and that's assuming that each vendor creates only a single Namespace). That means that if only 20 parties create extensions for use in XHTML documents, we will necessarily end up with over 1,000,000 variants of the <html> element. That's an awful lot more than three extra lines of code, whatever the software infrastructure. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 2 00:06:47 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:34 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? References: <805C62F55FFAD1118D0800805FBB428D02BBFE34@cc20exch2.mobility.com> <14285.37768.371687.892071@localhost.localdomain> Message-ID: <37CDA3C4.C4E6457D@pacbell.net> As someone said (and it wasn't Bill Joy who said it first, despite what someone said here the other day!) there are only three interesting numbers in computer science: zero, one, and many (including an infinity). If the XHTML WG doesn't want one namespace (like us rational folk on this list :-), and we don't like to see an unbounded number of namespace IDs ... Perhaps the right answer is zero: just take the namespace URI out of the XHTML spec completely. - Dave p.s. I think the actual formula is a bit less than N-squared; N, plus N-1 combinations of the namespaces that are "all but one of them", and so on. Regardless of what the real formula is, it's clearly a nonlinear growth. David Megginson wrote: > > Hunter, David writes: > > > In other words, any application which is working with XML can just > > look for that namespace and say "oh, this element is using XHTML. > > I'll hand it off to the XHTML application to process". If we use > > separate namespaces, then any application which may have XHTML to > > process will have to know about all of those namespaces. Perhaps > > not a big deal, if only those three namespaces are ever used, but > > perhaps a huge deal if more flavours of XHTML are created, or the > > namespaces are versioned. > > In fact, there could end up being an exponential explosion of > XHTML-related Namespaces, depending on how the HTML WG intends to > proceed (it's not explicit in the publicly-available XHTML documents, > and I hear contradictory things from the WG members). > > What happens when a vendor wants to create a new element that will > appear in, say, an HTML paragraph? Obviously the new element itself > (such as <ms:spreadsheet> or <ra:videoclip>) will have to be in a > different Namespace -- that's the whole point -- but will the > containing paragraph have to be in a different Namespace as well? In > other words (assuming that XHTML is the default Namespace) can we have > > <p>Today, President Clinton visited the finger lakes. > <ra:videoclip src="clinton.ram" />.</p> > > <p>Economic indicators are down. > <ms:spreadsheet src="stuff.xls" />.</p> > > or does it have to be this? > > <ra:p>Today, President Clinton visited the finger lakes. > <ra:videoclip src="clinton.ram" />.</ra:p> > > <ms:p>Economic indicators are down. > <ms:spreadsheet src="stuff.xls" />.</ms:p> > > (And, of course, an <ms:li> to hold the <ms:p>, and an <ms:ul> to hold > the <ms:li>, and an <ms:body> to hold the <ms:ul>, and an <ms:html> to > hold the <ms:body> -- it will always necessarily bubble to the top > <html> element). > > If the HTML WG takes this (terrifying) path, then what happens when a > Web author wants both extensions in the same paragraph? <ra:p> > doesn't allow <ms:spreadsheet>, and <ms:p> doesn't allow > <ra:videoclip>, so it looks like she's somehow expected to invent yet > another Namespace herself: > > <my:p>Today, President Clinton visited the finger lakes. > <ra:video-popup src="clinton.ram" />. Economic indicators are > down. <ms:spreadsheet src="stuff.xls" />.</my:p> > > My math sucks, but as far as I can figure out, that means that the > number of possible HTML-related Namespace URIs will end up being not > only three, but about two to the power of the number of parties who > decide to create extensions (and that's assuming that each vendor > creates only a single Namespace). > > That means that if only 20 parties create extensions for use in XHTML > documents, we will necessarily end up with over 1,000,000 variants of > the <html> element. > > That's an awful lot more than three extra lines of code, whatever the > software infrastructure. > > All the best, > > David > > -- > David Megginson david@megginson.com > http://www.megginson.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmg at trivida.com Thu Sep 2 00:47:50 1999 From: jmg at trivida.com (Jeff Greif) Date: Mon Jun 7 17:14:34 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? References: <805C62F55FFAD1118D0800805FBB428D02BBFE34@cc20exch2.mobility.com> <14285.37768.371687.892071@localhost.localdomain> Message-ID: <078801bef4cc$142027f0$a24630d1@trivida.com> But isn't any tag proliferation of this sort (rendering data for an external application) supposed to be avoided (in HTML 4 at least) by <OBJECT type="application/x-ms-spreadsheet" data="stuff.xls" ...></OBJECT> and <OBJECT type="application/x-ra-videoclip" data="clinton.ram" ...></OBJECT> People shouldn't be adding such tags, defining DTDs to support them, or making namespaces to attempt to distinguish their new bogus HTML derivatives from the vanilla forms. One would hope vendors would not be so stupid as to do this when there is no longer any justification whatever (in some earlier HTMLs there was no uniform mechanism). Jeff ----- Original Message ----- From: David Megginson <david@megginson.com> To: XML-Dev Mailing list <xml-dev@ic.ac.uk> Sent: Wednesday, September 01, 1999 2:35 PM Subject: How about over 1,000,000 XHTML Namespace URIs? ... > What happens when a vendor wants to create a new element that will > appear in, say, an HTML paragraph? Obviously the new element itself > (such as <ms:spreadsheet> or <ra:videoclip>) will have to be in a > different Namespace -- that's the whole point -- but will the > containing paragraph have to be in a different Namespace as well? In > other words (assuming that XHTML is the default Namespace) can we have > > <p>Today, President Clinton visited the finger lakes. > <ra:videoclip src="clinton.ram" />.</p> > > <p>Economic indicators are down. > <ms:spreadsheet src="stuff.xls" />.</p> > > or does it have to be this? > > <ra:p>Today, President Clinton visited the finger lakes. > <ra:videoclip src="clinton.ram" />.</ra:p> > > <ms:p>Economic indicators are down. > <ms:spreadsheet src="stuff.xls" />.</ms:p> > > (And, of course, an <ms:li> to hold the <ms:p>, and an <ms:ul> to hold > the <ms:li>, and an <ms:body> to hold the <ms:ul>, and an <ms:html> to > hold the <ms:body> -- it will always necessarily bubble to the top > <html> 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Sep 2 01:42:38 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:14:34 2004 Subject: ANN: 4XPath 0.7.0 Message-ID: <199909012145.RAA03207@malatesta.local> FourThought LLC (http://FourThought.com) announces the release of 4XPath 0.7.0 ----------------------- A python implementation of the W3C's XPath language 4XPath implements the W3C XPath language for indicating and selecting XML document components. http://www.w3.org/TR/xpath 4XPath implements the full 4XPath specification. News ---- This is the first public release. More info and Obtaining 4XPath ----------------------------- Please see http://FourThought.com/4Suite/4XPath Or you can download 4XPath from ftp://FourThought.com/pub/4Suite/4XPath 4XPath is distributed under a license similar to that of Python. -- 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 uche.ogbuji at fourthought.com Thu Sep 2 02:37:48 1999 From: uche.ogbuji at fourthought.com (uche.ogbuji@fourthought.com) Date: Mon Jun 7 17:14:34 2004 Subject: ANN: 4XSLT 0.7.0 Message-ID: <199909012238.SAA03332@malatesta.local> FourThought LLC (http://FourThought.com) announces the release of 4XSLT 0.7.0 ----------------------- A python implementation of the W3C's XSLT language 4XSLT is an XML transformation processor based on the W3C's specification for the XSLT transform language. http://www.w3.org/TR/xslt Currently, 4XSLT supports a sub-set of the August 13th working draft of XSLT including the following: Full expression support and attribute-value template expansion xsl:include xsl:template xsl:apply-templates xsl:for-each xsl:element xsl:attribute xsl:text xsl:value-of and literal elements and text 4XSLT produces its result tree by throwing standard SAX events to a document handler, so it can be easily modified to supply results to any SAX consumer. News ---- This is the first broad release. More info and Obtaining 4XSLT ----------------------------- Please see http://FourThought.com/4Suite/4XSLT Or you can download 4XSLT from ftp://FourThought.com/pub/4Suite/4XSLT 4XSLT is distributed under a license similar to that of Python. -- 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 Thu Sep 2 02:37:39 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:34 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <078801bef4cc$142027f0$a24630d1@trivida.com> References: <805C62F55FFAD1118D0800805FBB428D02BBFE34@cc20exch2.mobility.com> <14285.37768.371687.892071@localhost.localdomain> <078801bef4cc$142027f0$a24630d1@trivida.com> Message-ID: <14285.50781.96870.331504@localhost.localdomain> Jeff Greif writes: > But isn't any tag proliferation of this sort (rendering data for an > external application) supposed to be avoided (in HTML 4 at least) > by > > <OBJECT type="application/x-ms-spreadsheet" data="stuff.xls" ...></OBJECT> > and > <OBJECT type="application/x-ra-videoclip" data="clinton.ram" ...></OBJECT> Pick a different example, then; how about <p>It costs <ecomm:price curr="USD">$20.00</ecomm:price>.</p> or <p>I met <reuters:person>Joe Clark</reuters:person>.</p> The original selling point of XML (not, I think, its most important use, but the reason it got all the press) was that it would provide a well-defined way to extend XML. This is the kind of extension that people were thinking of, and XHTML will let us all down if it tries to make such an easy thing hard. We still end up with exactly the same unmanageable proliferation of Namespace URIs if we need a different Namespace URI for the HTML containing each extension. 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 Mark.Birbeck at iedigital.net Thu Sep 2 03:32:08 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:34 2004 Subject: why distinctions within XHTML? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F47@sohos002.ied-support.net> David Hunter wrote: > ... And I love the idea of being able to embed > XHTML fragments into other XML vocabularies, such as > > <order> > <customer>Fred Jones</customer> > <comments xmlns="xhtml-namespace"> > <p>Bought <em>500</em> units!</p> > </comments> > </order> [snip] > What I don't see is why any of this means that we need to > distinguish the three flavours of XHTML with separate > namespaces. [snip] > I'm worried that if the three current flavours are > distinguished by namespaces, it makes it much harder to > bring them all back to one eventually, but that instead > there will always be a strict, and a loose, and a frameset. [snip] > In other words, any application which is working with XML can > just look for that namespace and say "oh, this element is using > XHTML. I'll hand it off to the XHTML application to process". David, My argument is that in the future, version >1 of XHTML will be modularised and so you will actually do this: <order xmlns="myorderstuff" xmlns:bl="xhtml.block.text.module"> <customer>Fred Jones</customer> <comments> <bl:p>Bought <bl:em>500</bl:em> units!</bl:p> </comments> </order> Note that I've moved the namespace definition down a level from 'comments' because you wouldn't put it there. All you would need to do would be to define in your schema that 'comments' can have children from the 'XHTML block text module'. (Quite why David M thinks each new namespace should be at the 'comments' level is baffling me. A million namespaces!?!) In other words, you won't be using 'strict', 'transitional', or anything. In terms of post-parsing processing, in this scenario a 'p' is a 'p' is a 'p' (as everyone wants, albeit a bl:p now, instead of a generic html:p). However, at the moment none of this exists, although it is a stated goal of XHTML. (If you haven't already, have a look at the modularization document - it's very impressive.) So, even if you accept what I have just said, you could still say why bother having three namespaces today? Why not just wait until the modularization stuff is complete? And I can only repeat that there is still the issue of legacy documents. Converting the mass of HTML we have, to nice XML requires going via XHTML, and you may need to know which flavour of HTML 4.0 you came from. Imagine for example, writing an application that took a load of web pages of football results or phone lists, and wanted to convert them to XML files of the core data, with accompanying XSL files that when applied to the this XML data bring you back to the original HTML that you just broke down. (A pretty nifty app!) In that situation you would probably want to know what variant you came from. As I said in a previous message, if you think of what I just described as tidyHTML, and the modularised stuff as futureHTML then it's all pretty straightforward. It just so happens that tidyHTML has been called XHTML 1.0 and futureHTML is also called XHTML ... and currently stands at, er ... version 1.0. (And also to get some good PR, I think the W3C pushed the futureHTML aspect of XHTML, which if we're honest is not even out of the stalls yet.) Regards, Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Marc.McDonald at Design-Intelligence.com Thu Sep 2 03:32:03 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:14:35 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? Message-ID: <4454C011BDE5D211B6C800609776E54016CD24@master.design-intelligence.com> I took a look at the XHTML DTDs and basically wonder why there is a need for 3 of them at all or their corresponding namespaces. The major difference in structure is a frameset element instead of a body element inside the HTML element. There are additional attributes for color, alignment, and a target frame. There are a few added elements. The DTDs map as follows: strict No alignment, colors, framesets frameset Alignment, colors, framesets transitional Alignment, colors, no framesets An HTML processor is supposed to handle unexpected elements gracefully, so why not have one DTD and namespace? The use of any elements or attributes not expected by the processor need to be handled anyway. Just always use the frameset DTD with the change of: <!ELEMENT html (head, (body | frameset))> so either frameset or non-frameset structure is valid. The single DTD should be modified to have conditionals to restrict it to the given subset DTDs if desired for restrictive validation. So many parameter entites are used and no one thought of using them for the differences: <!ENTITY a.targeting % "target %FrameTarget; #IMPLIED"> <!ENTITY a.align % "align %imgAlign; #IMPLIED"> <!ENTITY a.spacing % "hspace %pixels; #IMPLIED vspace %pixels; #IMPLIED"> etc. Besides eliminating the problem, it's a lot easier to maintain one DTD instead of three with 95% commonality. > Marc B. McDonald > Principal Software Scientist > Design Intelligence, Inc. > 1111 Third Avenue, Suite 1500 > Seattle, WA 98101 > marc.mcdonald@design-intelligence.com > Ph: 206.343-7797 > Fax: 206.343.7750 > > http://www.design-intelligence.com > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Thu Sep 2 03:27:09 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:35 2004 Subject: Why namespaces? References: <A26F84C9D8EDD111A102006097C4CD0D0E8F43@sohos002.ied-support.net> Message-ID: <000601bef4e0$f9c45d80$0300000a@cygnus.uwa.edu.au> Mark Birbeck wrote: > Simon St.Laurent wrote: > > At 09:17 AM 9/1/99 +0800, James Tauber wrote: > > >"we would only need separate namespaces for each flavour of > > > XHTML if people are going to want to mix the three flavours > > > in the one document and distinguish the different usages > > > of the element/attributes names in the intersection." > > > > Simple, clean, cuts to the heart of the matter. > > 'fraid I don't agree. For the *legacy* HTML you may still need to > distinguish where it came from when it is being processed as XHTML. But my point is that *namespaces* shouldn't be what you use to make this distinction. Namespaces (by my reading of the spec) are for distinguishing element/attribute vocabularies *within an instance*. James (who still thinks prefix matching of namespaces is a neat idea) -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net <pipe>Ceci n'est pas une pipe</pipe> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Thu Sep 2 03:42:22 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:35 2004 Subject: XHTML & Schemas References: <37CD441A.1FF39F6E@prescod.net> Message-ID: <002001bef4e3$19ad64a0$0300000a@cygnus.uwa.edu.au> ----- Original Message ----- From: Paul Prescod <paul@prescod.net> > Namespaces are triggers for various things. Stylesheets, validators, > etc. Up until I changed my mind about this premise, I agreed completely with both your three-namespace conclusion and your actual argument for it. However, I no longer agree with the premise above as stated. Namespaces are for distinguishing element/attribute vocabularies within an instance. Any other use of them is beyond the spec and bound to end up in arguments on xml-dev :-) A corollary to this is that *something else* (perhaps in conjunction with namespaces) must trigger stylesheets, validators, etc. I would like to see a solution proposed for that---soon, if at all possible. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net <pipe>Ceci n'est pas une pipe</pipe> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 04:16:54 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:35 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? References: <805C62F55FFAD1118D0800805FBB428D02BBFE34@cc20exch2.mobility.com> <14285.37768.371687.892071@localhost.localdomain> Message-ID: <37CDCE10.9BB80D1E@prescod.net> David Megginson wrote: > > What happens when a vendor wants to create a new element that will > appear in, say, an HTML paragraph? Obviously the new element itself > (such as <ms:spreadsheet> or <ra:videoclip>) will have to be in a > different Namespace -- that's the whole point -- but will the > containing paragraph have to be in a different Namespace as well? Today? Yes. XHTML is not designed nor defined to allow other element types to be mixed in nor to BE mixed in. Tomorrow, XHTML is supposed to be defined to be extensible. Then a single namespace (and schema) will be sufficient. The problem is that people want to act as if it is extensible today which it is clearly not (name notwithstandaing). Ading a namespace to something doesn't magically make it into something that can be mixed into other DTDs. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Thu Sep 2 04:29:43 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:35 2004 Subject: Why namespaces? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F48@sohos002.ied-support.net> James Tauber wrote: > Mark Birbeck wrote: > > Simon St.Laurent wrote: > > > At 09:17 AM 9/1/99 +0800, James Tauber wrote: > > > >"we would only need separate namespaces for each flavour of > > > > XHTML if people are going to want to mix the three flavours > > > > in the one document and distinguish the different usages > > > > of the element/attributes names in the intersection." > > > > > > Simple, clean, cuts to the heart of the matter. > > > > 'fraid I don't agree. For the *legacy* HTML you may still need to > > distinguish where it came from when it is being processed as XHTML. > > But my point is that *namespaces* shouldn't be what you use > to make this > distinction. So, how else do you make the distinction? You can't use DTDs if the XHTML is inside another doc - so what else? > Namespaces (by my reading of the spec) are for distinguishing > element/attribute vocabularies *within an instance*. Not so. My server might receive this: <com:delete> <u:user> <u:name>Mark</u:name> </u:user> </com:delete> and then five minutes later receive this: <com:delete> <c:computer> <c:name>laptop</c:name> </c:computer> </com:delete> By your reckoning the fact that the first document has 'com' and 'u' distinct, and the second has 'com' and 'c' distinct is fine. But what if the first delete instruction simply referred to removing the user profile, and not the user? In other words, the two 'delete' nodes might be in different namespaces and do different things, even though they are not in the same document. My server would surely want to know which namespace they occupied. Namespaces (by my reading of the spec) are for distinguishing element/attribute vocabularies *within the whole world*. Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From litebook at powerup.com.au Thu Sep 2 04:39:33 1999 From: litebook at powerup.com.au (Trevor Croll) Date: Mon Jun 7 17:14:35 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? References: <805C62F55FFAD1118D0800805FBB428D02BBFE34@cc20exch2.mobility.com> <14285.37768.371687.892071@localhost.localdomain> <37CDCE10.9BB80D1E@prescod.net> Message-ID: <002301bef4ec$21c88080$334ffea9@litebook> More examples of the cheap winning over the better are: The IBM XT PC - 8bit with 16 bit external processor won over the 32bit Motorolla, Zilog, and other processors that were much better with superior hardware and operating systems that were more expensive. People punished themselves with MS-DOS for 10 years when Apple MAC users were using WINDOWS??? DOS systems were cheap and widely available and open. The cheap and easy to get MS DOS beat CP/M, UNIX, MUFO, MUMPS, PICK, ..... as an operating system of choice. MS Word beat Word perfect because of the dominance of MS-DOS and Windows and Microsoft. History shows that the simple and low cost beats the complex every time. The DODO was a bird that lived on a pacific Island, It became big, lost its ability to fly, and became extinct. -- This is the lesson the W3C should keep in mind. ----- Original Message ----- From: Paul Prescod <paul@prescod.net> To: XML-Dev Mailing list <xml-dev@ic.ac.uk> Sent: Thursday, September 02, 1999 11:08 AM Subject: Re: How about over 1,000,000 XHTML Namespace URIs? > David Megginson wrote: > > > > What happens when a vendor wants to create a new element that will > > appear in, say, an HTML paragraph? Obviously the new element itself > > (such as <ms:spreadsheet> or <ra:videoclip>) will have to be in a > > different Namespace -- that's the whole point -- but will the > > containing paragraph have to be in a different Namespace as well? > > Today? Yes. XHTML is not designed nor defined to allow other element > types to be mixed in nor to BE mixed in. > > Tomorrow, XHTML is supposed to be defined to be extensible. Then a > single namespace (and schema) will be sufficient. > > The problem is that people want to act as if it is extensible today > which it is clearly not (name notwithstandaing). Ading a namespace to > something doesn't magically make it into something that can be mixed > into other DTDs. > > Paul Prescod > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 04:58:07 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:35 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F4A@sohos002.ied-support.net> Marc McDonald wrote: > An HTML processor is supposed to handle unexpected elements > gracefully, so why not have one DTD and namespace? The use of > any elements or attributes not expected by the processor need > to be handled anyway. Because it might not be an HTML processor that is handling the XHTML. Just 'cos browsers are supposed to carry on regardless if they see an error, doesn't mean every other application should. Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at docuverse.com Thu Sep 2 07:30:41 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:35 2004 Subject: Consensus and Petition for XHTML Namespaces Message-ID: <000001bef504$ccdd92e0$5a2bfea9@w21tp> If I am guessing correctly, everyone is sick of all the discussions on the XHTML Namespace(s) issue. I think it is time to find out if there is enough consensus against multiple XHTML namespaces. If there a substantial consensus, I propose that we submit a formal petition to the Director of W3C, Tim Berners-Lee, to return the document for work at the working draft stage, with a request to the editors to use single XHTML namespace instead of three. Whether he follows 'our recommendation' for a change or not depends on whether he wants to widen the controversy from XHTML to W3C. The reason I am proposing for a formal petition is that I believe the W3C process as it stands now has broken down, if not in general then at least in this particular case. It is the Director of the W3C who makes the decision on whether to approve Recommendations, a judge of sort. If the Director has a preconceived bias on a critical issue, he can not make a fair decision. I believe that the Director is biased against single XHTML namespace. This is not the way a standards committee should work, not even behind the Iron Curtain. The action I am proposing will create a new precedence in the W3C 'process' and I am certain that it will be a good one. Yes, I am biased on that point. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 2 12:08:12 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:35 2004 Subject: XML Parsers for Java -- Recommendations? References: <93CB64052F94D211BC5D0010A800133170F095@wwmess3.bra01.icl.co.uk> Message-ID: <37CE4CF7.D138AA2D@pacbell.net> Kay Michael wrote: > > > Have a look at the parser conformance test results on my web page at > > > > http://home.pacbell.net/david-b/xml/ > > > I only see the conformance tests there, not the results. Scroll down a bit to the list of parsers. At this point there are results for most of the SAX parsers I know about. I just updated this; maybe that page will be easier to navigate. Nonvalidating - Sun TR2 (SAX2 wrapper) - XP 0.5 - Lark 1.0beta - Oracle 2.0.0.2 (SAX2 wrapper) - IBM 2.0.15 - AElfred 1.2a (SAX2 wrapper) - Silfide 0.88, a.k.a. SXP - MSXML from Microsoft JVM 3186 - DataChannel XJParser Validating - Sun TR2 (SAX2 wrapper) - IBM 2.0.15 - Oracle 2.0.0.2 (SAX2 wrapper) When you click on the links you'll see a report with all the results, in gory detail -- don't print, browse online. The third table up front is a summary which the best overview you can get for the moment. Yes, what folk _really_ need is a comparative summary ... it's coming! ;-) > > If anything makes me want to kill a programmer, it's the level of > > gratuitous nonconformance that a few of those parsers show! > > I don't mind a parser that lets through the occasional document that should > strictly be rejected (e.g. by tolerating a stray zero byte at the end of the > document). Unfortunately, not many parsers have as few problems as that!! Look at the diagnostics in the reports above, and compare them to what they should be trying to say (e.g. nothing :-). > The only mainstream parser I refuse absolutely to use or > recommend to anyone is the one that arbitrarily rejects well-formed > documents. But since I don't want to have to defend myself in court, I'm > reluctant to publish its name here - the authors know, because I have told > them. I think a bunch of the folk providing the parsers above have gotten such reports from me, too. Not many have fixed their problems though. I'll mention Oracle favorably -- they deserve it! That new parser is looking nice, though it may not yet be shipped in products. - Dave > 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 Michael.Kay at icl.com Thu Sep 2 13:37:33 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:14:35 2004 Subject: XML Parsers for Java -- Recommendations? Message-ID: <93CB64052F94D211BC5D0010A800133170F095@wwmess3.bra01.icl.co.uk> > > Have a look at the parser conformance test results on my web page at > > http://home.pacbell.net/david-b/xml/ > I only see the conformance tests there, not the results. > If anything makes me want to kill a programmer, it's the level of > gratuitous nonconformance that a few of those parsers show! I don't mind a parser that lets through the occasional document that should strictly be rejected (e.g. by tolerating a stray zero byte at the end of the document). The only mainstream parser I refuse absolutely to use or recommend to anyone is the one that arbitrarily rejects well-formed documents. But since I don't want to have to defend myself in court, I'm reluctant to publish its name here - the authors know, because I have told them. 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 oren at capella.co.il Thu Sep 2 13:52:39 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:35 2004 Subject: Fw: XHTML & Schemas Message-ID: <015901bef538$8d3a1440$4602a8c0@capella.co.il> Paul Prescod <paul@prescod.net> wrote: > Let me try to put this argument on a practical footing. > > Namespaces are triggers for various things. Stylesheets, validators, > etc. > > For better or worse XHTML has three different grammars. I could probably > be convinced that this is a bad idea (and on another day might even > argue vociferously that way). But anyhow, XHTML has three grammars. This > probably has more to do with politics than technology: "our mandate is > to blah blah blah". > > That means that when we get namespace-aware validators there will be > three schemas. Schemas are namespace-triggered: > > * not "version attribute" triggered > * not DOCTYPE triggered > > They are namespace triggered. <ALARM>WHAT?</ALARM> > (and for good reason...trying to bring > attributes into it makes the validation model much more complicated) I disagree - but I don't quite understand what you mean by "bring attributes into it" and how it connects to namespaces, so let it pass for a moment... > It follows that we need three namespaces to attach the three grammars > to. <Gulp>It certainly does.</Gulp> I feel like a fool (that's OK, I'm used to it). I _assumed_ that the matter of associating a namespace with a DTD/XSchemas was not resolved. There certainly has been a lot of action going on in this list about it, and bemoaning of the fact it wasn't cleared anyway. For example, you yourself have said: > By this reasoning, it doesn't matter how many different name-space > prefixes XHTML uses because *none of them* give you a way to know that > what you are processing is in fact an XHTML document (or XHTML-specific > element). Rather, the binding between documents and their *governing > semantic definitions* (e.g., schemas, architectures, etc.) must be > provided by some other mechanism. In the absence of a generalized > mechanism for doing this binding, it can only be done in documentation > of the semantics. Which, is, of course, a direct contradiction of thee above. Don't feel bad; Ann has also said: > (Me:) > > And/or refer me to some W3C paper which clarifies what the > > "official view" is? > > I don't think you'll find one. > > The Namespaces rec was as controversial then as it is now, and opinions are > still widely divided. "When all else fails, read the manual". I went to the XSchema draft and found the following paragraph (http://www.w3.org/TR/xmlschema-1/#composition-instances, section 4.1): During validation, the standard mechanisms of [XML-Namespaces] are interpreted to create associations between instance document prefixes and schema definitions. Thus, there is in each valid instance document a namespace associated with each schema to which the instance conforms. Each namespace qualified element (or eventually entity or notation), its attributes and its content, is validated against its declaration in the corresponding URI-named schema. In that sense, each schema defines and is coextensive with a namespace. The means by which schemas are located during processing is discussed below in Access to Schemata. Comprehensive rules for validation are discussed in Conformance. Their example even shows the namespace URI as pointing to the schema - but another paragraph in the same spec indicates that the processor does not necessarily uses this URI to download the schema. At any rate... OK, I'm a fool - I should have gone to the spec before. I have some mitigating circumstances - one being delivery deadlines, and the other is the assumption that there wouldn't have been such a fuss over this issue if it was resolved. Or is it resolved? XSchemas aren't a recommendation yet... And the consequences of this are so far reaching, and go against so many deeply held positions expressed in this mailing list - how did this remain hidden for so long? Is it that people simply ignore XSchemas (as I did :-)? At any rate, as you've pointed out, the XSchema approach _requires_ the XHTML use of three namespaces. The fact that I don't like it - and that many others don't like it - is besides the point. If people want to have a single namespace for XHTML, they should first go and re-write the above paragraph in the XSchema draft. Right? I know better then to ask why XSchemas don't use a DOCTYPE-like directive to identify the schema. I can see two obvious disadvantages: - There can't be two different XSchemas referring to the same namespace. - A document can't obey more then one XSchema (since each element must belong to a single namespace). Now, I feel this is too high a price to pay for whatever other advantage the XSchema WG had in mind. Just as an example, David Megginson has said: > This is something that SGML got wrong and XML got right -- SGML > assumed that there was always a *single* DTD that applied to any > existing document (though that never worked in practice, so we always > had to invent kludges for non-trivial systems), so that a document > instance could not exist independently of its schema and vice-versa > (external DTD subsets are not independent objects in SGML, but simply > part of the document that includes them). The quoted section 4.1 of the XSchema draft seems to directly contradict his view of what's right, so XML did not "get it right". Am I missing something again? There's also the small matter of writing XSLT stylesheets, and XPointers in general. If this namespace-per-each-XSchema idea catches on, someone had better extend the match patterns to allow saying "{ns1|ns2|ns3}p". Otherwise, writing match pattern would become hellish. I don't generally approve of W3C bashing; I think that on the whole they are doing a good job. But the combination of closed process, lack of rationale documentation, and the multitude of recommendations is causing a lot of unnecessary confusion. This effects everyone using these recommendations, and hence implementations and users. The "second guess the WG" game has to end. If the W3C insists on a closed process, they should at least commit to adding rationale documentation to their recommendation - starting from the very first draft. Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Sep 2 14:16:10 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:35 2004 Subject: XHTML & Schemas In-Reply-To: <015901bef538$8d3a1440$4602a8c0@capella.co.il> References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> Message-ID: <14286.26826.892548.495823@localhost.localdomain> Oren Ben-Kiki writes: > > This is something that SGML got wrong and XML got right -- SGML > > assumed that there was always a *single* DTD that applied to any > > existing document (though that never worked in practice, so we > > always had to invent kludges for non-trivial systems), so that a > > document instance could not exist independently of its schema and > > vice-versa (external DTD subsets are not independent objects in > > SGML, but simply part of the document that includes them). > > The quoted section 4.1 of the XSchema draft seems to directly > contradict his view of what's right, so XML did not "get it > right". Am I missing something again? Yes -- XML-Schema is not XML. XML-Schema is (currently) getting it wrong, but they're in the early drafts, so I still hope for their redemption. 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 clefebvre at advance-groupe.com Thu Sep 2 14:30:34 1999 From: clefebvre at advance-groupe.com (Christophe Lefebvre) Date: Mon Jun 7 17:14:35 2004 Subject: Reload in XML References: <003f01bed4b7$83ecf200$e4224b0a@ncb.gov.sg> Message-ID: <37CE6F09.7DF9843E@advance-groupe.com> Hi, A very easy tip... change the XML file too or just change the date of the file on your server. Hope it helps -- _____________________________________________________________ / / / Christophe Lefebvre - Email : clefebvre@advance-groupe.com // / Ing?nieur Consultant T?l : 01 53 02 40 90 // / Advance Consultants Fax : 01 44 75 82 02 // / 12, cour Saint Eloi http://www.advance-groupe.com // / 75012 Paris // /____________________________________________________________// /____________________________________________________________/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 14:38:43 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:35 2004 Subject: XHTML & Schemas References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> Message-ID: <001601bef53f$06d66050$4602a8c0@capella.co.il> David Megginson <david@megginson.com> wrote: > Yes -- XML-Schema is not XML. XML-Schema is (currently) getting it > wrong, but they're in the early drafts, so I still hope for their > redemption. That's well and good, but we can't wait until the XSchema recommendation is finalized. XHTML is due to be finalized much earlier, and as we've seen it depends on what the decision in XSchema will be. I don't know how the W3C process handles such a conflict. What will happen if XHTML makes a decision, and the XSchema draft then changes so it no longer makes sense? 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 dhunter at Mobility.com Thu Sep 2 14:53:35 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:35 2004 Subject: why distinctions within XHTML? Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFE39@cc20exch2.mobility.com> > From: Mark Birbeck [mailto:Mark.Birbeck@iedigital.net] > Sent: Wednesday, September 01, 1999 9:42 PM <snip/> > My argument is that in the future, version >1 of XHTML will be > modularised and so you will actually do this: > > <order xmlns="myorderstuff" xmlns:bl="xhtml.block.text.module"> > <customer>Fred Jones</customer> > <comments> > <bl:p>Bought <bl:em>500</bl:em> units!</bl:p> > </comments> > </order> > > Note that I've moved the namespace definition down a level from > 'comments' because you wouldn't put it there. All you would need to do > would be to define in your schema that 'comments' can have > children from > the 'XHTML block text module'. (Quite why David M thinks each new > namespace should be at the 'comments' level is baffling me. A million > namespaces!?!) In other words, you won't be using 'strict', > 'transitional', or anything. In terms of post-parsing processing, in > this scenario a 'p' is a 'p' is a 'p' (as everyone wants, > albeit a bl:p > now, instead of a generic html:p). However, at the moment none of this > exists, although it is a stated goal of XHTML. (If you > haven't already, > have a look at the modularization document - it's very impressive.) <snip/> Mark, We're still in total agreement, except for the xmlns:bl="xhtml.block.text.module" piece. What I (and others) are saying is that the "xhtml.block.text.module" should be a *single* XHTML namespace right from the get-go; one single string, that any XML parser from now unto eternity can look at and say "this is XHTML". It can then, if it wishes, pass the XHTML pieces to an XHTML-specific application for rendering or whatever. If XHTML 1 brings three namespaces, then there are three strings we have to look for to determine if this is XHTML. If XHTML 1.1 or 2 brings XHTML back to just one flavour, then a new namespace will have to be introduced; now we have 4 namespaces that we'll have to look for. (One we'll be expecting, and two that are deprecated, but we'll still have to look for them just in case.) Even this wouldn't be <em>too</em> bad. <speculation inside-knowledge='none'>But I don't think that we'll end up with 4 namespaces. Unfortunately, as people keep pointing out, this is all PURE guesswork, but it looks like the XHTML group is leaning towards a namespace for every "module". (Say, one for XHTML tables, and one for XHTML frames, and one for XHTML paragraphs, and one for XHTML divs?...) This gets worse when things change; what if an element name in XHTML tables changes from XHTML 2 to XHTML 3? Well, *another* namespace will get invented, for the new version.</speculation> I understand the reasoning behind the XHTML group wanting three versions, to mirror the three versions of HTML 4. But I would like them to start, from the very beginning, to treat XHTML as various parts (modules) of *one vocabulary*. A vocabulary that could be identified by a single namespace, so that in the future, when integration of XHTML and other XML vocabularies is possible, it will also be easy to identify the XHTML pieces, so that they can be processed by our XHTML applications. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Thu Sep 2 15:06:40 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:35 2004 Subject: XHTML & Schemas References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> <001601bef53f$06d66050$4602a8c0@capella.co.il> Message-ID: <009601bef544$3c3a7d80$0300000a@cygnus.uwa.edu.au> > That's well and good, but we can't wait until the XSchema recommendation is > finalized. XHTML is due to be finalized much earlier, and as we've seen it > depends on what the decision in XSchema will be. I don't know how the W3C > process handles such a conflict. What will happen if XHTML makes a decision, > and the XSchema draft then changes so it no longer makes sense? Which is one reason why I think XHTML should perhaps go with zero namespaces for now and the W3C should address the broader issue ASAP. Although, it could be said that the W3C *has* addressed the issue and he has already made his mind up :-) James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Sep 2 15:11:17 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:35 2004 Subject: why distinctions within XHTML? In-Reply-To: <805C62F55FFAD1118D0800805FBB428D02BBFE39@cc20exch2.mobility.com> References: <805C62F55FFAD1118D0800805FBB428D02BBFE39@cc20exch2.mobility.com> Message-ID: <14286.30344.97663.274555@localhost.localdomain> Hunter, David writes: > I understand the reasoning behind the XHTML group wanting three > versions, to mirror the three versions of HTML 4. But I would like > them to start, from the very beginning, to treat XHTML as various > parts (modules) of *one vocabulary*. A vocabulary that could be > identified by a single namespace, so that in the future, when > integration of XHTML and other XML vocabularies is possible, it > will also be easy to identify the XHTML pieces, so that they can be > processed by our XHTML applications. I agree. In fact my argument is that a Namespace URI should be like a domain name -- it is the persistent, public face of a vocabulary. Microsoft might restructure their Web site tomorrow, but they'll probably still keep the microsoft.com domain name so that people can find the new site. Imagine if you had to choose between the following: microsoft-strict-1-0.com microsoft-transitional-1-0.com microsoft-frameset-1-0.com And then, after the redesign microsoft-1-1.com then microsoft-1-2.com then microsoft-2-0.com Microsoft can change their IP address and their internal structure as ofter as they like, but it's hard for people to find them if they change their domain name. Likewise, XHTML can change its DTDs/schemas, but will be very hard for deployed software to recognize XHTML if it keeps changing its Namespace URI. 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 ht at cogsci.ed.ac.uk Thu Sep 2 15:17:52 1999 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:14:35 2004 Subject: Fw: XHTML & Schemas In-Reply-To: "Oren Ben-Kiki"'s message of "Thu, 2 Sep 1999 13:44:44 +0200" References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> Message-ID: <f5b7lm9zbz9.fsf@cogsci.ed.ac.uk> Please note that everything to do with the connections between instances and XML Schema schemas and between one XML Schema schema and another is up for grabs within the WG at this time. The current WD should NOT be taken as definitive in this (or any other :-) area. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 15:22:13 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:14:35 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <93CB64052F94D211BC5D0010A800133170F094@wwmess3.bra01.icl.co.uk> > >Unlike the last XHTML Working Draft, this PR has reverted to defining > >*three* separate XHTML Namespace URIs (transitional, strict, and > >frameset) with the threat of more HTML Namespaces in the future. I seem to recall, at the time Namespaces was being debated, a lone voice saying that of course namespaces should be hierarchic rather than single-level. Shame that noone listened. 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 oren at capella.co.il Thu Sep 2 15:22:42 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:35 2004 Subject: XHTML & Schemas References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> <001601bef53f$06d66050$4602a8c0@capella.co.il> <009601bef544$3c3a7d80$0300000a@cygnus.uwa.edu.au> Message-ID: <002701bef545$2e17c1d0$4602a8c0@capella.co.il> James Tauber <jtauber@jtauber.com> wrote: > I wrote: > > That's well and good, but we can't wait until the XSchema recommendation > is > > finalized. XHTML is due to be finalized much earlier, and as we've seen it > > depends on what the decision in XSchema will be. I don't know how the W3C > > process handles such a conflict. What will happen if XHTML makes a > decision, > > and the XSchema draft then changes so it no longer makes sense? > > Which is one reason why I think XHTML should perhaps go with zero namespaces > for now and the W3C should address the broader issue ASAP. Although, it > could be said that the W3C *has* addressed the issue and he has already made > his mind up :-) Actually, that's a real worry. After all, how would we know about such a decision except for its expression in the various drafts? So far, the facts I'm aware of are consistent with the W3C deciding to go in the "namespace == schema" way, and are inconsistent with any other interpretation. It isn't as if we really expect someone at the W3C to send a message to this group saying "look, guys, stop arguing about this - we've made up our minds, and it will be <this> way.", right? The problem is that if they have made this decision, any request to change a specific draft would be ignored - since it would make it inconsistent with the system as a whole; and there's no easy way you could appeal the basic decision itself, since it isn't part of any draft. Could someone more knowledgeable of the W3C process shed some light on this? 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 Thu Sep 2 15:38:05 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:35 2004 Subject: XHTML & Schemas References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> <001601bef53f$06d66050$4602a8c0@capella.co.il> <009601bef544$3c3a7d80$0300000a@cygnus.uwa.edu.au> <002701bef545$2e17c1d0$4602a8c0@capella.co.il> Message-ID: <010901bef548$9f92c8c0$0300000a@cygnus.uwa.edu.au> > Actually, that's a real worry. After all, how would we know about such a > decision except for its expression in the various drafts? So far, the facts > I'm aware of are consistent with the W3C deciding to go in the "namespace == > schema" way, and are inconsistent with any other interpretation. Documents like Web Architecture: Extensible Languages http://www.w3.org/TR/NOTE-webarch-extlang and others at http://www.w3.org/DesignIssues/ provide some good insight into TimBL's thinking on these and related issues. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net <pipe>Ceci n'est pas une pipe</pipe> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 15:39:38 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:35 2004 Subject: why distinctions within XHTML? In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E8F47@sohos002.ied-suppor t.net> Message-ID: <4.1.19990902093928.03cd8ef0@mail.webgeek.com> At 02:41 AM 9/2/99 +0100, Mark Birbeck wrote: >My argument is that in the future, version >1 of XHTML will be >modularised and so you will actually do this: > ><order xmlns="myorderstuff" xmlns:bl="xhtml.block.text.module"> > <customer>Fred Jones</customer> > <comments> > <bl:p>Bought <bl:em>500</bl:em> units!</bl:p> > </comments> ></order> While that's certainly a possibility -- before anyone gets too excited (either way) over it, the modularization work isn't done, so we may see something like this, but we may not. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Thu Sep 2 15:40:58 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:35 2004 Subject: Fw: Fw: XHTML & Schemas Message-ID: <004201bef547$b101c940$4602a8c0@capella.co.il> Henry S. Thompson <ht@cogsci.ed.ac.uk> wrote: > Please note that everything to do with the connections between > instances and XML Schema schemas and between one XML Schema schema and > another is up for grabs within the WG at this time. The current WD > should NOT be taken as definitive in this (or any other :-) area. That's a relief :-) Well, they certainly will have an interesting time deciding this one. I just hope they'll do it in time to decide the matter in XHTML. 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 Mark.Birbeck at iedigital.net Thu Sep 2 15:41:56 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:35 2004 Subject: XHTML & Schemas Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F4C@sohos002.ied-support.net> Oren Ben-Kiki wrote: > I feel like a fool (that's OK, I'm used to it). I _assumed_ > that the matter of associating a namespace with a DTD/XSchemas > was not resolved. There certainly has been a lot of action going > on in this list about it, and bemoaning of the fact it wasn't > cleared anyway. [snip] > OK, I'm a fool - I should have gone to the spec before. I have some > mitigating circumstances - one being delivery deadlines, and > the other is the assumption that there wouldn't have been such a > fuss over this issue if it was resolved. Come on Oren, ... this is XML-DEV you're talking about :-) > And the consequences of this are so far reaching, and go > against so many deeply held positions expressed in this > mailing list - how did this remain hidden for so long? > Is it that people simply ignore XSchemas (as I did :-)? Nope. See my email below from Monday. I don't think I could have been any clearer. Whilst I don't want to say I told you so, I have to, just to restore my sanity (this last 'debate' has been close to bonkers on a number of occasions). > -----Original Message----- > From: Mark Birbeck > Sent: 30 August 1999 17:58 > To: XML-Dev Mailing list > Subject: RE: why distinctions within XHTML? > > > Simon St.Laurent wrote: > > It seems like DOCTYPE and the three DTDs should handle this > > without any problem. I can't figure out why you'd want to bring > > namespaces into this. I could write an editor that recognized the > > namespace and did processing based on the namespace, but I think > > DOCTYPE would be simpler. I don't think namespaces have to do > > this work. > > But what if you wanted to write an editor that left MathML > alone, or passed the MathML parts on to another application > or plug-in? You'd need to use XML Schemas because DTDs > couldn't handle that (your XHTML doc has just failed if it > has MathML in it!) and you'll need a namespace for that > (under current proposals). So, if you accept that you need > three DTDs, then to get into the world of XML Schemas (or > whatever it ends up being) you need three namespaces. > > Regards, > > Mark Birbeck > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 15:42:22 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:35 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <4.1.19990902094108.0426dc40@mail.webgeek.com> At 06:35 PM 9/1/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: >The DTDs map as follows: > strict No alignment, colors, framesets > frameset Alignment, colors, framesets > transitional Alignment, colors, no framesets There's more to the differences between strict and transitional than "alignment and color", though those are the easiest to point out, and these originated with HTML 4.0, not XHTML. <broken record type="OnlyTimeToday"> We're in phase 1, moving existing HTML 4.0 into XML. </broken record> Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 15:52:13 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:35 2004 Subject: Consensus and Petition for XHTML Namespaces In-Reply-To: <000001bef504$ccdd92e0$5a2bfea9@w21tp> Message-ID: <4.1.19990902094956.0427d1c0@mail.webgeek.com> At 10:34 PM 9/1/99 -0700, Don Park wrote: > Whether he follows >'our recommendation' for a change or not depends on whether he wants to >widen the controversy from XHTML to W3C. I'm sorry, but this is pretty amusing. If he doesn't accept the proposal, the W3C is even more of a big evil empire? Does xml-dev really think that their (fractured) group opinion should carry more weight than anything else? 330+ AC reps will be voting on this. This group's voice is but just one. > If the Director has >a preconceived bias on a critical issue, he can not make a fair decision. And you assume this based on what? Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Thu Sep 2 15:54:54 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:35 2004 Subject: ATTN: Please comment on XHTML (before it's too late) References: <93CB64052F94D211BC5D0010A800133170F094@wwmess3.bra01.icl.co.uk> Message-ID: <010b01bef54a$e803c9e0$0300000a@cygnus.uwa.edu.au> ----- Original Message ----- From: Kay Michael <Michael.Kay@icl.com> > I seem to recall, at the time Namespaces was being debated, a lone voice > saying that of course namespaces should be hierarchic rather than > single-level. Shame that noone listened. I confess I don't recall seeing this. But you may have noticed I suggested something similar in two recent posts. My idea was that you basically allow namespace URI matching on prefixes. So if you are interested in whether something is XHTML (but don't care about version) you match on "http://www.w3.org/xhtml", but if you care about version you match on something like "http://www.w3.org/xhtml1/strict". Perhaps this is what was originally suggested back during the first namespace war. Actually the current XSLT draft does something similar (see 2.5), but I don't know whether it will make it into the REC. Mind you, hierarchical organisation isn't that good a general solution as it forces you to prioritise axes. If you choose to make it possible to underspecify for strictness you can't then make it possible to underspecify for number, for example. From what I recall, that's why feature structures (at the time used in phonology) were introduced into syntax in the 1950s. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net <pipe>Ceci n'est pas une pipe</pipe> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 15:57:45 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:35 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <4.1.19990902094108.0426dc40@mail.webgeek.com> References: <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <199909021400.KAA16537@hesketh.net> At 09:43 AM 9/2/99 -0400, Ann Navarro wrote: ><broken record type="OnlyTimeToday"> >We're in phase 1, moving existing HTML 4.0 into XML. ></broken record> Get Phase 1 wrong, and there may not be any other phases - or those phases may be a heck of a lot harder to do. Introducing complexity at the start of a project is rarely a good idea, in my limited experience. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 oren at capella.co.il Thu Sep 2 16:05:54 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:36 2004 Subject: XHTML & Schemas References: <A26F84C9D8EDD111A102006097C4CD0D0E8F4C@sohos002.ied-support.net> Message-ID: <006f01bef54b$3e3f7110$4602a8c0@capella.co.il> Mark Birbeck <Mark.Birbeck@iedigital.net> wrote: > Oren Ben-Kiki wrote: > > OK, I'm a fool - I should have gone to the spec before. I have some > > mitigating circumstances - one being delivery deadlines, and > > the other is the assumption that there wouldn't have been such a > > fuss over this issue if it was resolved. > > Come on Oren, ... this is XML-DEV you're talking about :-) Well... still. And anyway, it does turn out that it is not resolved after all. > > And the consequences of this are so far reaching, and go > > against so many deeply held positions expressed in this > > mailing list - how did this remain hidden for so long? > > Is it that people simply ignore XSchemas (as I did :-)? > > Nope. See my email below from Monday. I don't think I could have been > any clearer. You are right, of course - I missed that, especially the "under current proposal" part. BTW, I must say I'm starting to think Simon St.Laurent's general approach to these issues is the right one - while fully appreciating that it does not seem to be the way the W3C is heading :-( > Whilst I don't want to say I told you so, I have to, just > to restore my sanity (this last 'debate' has been close to bonkers on a > number of occasions). Feel free; This mailing list does tend to get out of control at times (remember the unnecessary chaos about namespaces and attributes?) I'm fully willing to accept my well deserved share of slaps on the wrist. But hey, "you'll never learn anything unless you are willing to occasionally make a fool of yourself in public". I just hope not to make a habit of it. I still think using three namespaces is a bad idea :-) 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 ann at webgeek.com Thu Sep 2 16:13:09 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:36 2004 Subject: Fw: Fw: XHTML & Schemas In-Reply-To: <004201bef547$b101c940$4602a8c0@capella.co.il> Message-ID: <4.1.19990902101214.043419d0@mail.webgeek.com> At 03:33 PM 9/2/99 +0200, Oren Ben-Kiki wrote: > Well, they certainly will have an interesting time >deciding this one. I just hope they'll do it in time to decide the matter in >XHTML. I'm not sure where you're thinking that work in Schemas will determine the outcome of work in XHTML 1.0. XHTML 1.0 is silent on schemas -- conforming documents must validate against a DTD. Schemas will certainly impact continuing work, but we're not hinging anything in XHTML 1.0 on them. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 16:18:13 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:36 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <199909021400.KAA16537@hesketh.net> References: <4.1.19990902094108.0426dc40@mail.webgeek.com> <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <4.1.19990902101554.04278a70@mail.webgeek.com> At 10:03 AM 9/2/99 -0400, Simon St.Laurent wrote: >At 09:43 AM 9/2/99 -0400, Ann Navarro wrote: >><broken record type="OnlyTimeToday"> >>We're in phase 1, moving existing HTML 4.0 into XML. >></broken record> > >Get Phase 1 wrong, and there may not be any other phases - or those phases >may be a heck of a lot harder to do. What is so much harder to do if next it was said: Now that we're nice and tidy with XHTML 1.0, we move forward with a single flavor, be it <whatever one is chosen>, and we modularize that, and extend that? Ann (not representing any group's position or direction) --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From oren at capella.co.il Thu Sep 2 16:22:03 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:36 2004 Subject: Fw: Fw: XHTML & Schemas References: <4.1.19990902101214.043419d0@mail.webgeek.com> Message-ID: <007f01bef54d$6e9aacb0$4602a8c0@capella.co.il> Ann Navarro <ann@webgeek.com> wrote: > I'm not sure where you're thinking that work in Schemas will determine the > outcome of work in XHTML 1.0. > > XHTML 1.0 is silent on schemas -- conforming documents must validate > against a DTD. > > Schemas will certainly impact continuing work, but we're not hinging > anything in XHTML 1.0 on them. Surely you wouldn't place something in the recommendation which is known to contradict the XSchema WG decisions? Concretely, as long as the XSchema WG keeps the "namespace == schema" rule, I don't see how you can decide to use just one namespace for XHTML (much as I would like you to) - unless you are betting they'll change this rule in the future. 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 ann at webgeek.com Thu Sep 2 16:39:36 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:36 2004 Subject: Fw: Fw: XHTML & Schemas In-Reply-To: <007f01bef54d$6e9aacb0$4602a8c0@capella.co.il> References: <4.1.19990902101214.043419d0@mail.webgeek.com> Message-ID: <4.1.19990902104039.04417c80@mail.webgeek.com> At 04:14 PM 9/2/99 +0200, Oren Ben-Kiki wrote: >Surely you wouldn't place something in the recommendation which is known to >contradict the XSchema WG decisions? Concretely, as long as the XSchema WG >keeps the "namespace == schema" rule, I don't see how you can decide to use >just one namespace for XHTML But we haven't :) Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Sep 2 16:39:19 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:36 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <4.1.19990902101554.04278a70@mail.webgeek.com> References: <199909021400.KAA16537@hesketh.net> <4.1.19990902094108.0426dc40@mail.webgeek.com> <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <199909021442.KAA18395@hesketh.net> At 10:18 AM 9/2/99 -0400, Ann Navarro wrote: >What is so much harder to do if next it was said: Now that we're nice and >tidy with XHTML 1.0, we move forward with a single flavor, be it <whatever >one is chosen>, and we modularize that, and extend that? If I a) believed that was in fact the group's direction and b) believed it would be possible, once three namespaces had been unleashed and software written I might think that in fact it wouldn't be so difficult, and that this three-vs.-one issue was just a minor curve in the road. Unfortunately, I doubt a, and my doubt in b makes a pretty irrelevant anyway. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 artcube at hotmail.com Thu Sep 2 16:41:47 1999 From: artcube at hotmail.com (Rob Rightmyer) Date: Mon Jun 7 17:14:36 2004 Subject: unsubscribe Message-ID: <19990902144358.34418.qmail@hotmail.com> unsubscribe ______________________________________________________ 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 oren at capella.co.il Thu Sep 2 16:44:36 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:36 2004 Subject: Fw: Fw: XHTML & Schemas References: <4.1.19990902101214.043419d0@mail.webgeek.com> <4.1.19990902104039.04417c80@mail.webgeek.com> Message-ID: <00b201bef550$97e33030$4602a8c0@capella.co.il> Ann Navarro <ann@webgeek.com> wrote: > At 04:14 PM 9/2/99 +0200, Oren Ben-Kiki wrote: > >Surely you wouldn't place something in the recommendation which is known to > >contradict the XSchema WG decisions? Concretely, as long as the XSchema WG > >keeps the "namespace == schema" rule, I don't see how you can decide to use > >just one namespace for XHTML > > But we haven't :) Fine, but you can no longer claim that XSchema WG decisions have no effect on the XHTML WG... Which is why I said I hope they'll settle it soon - so you could :-) 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 simonstl at simonstl.com Thu Sep 2 16:56:10 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:36 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <4.1.19990902094956.0427d1c0@mail.webgeek.com> References: <000001bef504$ccdd92e0$5a2bfea9@w21tp> Message-ID: <199909021459.KAA19140@hesketh.net> [Please tune out if you have no interest in the relationship between W3C and the xml-dev mailing list] At 09:52 AM 9/2/99 -0400, Ann Navarro wrote: >I'm sorry, but this is pretty amusing. If he doesn't accept the proposal, >the W3C is even more of a big evil empire? Does xml-dev really think that >their (fractured) group opinion should carry more weight than anything >else? More weight than anything else? Certainly not. Some weight? Wouldn't it be nice to think so. XML-dev is 'just' an open mailing list, but it does appear to be the communications center of a large portion of the XML community, for better or worse, and an important reference even for those who don't participate. While the W3C's charter doesn't suggest that it _has_ to listen to user community opinion outside of the bounds of its paid membership, it might do well both to listen and to make clear that it is listening - for PR, if nothing else. It would make it a lot harder to describe the W3C as a closed 'evil empire' if in fact that were the case. XML-dev has made significant contributions - or so various W3C-affiliated folks have said repeatedly. Pounding on XML-dev, as appears to be happening above, seems unconstructive at best and provocative at worst. >330+ AC reps will be voting on this. This group's voice is but just one. Actually, this group's voice is zero, per W3C voting rules. Of course, given that all power rests with the Director anyway, it seems reasonable to question how much power those 330+ AC reps have anyway. >> If the Director has >>a preconceived bias on a critical issue, he can not make a fair decision. > >And you assume this based on what? It seems to be a recurring theme in this discussion, though no one has stated it explicitly - perhaps for fear of running afoul of W3C process. The change was rather sudden, and rather large for a PR. Rumors and innuendo, in the absence of a public rationale, are as close to 'fact' as we're going to get. Don't like it? Open the doors and say what's really going on! Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 Thu Sep 2 17:07:02 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:36 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F4E@sohos002.ied-support.net> Ann Navarro wrote: > Sent: 02 September 1999 15:18 > To: Simon St.Laurent; xml-dev@ic.ac.uk > Subject: RE: How about over 1,000,000 XHTML Namespace URIs? > > > At 10:03 AM 9/2/99 -0400, Simon St.Laurent wrote: > >At 09:43 AM 9/2/99 -0400, Ann Navarro wrote: > >><broken record type="OnlyTimeToday"> > >>We're in phase 1, moving existing HTML 4.0 into XML. > >></broken record> > > > >Get Phase 1 wrong, and there may not be any other phases - > or those phases > >may be a heck of a lot harder to do. > > What is so much harder to do if next it was said: Now that > we're nice and > tidy with XHTML 1.0, we move forward with a single flavor, be > it <whatever > one is chosen>, and we modularize that, and extend that? I agree with the stages - that's why I have been drawing a distinction between tidyHTML and futureHTML. However, don't you do need to leave the three legacy formats intact? I'd have thought that any modularisation and extension has to be to a brand new set of namespaces, not an evolution of one of the current three. Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From brad.arseneau at ac.com Thu Sep 2 17:07:06 1999 From: brad.arseneau at ac.com (brad.arseneau@ac.com) Date: Mon Jun 7 17:14:36 2004 Subject: unsubscribe Message-ID: <862567E0.00529BC8.00@amrhm1101.ac.com> unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 17:15:59 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:36 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <199909021459.KAA19140@hesketh.net> References: <4.1.19990902094956.0427d1c0@mail.webgeek.com> <000001bef504$ccdd92e0$5a2bfea9@w21tp> Message-ID: <4.1.19990902111620.04449e60@mail.webgeek.com> At 11:02 AM 9/2/99 -0400, Simon St.Laurent wrote: >Don't like it? Open the doors and say what's really going on! The HTML Working Group, comprised of nearly two dozen individuals, reached a state of agreement suitable for the chair (who determines what is or is not consensus), and made a change. Period. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 17:27:58 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:36 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E8F4E@sohos002.ied-suppor t.net> Message-ID: <4.1.19990902112751.04449880@mail.webgeek.com> At 04:00 PM 9/2/99 +0100, Mark Birbeck wrote: >I agree with the stages - that's why I have been drawing a distinction >between tidyHTML and futureHTML. However, don't you do need to leave the >three legacy formats intact? I'd have thought that any modularisation >and extension has to be to a brand new set of namespaces, not an >evolution of one of the current three. We have, in XHTML 1.0, which is what we were mandated to do. However, moving forward from HTML 4.0, which is what the future work in XHTML does, isn't necessarily bound. Ann (again, not speaking as to any specific opinion or direction of the Group) --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu Sep 2 18:00:17 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:36 2004 Subject: XHTML & Schemas References: <37CD441A.1FF39F6E@prescod.net> <002001bef4e3$19ad64a0$0300000a@cygnus.uwa.edu.au> Message-ID: <37CE8C54.50138CFB@prescod.net> James Tauber wrote: > > ----- Original Message ----- > From: Paul Prescod <paul@prescod.net> > > Namespaces are triggers for various things. Stylesheets, validators, > > etc. > > Up until I changed my mind about this premise, I agreed completely with both > your three-namespace conclusion and your actual argument for it. > > However, I no longer agree with the premise above as stated. Namespaces are > for distinguishing element/attribute vocabularies within an instance. I disagree on two fronts. First, namespaces are for distinguishing element/attribute vocabularies *across* instances. The whole point is that I could (one day) take some XHTML content and put it in an instance that is not entirely an XHTML document. > A corollary to this is that *something else* (perhaps in conjunction with > namespaces) must trigger stylesheets, validators, etc. I would like to see a > solution proposed for that---soon, if at all possible. I don't follow this at all. What is the value in namespaces if they cannot be used in style rules, schema rules and other such name-triggered processes. XSLT and XSchema *already* use them as triggers. Do you claim that this is an abuse? David's whole argument is that three namespaces make it more difficult to use namespaces as triggers because you must now trigger on three names instead of one. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From edd at usefulinc.com Thu Sep 2 18:18:46 1999 From: edd at usefulinc.com (Edd Dumbill) Date: Mon Jun 7 17:14:36 2004 Subject: Why namespaces? In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E8F48@sohos002.ied-support.net>; from Mark Birbeck on Thu, Sep 02, 1999 at 02:58:54AM +0100 References: <A26F84C9D8EDD111A102006097C4CD0D0E8F48@sohos002.ied-support.net> Message-ID: <19990902162106.G32545@heddley.com> On Thu, Sep 02, 1999 at 02:58:54AM +0100, Mark Birbeck wrote: > > Namespaces (by my reading of the spec) are for distinguishing > > element/attribute vocabularies *within an instance*. > > Not so. My server might receive this: > > <com:delete> > <u:user> > <u:name>Mark</u:name> > </u:user> > </com:delete> > > and then five minutes later receive this: > > <com:delete> > <c:computer> > <c:name>laptop</c:name> > </c:computer> > </com:delete> > > By your reckoning the fact that the first document has 'com' and 'u' > distinct, and the second has 'com' and 'c' distinct is fine. But what if > the first delete instruction simply referred to removing the user > profile, and not the user? In other words, the two 'delete' nodes might > be in different namespaces and do different things, even though they are > not in the same document. My server would surely want to know which > namespace they occupied. Namespaces (by my reading of the spec) are for > distinguishing element/attribute vocabularies *within the whole world*. >From my reading of your post it seems to be confusing the prefix with the namespace itself. The namespace URI reference identifies the namespace. So, yes, namespaces can be used to distinguish vocabularies globally, put prefixes can't. So in the first example you have in an attribute of a containing element: xmlns:com="http://foo.bar.org/commands/onesense" and the second xmlns:com="http://foo.bar.org/commands/anothersense" Therefore implementations shouldn't assume anything from a prefix, but derive their meaning from the namespace prefix binding. Indeed as I understand it you can reuse a prefix within an instance, but bound to a different namespace. It seems to me that the annoyance is arising because DTDs clearly are no longer sufficient to distinguish sets of elements as namespaces allow elements with distinct definitions to be mixed in one instance. This seems to be the motivation from the XHTML side of things. It is clearly a goal of XHTML to allow inclusion of other XML namespaces in a document, therefore XHTML ought to define the namespace within which it sits. And since, in HTML4 there are three DTDs which describe distinct flavors, three namespaces are required. It is up to the application (not the parser) how they treat the three XHTML namespaces, but the distinction ought to be preserved until the application level. James Tauber said: > >"we would only need separate namespaces for each flavour of > > XHTML if people are going to want to mix the three flavours > > in the one document and distinguish the different usages > > of the element/attributes names in the intersection." Which is right. It seems to be a clear aim of the XHTML PR that this mixing be permitted for any XML namespace. So whether three namespaces are required depends on whether you believe that a namespace infers a definition by which you can validate. Oren Ben-Kiki says: > "Concretely, as long as the XSchema WG keeps the "namespace == schema" > rule, I don't see how you can decide to use just one namespace for > XHTML (much as I would like you to)" So, if a namespace does indeed == a schema then we need three of them. The implication of this to me seems to be nothing less than the ultimate replacement of the DTD declaration by the namespace declaration. > Mark I _think_ I've ended up in a 3-namespace mood. regards -- Edd Dumbill ------/ a new media consultant, writer & technologist /-- | Director, Useful Information Company <http://usefulinc.com> | Internet Director, Pharmalicensing <http://pharmalicensing.com> : UK voice/msg: +44 702-093-6870 UK fax: +44 870-164-0230 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 18:19:47 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:36 2004 Subject: XHTML & Schemas Message-ID: <3.0.32.19990902091712.01764460@pop.intergate.bc.ca> At 03:15 PM 9/2/99 +0200, Oren Ben-Kiki wrote: >Actually, that's a real worry. After all, how would we know about such a >decision except for its expression in the various drafts? So far, the facts >I'm aware of are consistent with the W3C deciding to go in the "namespace == >schema" way, and are inconsistent with any other interpretation. I assure you, this question is very much open. Open not only in the sense of "no decision's been taken" but open in the sense that "no obvious consensus has yet emerged." -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 Sep 2 18:19:47 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:36 2004 Subject: Fw: Fw: XHTML & Schemas Message-ID: <3.0.32.19990902092034.01763570@pop.intergate.bc.ca> At 10:13 AM 9/2/99 -0400, Ann Navarro wrote: >Schemas will certainly impact continuing work, but we're not hinging >anything in XHTML 1.0 on them. Er, well, actually, from what you've posted earlier, I thought the idea that namespaces and schemas map one-to-one was one of the primary justifications for the use of 3 namespaces in XHTML. And for the record, I think the idea that namespaces are in an identity relationship with schemas is just hopelessly broken. But that's another debate. -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 Thu Sep 2 18:22:07 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:36 2004 Subject: XHTML & Schemas References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> Message-ID: <37CE9599.69475C4D@prescod.net> David Megginson wrote: > > > The quoted section 4.1 of the XSchema draft seems to directly > > contradict his view of what's right, so XML did not "get it > > right". Am I missing something again? > > Yes -- XML-Schema is not XML. XML-Schema is (currently) getting it > wrong, but they're in the early drafts, so I still hope for their > redemption. I don't know what you are talking about. A schema rule is inherently triggered based on hooks within the document. What could be a more natural hook than the universal name for an element type? This isn't saying that an element type is necessarily defined by a schema. It is saying that a schema rule is triggered by an element type. ...seems logical to me... Among other things, it fits hedge automata theory perfectly. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Sep 2 18:39:03 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:36 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <4.1.19990902111620.04449e60@mail.webgeek.com> References: <199909021459.KAA19140@hesketh.net> <4.1.19990902094956.0427d1c0@mail.webgeek.com> <000001bef504$ccdd92e0$5a2bfea9@w21tp> Message-ID: <199909021641.MAA24156@hesketh.net> At 11:17 AM 9/2/99 -0400, Ann Navarro wrote: >At 11:02 AM 9/2/99 -0400, Simon St.Laurent wrote: >>Don't like it? Open the doors and say what's really going on! > >The HTML Working Group, comprised of nearly two dozen individuals, reached >a state of agreement suitable for the chair (who determines what is or is >not consensus), and made a change. > >Period. I'll take that as 'No comment', as the process document for the W3C already indicates that what you describe above must have happened, and as that description provides no further light on a complicated question. The doors are still tightly closed, as far as I can tell, with no likelihood in the near future of light coming through. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 oren at capella.co.il Thu Sep 2 18:40:21 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:36 2004 Subject: XHTML & Schemas References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> <37CE9599.69475C4D@prescod.net> Message-ID: <010401bef560$c66cb0b0$4602a8c0@capella.co.il> Paul Prescod <paul@prescod.net> wrote: > ... A schema rule is inherently > triggered based on hooks within the document. What could be a more > natural hook than the universal name for an element type? A DOCTYPE element :-) 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 wunder at infoseek.com Thu Sep 2 18:45:05 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:14:36 2004 Subject: XHTML & Schemas In-Reply-To: <002001bef4e3$19ad64a0$0300000a@cygnus.uwa.edu.au> References: <37CD441A.1FF39F6E@prescod.net> Message-ID: <3.0.5.32.19990902094345.03cfe860@corp.infoseek.com> At 09:29 AM 9/2/99 +0800, James Tauber wrote: > >A corollary to this is that *something else* (perhaps in conjunction with >namespaces) must trigger stylesheets, validators, etc. I would like to see a >solution proposed for that---soon, if at all possible. Perhaps an instruction to the application processing the document? XML 1.0 does not support modules. XHTML is a modular design. It's gonna look ugly in XML 1.0. So we're discussing *which* ugly workaround to use. Every solution is going to have big problems. My design eperience tells me to put in a version number and avoid multiplying entities unnecessarily. Whether that means PI's or three namespaces, or what, I can't tell yet. But when or if we have an XML that supports modules, the legacy code and the QA test cases for XHTML 1.0 shouldn't be a long-lived albatross. One way to decide between approaches is to implement some real systems and see which one works best, both for the software and for the people. Of course, that takes time. So, what is the rush to get a recommendation for XHTML 1.0 done? If the underlying support (modules, schemas) isn't there yet, why not wait? I see folks successfully using XML for structure and translating to HTML for presentation, but I don't seen a lot of folks who need both in the same document this year. How many people here need an XHTML recommendation Real Soon Now? Here at the search engine mines, we don't need a format until someone else uses it. wunder -- Walter R. Underwood wunder@infoseek.com wunder@best.com (home) http://software.infoseek.com/cce/ (my product) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Sep 2 18:45:27 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:36 2004 Subject: Whitespace in XML Message-ID: <199909021648.MAA24428@hesketh.net> I'm writing a chapter (yes, a full chapter, though a short one) on whitespace handling in XML. While not as complicated or controversial as namespaces, whitespace handling has some intriguing features of its own. If anyone has particular concerns about whitespace or has found something in the spec that feels like a neat trick or possible problem, please let me know privately. So far, I'm covering: Whitespace in declarations Whitespace in element content Whitespace in mixed content End-of-Line Handing Ways to sneak in #xD xml:space Implications for applications and stylesheets Thanks! Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 18:48:59 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:36 2004 Subject: Fw: Fw: XHTML & Schemas In-Reply-To: <3.0.32.19990902092034.01763570@pop.intergate.bc.ca> Message-ID: <4.1.19990902124808.045271e0@mail.webgeek.com> At 09:22 AM 9/2/99 -0700, Tim Bray wrote: >At 10:13 AM 9/2/99 -0400, Ann Navarro wrote: >>Schemas will certainly impact continuing work, but we're not hinging >>anything in XHTML 1.0 on them. > >Er, well, actually, from what you've posted earlier, I thought the >idea that namespaces and schemas map one-to-one was one of the primary >justifications for the use of 3 namespaces in XHTML. Well, yes, though from that viewpoint it's not just schemas, but DTDs, or any other defining mechanism. So -- in that sense, we're not pinned squarely on schemas. The one to one mapping is just one aspect of the argument on how many namespaces to use. >And for the record, I think the idea that namespaces are in an >identity relationship with schemas is just hopelessly broken. But >that's another debate. Yes it is :) Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 18:50:29 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:36 2004 Subject: XHTML & Schemas In-Reply-To: <3.0.32.19990902091712.01764460@pop.intergate.bc.ca> Message-ID: <4.1.19990902125046.04522270@mail.webgeek.com> At 09:22 AM 9/2/99 -0700, Tim Bray wrote: >At 03:15 PM 9/2/99 +0200, Oren Ben-Kiki wrote: >>Actually, that's a real worry. After all, how would we know about such a >>decision except for its expression in the various drafts? So far, the facts >>I'm aware of are consistent with the W3C deciding to go in the "namespace == >>schema" way, and are inconsistent with any other interpretation. > >I assure you, this question is very much open. Open not only in the sense >of "no decision's been taken" but open in the sense that "no obvious >consensus has yet emerged." -Tim On that, we're definitely in agreement. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 19:00:30 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:36 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <199909021641.MAA24156@hesketh.net> References: <4.1.19990902111620.04449e60@mail.webgeek.com> <199909021459.KAA19140@hesketh.net> <4.1.19990902094956.0427d1c0@mail.webgeek.com> <000001bef504$ccdd92e0$5a2bfea9@w21tp> Message-ID: <4.1.19990902125831.04533b20@mail.webgeek.com> At 12:43 PM 9/2/99 -0400, Simon St.Laurent wrote: >I'll take that as 'No comment', as the process document for the W3C already >indicates that what you describe above must have happened, and as that >description provides no further light on a complicated question. What do you want me to say, Simon? That Foo Corp's representative gave a 30 minute dissertation on why we should have three namespaces, that Bar, Inc's representative screamed at him for another 20 minutes, stomping out before lunch calling him a pin-head, the rest of us broke out into a scene worthy of the best bar-room brawl, and the victor was declared three namespaces based on who's clothing was the most intact at the end? Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu Sep 2 19:06:38 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:36 2004 Subject: XHTML & Schemas References: <37CD441A.1FF39F6E@prescod.net> <010b01bef530$fddbd330$4602a8c0@capella.co.il> Message-ID: <37CE9CE0.58B3AF87@prescod.net> Oren Ben-Kiki wrote: > > For example, you yourself have said: > > > By this reasoning, it doesn't matter how many different name-space > > prefixes XHTML uses because *none of them* give you a way to know that > > what you are processing is in fact an XHTML document (or XHTML-specific > > element). Rather, the binding between documents and their *governing > > semantic definitions* (e.g., schemas, architectures, etc.) must be > > provided by some other mechanism. In the absence of a generalized > > mechanism for doing this binding, it can only be done in documentation > > of the semantics. > > Which, is, of course, a direct contradiction of thee above. Do I write like that?? Don't answer that question! The truth is that that's Eliot's writing. I forwarded it to the list for him. The schema specification does in fact say that schemas are triggered by namespaces. > Their example even shows the namespace URI as pointing to the schema - but > another paragraph in the same spec indicates that the processor does not > necessarily uses this URI to download the schema. At any rate... The idea of having namespace URIs be triggers is logical and (I thought) uncontroversial. Fetching schemas THROUGH namespace URIs is in fact very controversial. But those are different issues. > At any rate, as you've pointed out, the XSchema approach _requires_ the > XHTML use of three namespaces. The fact that I don't like it - and that many > others don't like it - is besides the point. If people want to have a single > namespace for XHTML, they should first go and re-write the above paragraph > in the XSchema draft. Right? What would you rewrite it to? Let's say you have three schemas for XHTML on your hard drive or on the web. Let's say that you have a document like this: <MYDOC> <P xmlns="http://www.w3.org/TR/XHTML">This is supposed to be loose.</P> <P xmlns="http://www.w3.org/TR/XHTML">This is supposed to be strict.</P> </MYDOC> How would you select the schema to use for each? I agree with you and David for the schema specification to say that given a namespace URI the schema to fetch is hard-wired. But that wasn't my point. It was the opposite: there must be AT LEAST enough information in the document to *allow* the namespace processor to select a schema. If yours chooses to select a different one than mine then that is fine. If we do not put enough information in our documents for schema processors to know that we really meant for the data to be strict then they wil have to presume loose...right? Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From BMurri at wavephore.net Thu Sep 2 19:15:47 1999 From: BMurri at wavephore.net (Blair Murri) Date: Mon Jun 7 17:14:36 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? Message-ID: <31AA4BE99284D211B47A006008172E20016EA1@MAILMAN> > -----Original Message----- > From: Ann Navarro [SMTP:ann@webgeek.com] > Sent: Thursday, September 02, 1999 8:18 AM > To: Simon St.Laurent; xml-dev@ic.ac.uk > Subject: RE: How about over 1,000,000 XHTML Namespace URIs? > > At 10:03 AM 9/2/99 -0400, Simon St.Laurent wrote: > >At 09:43 AM 9/2/99 -0400, Ann Navarro wrote: > >><broken record type="OnlyTimeToday"> > >>We're in phase 1, moving existing HTML 4.0 into XML. > >></broken record> > > > >Get Phase 1 wrong, and there may not be any other phases - or those > phases > >may be a heck of a lot harder to do. > > What is so much harder to do if next it was said: Now that we're nice and > tidy with XHTML 1.0, we move forward with a single flavor, be it <whatever > one is chosen>, and we modularize that, and extend that? > > Ann (not representing any group's position or direction) > The problem is this. If this PR makes it to REC, people will likely use it. And if the use it, as it is currently written, the poor saps out there (read: us) will be forced to support it. Then, when the next rev is written, what was written to this rev will still be out there, and we will continue to need to support it. It is an implementation that seems to benefit very few at the cost of a lot of others. I have a question. Since the current PR doesn't allow mixing of a bunch of stuff, and because most HTML documents can only be rendered one way anyhow, why not disallow more than one flavor of HTML v.4 in a doc? Declare which DTD to use (strict, transitional, or frameset) and be done with it. Either 0 or 1 namespaces would be needed, and the flaws that so many are so enraged about will be avoided. You are still free to do in v.2 anything that is still open now (nothing is lost, except the ability to use grammer from more than one flavor of HTML in the same document at a time - something of marginal value at best, given the inability to mix XHTML with other stuff anyway). Blair L. Murri Sr. Programmer/etc. WavePhore, Inc. (speaking personally and not representing anyone's views but my own) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 19:18:46 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:36 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <4.1.19990902125831.04533b20@mail.webgeek.com> References: <199909021641.MAA24156@hesketh.net> <4.1.19990902111620.04449e60@mail.webgeek.com> <199909021459.KAA19140@hesketh.net> <4.1.19990902094956.0427d1c0@mail.webgeek.com> <000001bef504$ccdd92e0$5a2bfea9@w21tp> Message-ID: <199909021721.NAA26075@hesketh.net> At 01:01 PM 9/2/99 -0400, Ann Navarro wrote: >At 12:43 PM 9/2/99 -0400, Simon St.Laurent wrote: >>I'll take that as 'No comment', as the process document for the W3C already >>indicates that what you describe above must have happened, and as that >>description provides no further light on a complicated question. > >What do you want me to say, Simon? > >That Foo Corp's representative gave a 30 minute dissertation on why we >should have three namespaces, that Bar, Inc's representative screamed at >him for another 20 minutes, stomping out before lunch calling him a >pin-head, the rest of us broke out into a scene worthy of the best bar-room >brawl, and the victor was declared three namespaces based on who's clothing >was the most intact at the end? No - I'd like an explanation of _why_ three namespaces was held by consensus to be a better idea than one namespace. If that requires releasing the minutes, I wouldn't mind, but I doubt seriously that the decision was based on the relative lack of clothing on various participants. Basically, the draft changed suddenly - and did so in a move between Working Draft and Proposed Recommendation, which suggests that something more than a fight between Foo and Bar is the cause. Reading between the lines on this list also suggests that something is awry, though no one will state publicly what happened. If you want to put to rest the claims about 'autocratic evil empires', providing a good _public_ explanation would be a very good step. On the other hand, if you enjoy being part of the 'evil empire', the non-explanation you provided is great. Does the W3C public relations office handle community relations at all? Maybe they should be made aware of a growing credibility gap. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 19:20:56 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:36 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <31AA4BE99284D211B47A006008172E20016EA1@MAILMAN> Message-ID: <4.1.19990902132037.0452b4c0@mail.webgeek.com> At 11:18 AM 9/2/99 -0600, Blair Murri wrote: > > I have a question. Since the current PR doesn't allow mixing of a bunch of > stuff, and because most HTML documents can only be rendered one way anyhow, > why not disallow more than one flavor of HTML v.4 in a doc? Declare which > DTD to use (strict, transitional, or frameset) and be done with it. I'm confused -- where do we allow more than one flavor of HTML 4.0 in a single doc? Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dave at userland.com Thu Sep 2 19:22:37 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:14:36 2004 Subject: XML-RPC interface for discussion groups Message-ID: <08cc01bef568$8cf36d80$1618ccce@pebbles> This document describes the XML-RPC interface implemented by UserLand discussion groups. http://www.xmlrpc.com/discuss/msgReader$181 With a compatible editor you can easily create and edit web pages with workstation editors that are not browser based. It's a way, thru scripting, to work around limits in the browser as an editing environment, without giving up the convenience of direct-connect thru HTTP. Support is in development, in the community, for Emacs, BBEdit, AppleScript, ShockWave and Windows COM-compatible editors such as MS-Word, and no doubt others. We are also working with other discussion group software vendors to support this specification. For UserLand, this is the back-end for our editorial groupware system, and a new web writer's tool we have in development. But the interface can be used for all kinds of workflow and groupware. The more the merrier! Dave Winer UserLand Software xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 2 19:23:36 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:37 2004 Subject: XHTML & Schemas References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> <37CE9599.69475C4D@prescod.net> Message-ID: <37CEB302.46384C4@pacbell.net> Paul Prescod wrote: > > David Megginson wrote: > > > > > The quoted section 4.1 of the XSchema draft seems to directly > > > contradict his view of what's right, so XML did not "get it > > > right". Am I missing something again? > > > > Yes -- XML-Schema is not XML. XML-Schema is (currently) getting it > > wrong, but they're in the early drafts, so I still hope for their > > redemption. > > I don't know what you are talking about. A schema rule is inherently > triggered based on hooks within the document. What could be a more > natural hook than the universal name for an element type? Any declaration (element, PI, etc) about the schema that the document creator intended to apply! Inferring semantics is typically a lose. An issue is that the schema DRAFT (!) is saying that the namespace REC (!) was wrong -- schema is saying namespaces are for more than disambiguating names, the REC says otherwise. We may have a fully unambiguous notion of who "Henry" is ... but that won't normally be placing limits on where we might run into him! - 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 BMurri at wavephore.net Thu Sep 2 19:29:41 1999 From: BMurri at wavephore.net (Blair Murri) Date: Mon Jun 7 17:14:37 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? Message-ID: <31AA4BE99284D211B47A006008172E20016EA2@MAILMAN> > -----Original Message----- > From: Ann Navarro [SMTP:ann@webgeek.com] > Sent: Thursday, September 02, 1999 11:21 AM > To: Blair Murri > Cc: xml-dev@ic.ac.uk > Subject: RE: How about over 1,000,000 XHTML Namespace URIs? > > At 11:18 AM 9/2/99 -0600, Blair Murri wrote: > > > > I have a question. Since the current PR doesn't allow mixing of a bunch > of > > stuff, and because most HTML documents can only be rendered one way > anyhow, > > why not disallow more than one flavor of HTML v.4 in a doc? Declare > which > > DTD to use (strict, transitional, or frameset) and be done with it. > > I'm confused -- where do we allow more than one flavor of HTML 4.0 in a > single > doc? > > Ann > > OK. I don't know if currently multiple flavors of HTML are allowed in an XHTML v.1 doc. But, in my mind, that is about the only reason I can think of for needing multiple namespaces for each flavor. Validation is being done with DTDs, you yourself said. My understanding is that you declare the DTD to use and go. What advantage is gained by using seperate namespaces? I don't see it, and the arguments on this mail-list haven't pointed this out to me (unless it was to allow multiple flavors in the same doc). Blair L. Murri Sr. Programmer/etc. WavePhore, Inc. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Thu Sep 2 19:34:38 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:37 2004 Subject: XHTML & Schemas Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFE50@cc20exch2.mobility.com> > From: Paul Prescod [mailto:paul@prescod.net] > Sent: Thursday, September 02, 1999 11:51 AM > > <MYDOC> > <P xmlns="http://www.w3.org/TR/XHTML">This is supposed to be > loose.</P> > <P xmlns="http://www.w3.org/TR/XHTML">This is supposed to be > strict.</P> > </MYDOC> > > How would you select the schema to use for each? Why not <MYDOC> <P xmlns="http://www.w3.org/TR/XHTML"><?xhtml mode='loose'?>This is supposed to be loose.</P> <P xmlns="http://www.w3.org/TR/XHTML"><?xhtml mode='strict'?>This is supposed to be strict.</P> </MYDOC> We all agree that PIs are visibly ugly, but in this case, the way some of us are proposing the XHTML group moves forward [one namespace, now and forever], they're doing exactly what we want them to do: giving instructions to the processor. If the processing instruction gets left out, let the application default it to loose, or whatever it chooses. In the future, if XHTML gets consolidated to one flavour, we would a) still only have one namespace - easier to denote XHTML in other XML documents b) have processing instructions in our legacy XHTML documents, so that future XHTML applications would be able to tell, if they cared David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 19:36:27 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:37 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <199909021721.NAA26075@hesketh.net> References: <4.1.19990902125831.04533b20@mail.webgeek.com> <199909021641.MAA24156@hesketh.net> <4.1.19990902111620.04449e60@mail.webgeek.com> <199909021459.KAA19140@hesketh.net> <4.1.19990902094956.0427d1c0@mail.webgeek.com> <000001bef504$ccdd92e0$5a2bfea9@w21tp> Message-ID: <4.1.19990902133608.045311a0@mail.webgeek.com> At 01:24 PM 9/2/99 -0400, Simon St.Laurent wrote: >If you want to put to rest the claims about 'autocratic evil empires', >providing a good _public_ explanation would be a very good step. On the >other hand, if you enjoy being part of the 'evil empire', the >non-explanation you provided is great. There's no giant surprise lurking anywhere. The same arguments we're having here about the use and appropriateness of namespaces in general occur (probably) within every Working Group -- yes, that makes a case for further work there, but it's not something the *HTML Working Group* is going to be chartered to solve. If you'll recall, the group's *original* draft had 3, we, for a time, went to 1, but reversed ourselves back to the original position. No Hand of God action there. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Sep 2 19:49:16 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:37 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <4.1.19990902133608.045311a0@mail.webgeek.com> References: <199909021721.NAA26075@hesketh.net> <4.1.19990902125831.04533b20@mail.webgeek.com> <199909021641.MAA24156@hesketh.net> <4.1.19990902111620.04449e60@mail.webgeek.com> <199909021459.KAA19140@hesketh.net> <4.1.19990902094956.0427d1c0@mail.webgeek.com> <000001bef504$ccdd92e0$5a2bfea9@w21tp> Message-ID: <199909021751.NAA27316@hesketh.net> At 01:37 PM 9/2/99 -0400, Ann Navarro wrote: >There's no giant surprise lurking anywhere. The same arguments we're having >here about the use and appropriateness of namespaces in general occur >(probably) within every Working Group -- yes, that makes a case for further >work there, but it's not something the *HTML Working Group* is going to be >chartered to solve. > >If you'll recall, the group's *original* draft had 3, we, for a time, went >to 1, but reversed ourselves back to the original position. > >No Hand of God action there. Okay, I'll keep that in mind the next time a Proposed Recommendation shows enormous differences between its content and the previous Working Draft. I don't think God's involved (certainly hope not), but it seems like an awfully large thing to do on the way to a PR. You can deny it all you like, but it smells pretty ugly to this long-time W3C watcher. No rationale + sudden leap at PR stage -> No confidence. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 paul at qub.com Thu Sep 2 19:52:48 1999 From: paul at qub.com (Paul Tchistopolskii) Date: Mon Jun 7 17:14:37 2004 Subject: DTDGenerator and empty attributes. References: <93CB64052F94D211BC5D0010A800133170F08D@wwmess3.bra01.icl.co.uk> Message-ID: <00f501bef56c$9ddafc40$5df5c13f@PaulTchistopolskii> Thank you Michael, I realy missed upgrading to SAXON 4.2. I now upgraded to SAXON 4.5, tested it and everything works fine. Shame on me not checking your page for months - but there was no bug reports! Rgds.Paul. PS. The upgraded DTDGenerator Frontend runs at http://www.pault.com/Xmltube/dtdgen.html =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= paul@pault.com www.renderx.com www.pault.com XMLTube * Perl/JavaConnector * PerlApplicationServer =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > The source code has a comment saying that I fixed this problem on 20 April > 99, so if it is still there in the latest SAXON release there is something > wrong with my build or testing procedures! Paul, could you check you are > using the latest version? > > > -----Original Message----- > > From: Paul at Sunnyvale [mailto:paul@pault.com] > > Sent: 31 August 1999 10:45 > > Cc: Michael.Kay@icl.com > > Subject: DTDGenerator and empty attributes. > > > > Richard, > > > > Thank you for your bugreport. > > > > It appears that there is a problem with DTDGenerator > > caused by empty attributes. > > > > I have stripped your xml file to the smallest possible > > fragment which still causes the exception. > > > > #### Good file > > > > <XMLMessage> > > <XMLMessageHeader UserId="1"/> > > </XMLMessage> > > > > #### Output: > > > > Processing: C:\tmp\B.xml > > <!ELEMENT XMLMessage ( XMLMessageHeader ) > > > > > <!ELEMENT XMLMessageHeader EMPTY > > > <!ATTLIST XMLMessageHeader UserId NMTOKEN #REQUIRED > > > > > ### 'Bad' file > > > > <XMLMessage> > > <XMLMessageHeader UserId=""/> > > </XMLMessage> > > > > #### Output: > > > > Processing: C:\tmp\B.xml > > java.lang.StringIndexOutOfBoundsException: String index out > > of range: 0 > > at java.lang.String.charAt(String.java) > > at DTDGenerator.isValidName(DTDGenerator.java:69) > > at DTDGenerator.access$0(DTDGenerator.java:67) > > at DTDGenerator$ElemHandler.startElement(DTDGenerator.java:290) > > at com.icl.saxon.Distributor.startElement(Distributor.java:249) > > at com.jclark.xml.sax.Driver.startElement(Driver.java) > > at com.jclark.xml.parse.EntityParser.parseContent(EntityParser.java) > > at > > com.jclark.xml.parse.EntityParser.parseDocumentEntity(EntityPa > > rser.java) > > at com.jclark.xml.parse.DocumentParser.parse(DocumentParser.java) > > at > > com.jclark.xml.parse.base.ParserImpl.parseDocument(ParserImpl.java) > > at com.jclark.xml.sax.Driver.parse(Driver.java) > > at com.icl.saxon.Distributor.run(Distributor.java:111) > > at DTDGenerator.main(DTDGenerator.java:43) > > > > I'm crossposting this letter to Michael Kay ( who is the > > author of the > > DTDGenerator ) I hope he would be so kind to add more on > > this issue. My apologies to Michael if it was not a good idea. > > > > Rgds.Paul. > > > > > I am new to XML so my apologies if I am wasting your time. > > I am attempting > > > to set up a DTD and foun your page. I thought it would be a > > good jumping > > off > > > point for writing a DTD. My sample XML file (written with > > the aid of MS > > XML > > > Notepad) fails when passed to your online frontend. As you > > requested, I am > > > emailing you the source file and hope it may help both of > > us to sort out > > the > > > problem. > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 2 20:03:42 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:37 2004 Subject: why distinctions within XHTML? References: <4.1.19990902093928.03cd8ef0@mail.webgeek.com> Message-ID: <37CEBC55.D3183930@pacbell.net> Ann Navarro wrote: > > While that's certainly a possibility -- before anyone gets too excited > (either way) over it, the modularization work isn't done, so we may see > something like this, but we may not. For the record, some of my feedback back in March to the XHTML work was that the basics of the modularization stuff should be in the first release, since it's that fundamental. I'd even support holding back a 1.0 release to ensure modularization is covered. The current "10% solution" (three namespace URIs) is IMNSHO the wrong tack -- either don't address it at all, or hold out for a complete solution, but don't put something in that's widely perceived as broken and is universally acknowledged as incomplete! - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 2 20:18:57 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:37 2004 Subject: why distinctions within XHTML? References: <4.1.19990902093928.03cd8ef0@mail.webgeek.com> <37CEBC55.D3183930@pacbell.net> Message-ID: <37CEBFDB.C19D580B@pacbell.net> Oh, and to clarify -- I'm talking here about the notion of combining XHTML with modules of other vocabularies, not defining the internal modules that will allow XHTML subsetting. Both notions of modularization are important. But the one that'll make XHTML more widely used in the near future is the one that makes it easy to embed words from the XHTML vocabulary with others (such as CBL) and vice versa. The issue of the rules used to constrain such combinations is separable -- and should be separated, not glommed onto three URIs that can't possibly begin to capture the variety of rules (a million is not a low estimate) that will be used to constrain such combinations. - Dave David Brownell wrote: > > Ann Navarro wrote: > > > > While that's certainly a possibility -- before anyone gets too excited > > (either way) over it, the modularization work isn't done, so we may see > > something like this, but we may not. > > For the record, some of my feedback back in March to the XHTML work > was that the basics of the modularization stuff should be in the > first release, since it's that fundamental. I'd even support holding > back a 1.0 release to ensure modularization is covered. > > The current "10% solution" (three namespace URIs) is IMNSHO the wrong > tack -- either don't address it at all, or hold out for a complete > solution, but don't put something in that's widely perceived as broken > and is universally acknowledged as incomplete! > > - 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 joubin at inch.com Thu Sep 2 20:22:48 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:37 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >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 david-b at pacbell.net Thu Sep 2 20:27:26 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:37 2004 Subject: Why namespaces? References: <A26F84C9D8EDD111A102006097C4CD0D0E8F48@sohos002.ied-support.net> Message-ID: <37CEC1E3.E8DEE2F9@pacbell.net> Mark Birbeck wrote: > > So, how else do you make the distinction? You can't use DTDs if the > XHTML is inside another doc - so what else? But "XHTML inside another doc" is the very combining of vocabularies (modularization etc) that XHTML 1.0 isn't intended to address. In fact the XHTML PR (gaak) talks only about XHTML "documents" in all places I saw when I just re-scanned it. Only document and user agent conformance is defined. That sort of vocabulary combining isn't part of the first release. You can't use the notion of an XHTML "module" as the motivation for a feature, when that feature isn't supposed to be part of XHTML. - Dave p.s. As a concrete answer to the "how do you make the distinction", the answer is to declare the rules you're using to combine those various namespaces. A million different sets of rules? Quite easily. Not a million namespaces for a long time. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Sep 2 21:10:03 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:37 2004 Subject: XHTML & Schemas In-Reply-To: <37CE9599.69475C4D@prescod.net> References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> <37CE9599.69475C4D@prescod.net> Message-ID: <14286.52143.114741.934888@localhost.localdomain> Paul Prescod writes: > David Megginson wrote: > > > > > The quoted section 4.1 of the XSchema draft seems to directly > > > contradict his view of what's right, so XML did not "get it > > > right". Am I missing something again? > > > > Yes -- XML-Schema is not XML. XML-Schema is (currently) getting it > > wrong, but they're in the early drafts, so I still hope for their > > redemption. > > I don't know what you are talking about. A schema rule is inherently > triggered based on hooks within the document. What could be a more > natural hook than the universal name for an element type? Perhaps I misremembered the original excerpt -- I thought that it had to do with the Namespace URI pointing to the schema. I agree that schemas should define rules for qualified 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 david at megginson.com Thu Sep 2 21:08:51 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:37 2004 Subject: XHTML & Schemas In-Reply-To: <37CE8C54.50138CFB@prescod.net> References: <37CD441A.1FF39F6E@prescod.net> <002001bef4e3$19ad64a0$0300000a@cygnus.uwa.edu.au> <37CE8C54.50138CFB@prescod.net> Message-ID: <14286.51981.236383.390832@localhost.localdomain> Paul Prescod writes: > I disagree on two fronts. First, namespaces are for distinguishing > element/attribute vocabularies *across* instances. The whole point is > that I could (one day) take some XHTML content and put it in an instance > that is not entirely an XHTML document. Paul and I agree on this point. > > A corollary to this is that *something else* (perhaps in > > conjunction with namespaces) must trigger stylesheets, > > validators, etc. I would like to see a solution proposed for > > that---soon, if at all possible. > > I don't follow this at all. What is the value in namespaces if they > cannot be used in style rules, schema rules and other such > name-triggered processes. Agreed, again. This is what you can do with Namespaces *now*, and I think that it will end up being over 95% of what people what people do with Namespaces once there are specs for XML-Schemas, etc. It is an incredibly powerful idea, once we get our minds around it. 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 lauren at sqwest.bc.ca Thu Sep 2 21:13:27 1999 From: lauren at sqwest.bc.ca (Lauren Wood) Date: Mon Jun 7 17:14:37 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <199909021721.NAA26075@hesketh.net> References: <4.1.19990902125831.04533b20@mail.webgeek.com> Message-ID: <199909021843.OAA00921@gw.sqwest.bc.ca> Just to remind people of some of the general process that goes on in W3C WGs: changes are possible between a WD and a PR, mostly because a large proportion of the WG has become convinced somehow that the change is a good idea (others may disagree that it is a good idea, of course!). Once the spec is at PR, the member companies have a chance to say what they think, and the Director makes a decision based at least in part on the member company reponse. XML-DEV does not directly have a voice, but every person who reads XML-DEV and is associated with a W3C member organisation can at least in theory tell their AC rep what they think, so I don't think a discussion on this mailing list has no effect. It has no *direct* effect, which is something different. 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 lauren at sqwest.bc.ca Thu Sep 2 21:13:28 1999 From: lauren at sqwest.bc.ca (Lauren Wood) Date: Mon Jun 7 17:14:37 2004 Subject: why distinctions within XHTML? In-Reply-To: <37CEBC55.D3183930@pacbell.net> Message-ID: <199909021843.OAA26228@gw.sqwest.bc.ca> On 2 Sep 99, at 11:05, David Brownell wrote: > For the record, some of my feedback back in March to the XHTML work > was that the basics of the modularization stuff should be in the > first release, since it's that fundamental. I'd even support holding > back a 1.0 release to ensure modularization is covered. I would agree with this. I think the world needs the modularization as soon as possible and the current XHTML 1.0 brouhaha is taking time and energy away from that for little gain. 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 kurt.donath at lmco.com Thu Sep 2 21:45:19 1999 From: kurt.donath at lmco.com (Kurt Donath) Date: Mon Jun 7 17:14:37 2004 Subject: StarOffice Message-ID: <37CED444.B1A40BFA@lmco.com> Just downloaded StarOffice (http://www.sun.com/) and it mentions SGML under html display properties and in the help. Does anyone know if StarOffice supports any kind of SGML or XML functionality? -- Kurt Donath 315.456.6276 Staff Systems Engineer Intranet: http://www.syr.lmco.com/~donath/ . . . . . . . . . . . . . . . . . . . . . . . Lockheed Martin - Enterprise Information Systems Systems Engineering / Webserv xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 21:49:09 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:37 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <4.1.19990902125831.04533b20@mail.webgeek.com> from "Ann Navarro" at Sep 2, 99 01:01:02 pm Message-ID: <199909022024.QAA17002@locke.ccil.org> Ann Navarro scripsit: > >I'll take that as 'No comment', as the process document for the W3C already > >indicates that what you describe above must have happened, and as that > >description provides no further light on a complicated question. > > What do you want me to say, Simon? [silly story snipped] What Simon wants, of course, is the rationale. *What* was the compelling argument that made the HTML WG reverse itself on this point, so close to PR? -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 2 22:15:38 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:37 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <199909022024.QAA17002@locke.ccil.org> References: <4.1.19990902125831.04533b20@mail.webgeek.com> Message-ID: <4.1.19990902161608.044529c0@127.0.0.1> At 04:24 PM 9/2/99 -0400, John Cowan wrote: > >What Simon wants, of course, is the rationale. *What* was the compelling >argument that made the HTML WG reverse itself on this point, so close >to PR? And I can't speak for the entire group, so I'm not sure what else I can do here. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cliffwd at forte.com Thu Sep 2 22:22:31 1999 From: cliffwd at forte.com (Cliff Draper) Date: Mon Jun 7 17:14:37 2004 Subject: arbitrary characters in XML document? Message-ID: <14286.56566.439407.394793@cookie.forte.com> Hi, I have a question about dealing with multiple character sets. I have an application where I want to store data in XML and retrieve it later. Now a good chunk of the data I want to store is coming straight from the user and I have little control over exactly which character set the user is using. One of my users apparently tried using 0x98 + 0x03 as an accented 'e'; I have no idea which character set he used (and I don't care), but I still want to be able to store it and parse it later. When I parse it with expat with an encoding="UTF-8", it complains that it's not well-formed. Any ideas? thanks, -Cliff Draper cliffwd@forte.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Thu Sep 2 22:22:52 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:37 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <009a01bef581$a464fa60$c1d7f0cf@javadev.cwi.cablew.com> -----Original Message----- From: James Tauber <jtauber@jtauber.com> >Mind you, hierarchical organisation isn't that good a general solution as it >forces you to prioritise axes. This is true only if you _must_ map an n-dim space (n>1) with a _single_ hierarchy. You can certainly map an n-dim space with n hierarchies, where the relationships between hierarchies are isomorphic to the relationships of the dimension of space. So the question is, must we? It certainly takes more than a scalar (which is what an XML-namespace currently is, never mind the 'URI') to effectively 'situate' an XML object within its context. Why this insistence on using a single scalar? To keep things 'simple'? But the problem has an intrinsic level of complexity which must be managed, and as it is clearly apparent, when you force the expression of that complexity through a singular 'simple' mechanism, the net result is unnecessary ambiguity and complexity at the _application_ layer. IMHO, instead of concentrating on concocting various X- 'languages' (can't the world wait?), all the XML wizards should get together and spec out a standard _XML Relational Engine_ which plugs in the your standard XML Parser, and presents to the application layer a fully defined XML Object. Hand-in-hand with this, DOM must be modified to allow (simple, unified, standard) access to the 'meta-information' of a given XML Object Type, should the application require it. One result will be a shrinking of the bloated (and almost fully redundant) DTDs, for say 'Strict' and 'Transitional' flavors of XHTML. (And will also allow the removal of non-frame related elements (e.g. <body>) from frameset.dtd, which are _already_ fully defined elsewhere.) And then you can also say (regardless of whether <a> is appearing in a 'frameset', or vanilla 'html'): processElement(Element if(e.getSystem().equals("HTML") && // meta-info about element e.getType().equals("a")) // info about element { doHTMLHyperLink (e); // process application layer info } } // and if you are further interested in, say, 'target' attributes doHTMLHyperLink(Element e) { String target = null; if( ! e.getDialect().equals("strict"){ target = e.getAttribute ("target"); // .. } // ... } The information is there. If you are interested in it, then <strict:a> is differentiated from <transitional:a> and if you don't care, <html:a> is <strict_html:a> is <transitional:a> is <a> and life remains simple. /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc PS: Spatial context of an XML object: <!Doctype...> << System (discreet, non-hierarchical) xType://www.w3c.org/XHTML << Morphological Context xType://www.w3c.org/XHTML/Frameset xType://www.w3c.org/XHTML/Math xType://www.w3c.org/XHTML/Math/Algebra xType://www.w3c.org/XHTML/Math/Calculus xType://www.w3c.org/XHTML/Math/Groups xType://www.w3c.org/XHTML/Object xType://www.w3c.org/XHTML/Object/Applet xVersion://www.w3c.org/XHTML/1 << Revision Context xVersion://www.w3c.org/XHTML/1/1 xVersion://www.w3c.org/XHTML/1/2 xVersion://www.w3c.org/XHTML/2 << Dialectal Context xDialect://www.w3c.org/XHTML/Formal (~Strict) xDialect://www.w3c.org/XHTML/Colloquial (~transitional) xDialect://www.w3c.org/XHTML/Legacy xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 22:36:38 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:37 2004 Subject: StarOffice In-Reply-To: <37CED444.B1A40BFA@lmco.com> References: <37CED444.B1A40BFA@lmco.com> Message-ID: <14286.57318.697650.926583@localhost.localdomain> Kurt Donath writes: > Just downloaded StarOffice (http://www.sun.com/) and it mentions SGML > under html display properties and in the help. Does anyone know if > StarOffice supports any kind of SGML or XML functionality? If they're really going community-license (*almost* open source), then we have an opportunity to do some standardization -- I'd love to see a common (but extensible) spreadsheet format for the KDE spreadsheet, the Gnome spreadsheet, and the Star Office spreadsheet. 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 Thu Sep 2 22:37:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:37 2004 Subject: XHTML & Schemas References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> <37CE9599.69475C4D@prescod.net> <14286.52143.114741.934888@localhost.localdomain> Message-ID: <37CECEAA.E1F36838@prescod.net> David Megginson wrote: > > > I don't know what you are talking about. A schema rule is inherently > > triggered based on hooks within the document. What could be a more > > natural hook than the universal name for an element type? > > Perhaps I misremembered the original excerpt -- I thought that it had > to do with the Namespace URI pointing to the schema. Maybe I misunderstood it. Whatever. > I agree that > schemas should define rules for qualified names. Great. Do you agree that it will be vital to be able to declare whether an element was meant to validate against the "strict" or "loose" schema (if indeed there are both)? If so, do you further agree that that information should be expressed in a namespace? What other mechanism could we use to know whether to apply the loose:P content model or the strict:P model? Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 2 22:40:15 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:37 2004 Subject: arbitrary characters in XML document? References: <14286.56566.439407.394793@cookie.forte.com> Message-ID: <37CEE122.54D19844@pacbell.net> Cliff Draper wrote: > > Hi, I have a question about dealing with multiple character sets. > > I have an application where I want to store data in XML and retrieve > it later. Now a good chunk of the data I want to store is coming > straight from the user and I have little control over exactly which > character set the user is using. One of my users apparently tried > using 0x98 + 0x03 as an accented 'e'; I have no idea which character > set he used (and I don't care), You should. Arbitrary binary garbage isn't necessarily going to be legal -- as happened in this case -- and even if it chances to be legal, it's likely to come out as something that wasn't intended. Coming out as an error diagnostic is a useful outcome ... hidden mangling of data is as likely, and causes severe problems later on. A diagnostic lets you fix the problems early, before they get bad. > but I still want to be able to store > it and parse it later. When I parse it with expat with an > encoding="UTF-8", it complains that it's not well-formed. Probably because it isn't. > Any ideas? Don't permit aritrary binary data into your text. Ensure you know what character encoding was used, and make sure that you either transform that encoding to the one you're using, or switch to using that encoding. - Dave > thanks, > -Cliff Draper > cliffwd@forte.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Sep 2 22:44:12 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:37 2004 Subject: What's the rumour? (was Re: Consensus and Community (W3C and xml-dev)) In-Reply-To: <4.1.19990902161608.044529c0@127.0.0.1> References: <4.1.19990902125831.04533b20@mail.webgeek.com> <199909022024.QAA17002@locke.ccil.org> <4.1.19990902161608.044529c0@127.0.0.1> Message-ID: <14286.57467.88578.169576@localhost.localdomain> Ann Navarro writes: > At 04:24 PM 9/2/99 -0400, John Cowan wrote: > > > >What Simon wants, of course, is the rationale. *What* was the > >compelling argument that made the HTML WG reverse itself on this > >point, so close to PR? > > And I can't speak for the entire group, so I'm not sure what else I > can do here. There's a rumour in wide circulation (both inside and outside the W3C) that a sudden and irregular event brought about the change -- in other words, that it was not simply an independent decision on the part of the HTML WG members. I should note that similar rumours circulated about an equally sudden and unexpected change in the Namespaces spec just before it went to PR last year. Since I'm involved in the W3C work, I'm not at liberty to repeat that rumour in detail, but since everyone seems to have heard it, perhaps someone outside the W3C can put the rumour on the table so that Ann at least knows what her WG's being accused of. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Sep 2 22:48:50 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:37 2004 Subject: XHTML & Schemas In-Reply-To: <37CECEAA.E1F36838@prescod.net> References: <015901bef538$8d3a1440$4602a8c0@capella.co.il> <14286.26826.892548.495823@localhost.localdomain> <37CE9599.69475C4D@prescod.net> <14286.52143.114741.934888@localhost.localdomain> <37CECEAA.E1F36838@prescod.net> Message-ID: <14286.57885.295018.29345@localhost.localdomain> Paul Prescod writes: > Do you agree that it will be vital to be able to declare whether an > element was meant to validate against the "strict" or "loose" > schema (if indeed there are both)? I'm less certain about that -- I'm still trying to decide whether the document or the application should decide what schema to apply. With SGML, in *theory* it was the document that made the declaration, but in practice, it was usually the application, at least for non-trivial production systems: the systems mostly keep track of the status of the document through the production chain and swap entity catalogues or activate parameter entities to get the correct DTD flavour at each stage. I know that it's the wrong thing to have the document point to its stylesheet, and right now, I'm leaning towards considering a schema as a specialized stylesheet (or a stylesheet as a kind of schema). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From aray at q2.net Thu Sep 2 23:09:01 1999 From: aray at q2.net (Arjun Ray) Date: Mon Jun 7 17:14:37 2004 Subject: Why namespaces? In-Reply-To: <19990902162106.G32545@heddley.com> Message-ID: <Pine.LNX.3.95.990902170814.24736A-100000@mail.q2.net> On Thu, 2 Sep 1999, Edd Dumbill wrote: > On Thu, Sep 02, 1999 at 02:58:54AM +0100, Mark Birbeck wrote: > > [James Tauber:] > > > Namespaces (by my reading of the spec) are for distinguishing > > > element/attribute vocabularies *within an instance*. > > > > Not so. [...] Namespaces (by my reading of the spec) are for > > distinguishing element/attribute vocabularies *within the whole world*. The first view is a straightforward reading of the first two paragraphs of the XML Namespace spec's "Motivation and Summary". The second view is a straightforward reading of the third paragraph. The basic problem is that the statement "document constructs should have universal names" is a (IMHO, whopping) non-sequitur. > The namespace URI reference identifies the namespace. So, yes, > namespaces can be used to distinguish vocabularies globally, put > prefixes can't. Yes, except for the unstated agendas for reserved names that might be lurking:) > Therefore implementations shouldn't assume anything from a prefix, Something tells me that, unfortunately, this is precisely what some implementors would like to do, and therefore some implementations will wind up doing. > It is clearly a goal of XHTML to allow inclusion of other XML namespaces > in a document, therefore XHTML ought to define the namespace within > which it sits. But why now? What's the rush? > So, if a namespace does indeed == a schema then we need three of them. > > The implication of this to me seems to be nothing less than the ultimate > replacement of the DTD declaration by the namespace declaration. A lot of this - actually, to my mind, all of this - seems to be the cart before horse. Personally, I consider XML-ization of HTML a bad idea, so I really don't care how many angels have to dance on the head of this pin. But it was my understanding that modularization of HTML was an integral part of the XML-ization, so I can't see why that activity - important in its own right - has been shunted into the background for the sake of an ill-defined, easily-misunderstood will-o'the-wisp add-on. Put it this way: who are the implementors who have declared that no immediate decision on namespaces is a show-stopper? Arjun xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 23:08:25 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:37 2004 Subject: arbitrary characters in XML document? In-Reply-To: <14286.56566.439407.394793@cookie.forte.com> from "Cliff Draper" at Sep 2, 99 01:24:22 pm Message-ID: <199909022143.RAA19767@locke.ccil.org> Cliff Draper scripsit: > I have an application where I want to store data in XML and retrieve > it later. Now a good chunk of the data I want to store is coming > straight from the user and I have little control over exactly which > character set the user is using. One of my users apparently tried > using 0x98 + 0x03 as an accented 'e'; I have no idea which character > set he used (and I don't care), but I still want to be able to store > it and parse it later. When I parse it with expat with an > encoding="UTF-8", it complains that it's not well-formed. Too right. Your data isn't really character data at all, from the viewpoint of your XML application: it's raw bytes. So you should store it in Base64 or some similar format for representing raw bytes as characters. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 23:35:01 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:37 2004 Subject: why distinctions within XHTML? References: <4.1.19990902093928.03cd8ef0@mail.webgeek.com> <37CEBC55.D3183930@pacbell.net> Message-ID: <37CEDD48.C9BCBAC5@prescod.net> David Brownell wrote: > > The current "10% solution" (three namespace URIs) is IMNSHO the wrong > tack -- either don't address it at all, or hold out for a complete > solution, but don't put something in that's widely perceived as broken > and is universally acknowledged as incomplete! I agree and I would feel the same about a single namespace. We don't need no steekin namespaces (yet!). Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Sep 2 23:50:04 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:37 2004 Subject: dumb namespaces question Message-ID: <199909022152.RAA06190@hesketh.net> The end of section 2 of 'Namespaces in XML' saith: >Namespace Constraint: Leading "XML" >Prefixes beginning with the three-letter sequence x, m, l, in any case >combination, are reserved for use by XML and XML-related specifications. To me, that means that you can't start your own namespaces using xml or whatever. However, it isn't clear what this means for namespace processing with xml:space and xml:lang. There is no declared namespace for these lucky attribute values. Do we simply not need one, or do documents that use them have a problem with namespaces? Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 dhunter at Mobility.com Thu Sep 2 23:54:18 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:37 2004 Subject: why distinctions within XHTML? Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFE58@cc20exch2.mobility.com> > From: Paul Prescod [mailto:paul@prescod.net] > Sent: Thursday, September 02, 1999 4:26 PM > > David Brownell wrote: > > > > The current "10% solution" (three namespace URIs) is IMNSHO > the wrong > > tack -- either don't address it at all, or hold out for a complete > > solution, but don't put something in that's widely > perceived as broken > > and is universally acknowledged as incomplete! > > I agree and I would feel the same about a single namespace. We don't > need no steekin namespaces (yet!). I agree as well. While I feel that having a single universal XHTML namespace is a really good thing, it isn't actually needed until XHTML can be mixed with other XML vocabularies, so I'd be more than happy to leave it out until such time as that's feasible. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 2 23:59:55 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:37 2004 Subject: dumb namespaces question In-Reply-To: <199909022152.RAA06190@hesketh.net> from "Simon St.Laurent" at Sep 2, 99 05:56:18 pm Message-ID: <199909022235.SAA21423@locke.ccil.org> Simon St.Laurent scripsit: > > The end of section 2 of 'Namespaces in XML' saith: > >Namespace Constraint: Leading "XML" > >Prefixes beginning with the three-letter sequence x, m, l, in any case > >combination, are reserved for use by XML and XML-related specifications. > > To me, that means that you can't start your own namespaces using xml or > whatever. However, it isn't clear what this means for namespace processing > with xml:space and xml:lang. There is no declared namespace for these > lucky attribute values. Clause 4 saith: # The prefix xml is by definition bound to the namespace name # http://www.w3.org/XML/1998/namespace. But there is no namespace for xmlns, because that prefix is truly magic. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 3 00:00:51 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:37 2004 Subject: XHTML & Schemas References: <805C62F55FFAD1118D0800805FBB428D02BBFE50@cc20exch2.mobility.com> Message-ID: <37CEE4DE.983BA84B@prescod.net> Hunter, David wrote: > > > How would you select the schema to use for each? > > Why not > > <MYDOC> > <P xmlns="http://www.w3.org/TR/XHTML"><?xhtml mode='loose'?>This is supposed > to be loose.</P> > <P xmlns="http://www.w3.org/TR/XHTML"><?xhtml mode='strict'?>This is > supposed to be strict.</P> > </MYDOC> Are you saying is that the XML schema specification should have a special-case hack for detecting an "xhtml" processing instruction? Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Sep 3 00:08:31 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:37 2004 Subject: dumb namespaces question Message-ID: <3.0.32.19990902151053.00d0dd10@pop.intergate.bc.ca> At 05:56 PM 9/2/99 -0400, Simon St.Laurent wrote: >To me, that means that you can't start your own namespaces using xml or >whatever. However, it isn't clear what this means for namespace processing >with xml:space and xml:lang. There is no declared namespace for these >lucky attribute values. Yes there is. Read the namespace spec. -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 donpark at docuverse.com Fri Sep 3 00:08:29 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:38 2004 Subject: Consensus and Petition for XHTML Namespaces In-Reply-To: <4.1.19990902094956.0427d1c0@mail.webgeek.com> Message-ID: <003501bef590$2ef42300$daf7fea9@w21tp> >> If the Director has >>a preconceived bias on a critical issue, he can not make a >fair decision. > >And you assume this based on what? I am sorry Ann, but that information is confidential and can not be divulged to the public without explicit consent from W3C. I suggest that you ask Steven Pemberton about this if you really want to know. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 3 00:11:50 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:38 2004 Subject: My ideal XHTML (if I were dictator) In-Reply-To: <37CEDD48.C9BCBAC5@prescod.net> References: <4.1.19990902093928.03cd8ef0@mail.webgeek.com> <37CEBC55.D3183930@pacbell.net> <37CEDD48.C9BCBAC5@prescod.net> Message-ID: <14286.61480.918138.757341@localhost.localdomain> Paul Prescod writes: > > The current "10% solution" (three namespace URIs) is IMNSHO the > > wrong tack -- either don't address it at all, or hold out for a > > complete solution, but don't put something in that's widely > > perceived as broken and is universally acknowledged as > > incomplete! > > I agree and I would feel the same about a single namespace. We > don't need no steekin namespaces (yet!). I'd have to say that I'd prefer no XHTML spec to the last-call WD that we have now, but for me (and other implementors) a single, standard HTML Namespace is really the *only* point of an XHTML spec. I'd be happy just with an XHTML NOTE that looked something like this: ====================8<====================8<==================== [W3C logo, blurbs, disclaimers, etc.] This note defines an XHTML, an HTML vocabulary for XML. The XHTML vocabulary consists of all of the elements and attributes included in HTML 4.01 (all flavours), but using XML rather than SGML syntax. [give a few illustrative examples with commentary] All XHTML element and attribute names belong to the Namespace "http://www.w3.org/Namespaces/HTML/". This Namespace URI is intended to be presistent; the attribute "{http://www.w3.org/Namespace/HTML/}version" is reserved to distinguish future versions of XHTML when there are backwards-incompatibilities. [explain rules for unknown elements and attributes] [give examples of Namespace use] In an XHTML document, or within XHTML markup embedded in another document type, any non-XHTML extensions must be clearly distinguished by being placed in a separate Namespace. [give examples of XHTML with extensions and of embedded XHTML.] [provide a couple of non-normative sample DTDs in an appendix] ====================8<====================8<==================== Is this underspecified? Well, yes. Is it better than the status quo? It sure is! It's also probably the most that we can sell to the Web community at once, and probably the most that they can successfully implement in the next few years. Something this simple has the potential to revolutionize the Web and greatly improve search engines, things that we promised XML would do in the first place: applications will be able to recognize HTML markup in any XML document, and to recognize foreign markup in HTML documents -- that's *way* more than we have now. People can get to work defining and standardizing vocabularies, so that search engines can look for "{http://www.reuters.com/ns/}subject-code" or "{http://www.ecommerce.org/ns/}price" across large heterogenous document bases. I figure that we have only a 50% chance of success even with something this simple, about a 15% chance of success with the current XHTML WD, and about 0.1% chance of convincing the Web community to use schemas, modules, etc. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From btwito at nimble.com Fri Sep 3 00:31:18 1999 From: btwito at nimble.com (btwito@nimble.com) Date: Mon Jun 7 17:14:38 2004 Subject: Sample XML datasets for stress testing applications Message-ID: <FF3FDB3F5E4BD311809F00902785FC43663F@sense-nimble-160.oz.net> Could anybody provide pointers to rich datasets in XML for stress-testing XML applications? In particular, I'm looking for datasets with some depth, multiple attributes, and large amounts of data. I'm aware of the datasets pointers published on the FAQs, but am looking for more complex DTD structures and relatively large datasets... Thanks in Advance! Bruce Twito -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990902/576e1a07/attachment.htm From tbray at textuality.com Fri Sep 3 01:04:45 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:38 2004 Subject: My ideal XHTML (if I were dictator) Message-ID: <3.0.32.19990902160422.0097ea10@pop.intergate.bc.ca> At 06:13 PM 9/2/99 -0400, David Megginson wrote: >I'd be >happy just with an XHTML NOTE that looked something like this: Actually, you're not giving the WG enough credit. There are a bunch of other tricky little issues they had to deal with, like upper-lower case and so on. But I agree that a single way for programmers to address HTML markup would have been a huge benefit, and it's a pity we're not getting that. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Sep 3 01:04:40 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:38 2004 Subject: This is getting silly Message-ID: <3.0.32.19990902160714.00977310@pop.intergate.bc.ca> All this rumor and innuendo is beside the point. There is a body of people called the HTML Working Group who made a set of decisions reflected in the current XHTML 1.0 WD. The fact that there were substantial changes at the last moment is first of all not unprecedented, secondly not surprising, and thirdly, not the issue here. There are all sorts of honest grounds for disagreement on namespace handling in XHTML 1.0, and they are worth investing technical debate in. The current wave of postings is just a waste of time. -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 Fri Sep 3 02:11:54 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:14:38 2004 Subject: OPEN LETTER: Standards must stand on their own Message-ID: <4.2.0.58.19990903095835.00c88ca0@203.41.126.17> This is an open letter to all W3C standards developers, Clearly the release of the XHTML final draft has generated a lot of discussion. This has involved people within the working group defending the standard, along with others. Still more people have been busy attacking it. I think it is safe to say that, at the moment, confusion reins amongst the public (ie 'us'). This has highlighted what I think is an important point: "Standards must speak for themselves. They must be clearly 'the right way' to solve the problem. If they require advocates, then they have failed." If a standard is not well received on a list like this, then what chance will they have in the real world? There, if a standard is not liked, it will be ignored. This would be a terrible waste for all involved. Standards should not be controversial. They should not 'innovate'. They should solve a problem the 'best way' based on the real world experiences of all involved. If there is no experience to guide us in an area, don't create a standard. Wait. Experience will come ... With respect to the XHTML spec, it means that it should go back to draft status, and remain there until a solution presents itself that is unarguably elegant, and practical. If this cannot be done now, don't release the standard. If the world is not ready to create a single defensible standard, then it's not ready for a spec at all. In conclusion, I would like to draw parallels with other standards bodies. The IETF, for example, has a very good history with standards. Standards such as HTTP 1.1 were released without much fanfare. Everyone looked at it, admired it, and in due course implemented it. All with very little argument or discussion. Other bodies, such as the ISO, hold the other position. People tend to look at their standards and become frightened by their complexity. ISO standards have a long history of not being used. So I say again: Standards must speak for themselves. 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 simonstl at simonstl.com Fri Sep 3 02:33:48 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:38 2004 Subject: This is getting silly In-Reply-To: <3.0.32.19990902160714.00977310@pop.intergate.bc.ca> Message-ID: <4.0.1.19990902203440.00fa5210@pop.hesketh.net> At 04:07 PM 9/2/99 -0700, Tim Bray wrote: >All this rumor and innuendo is beside the point. There is a body of >people called the HTML Working Group who made a set of decisions >reflected in the current XHTML 1.0 WD. The fact that there were >substantial changes at the last moment is first of all not unprecedented, >secondly not surprising, and thirdly, not the issue here. > >There are all sorts of honest grounds for disagreement on namespace >handling in XHTML 1.0, and they are worth investing technical debate in. >The current wave of postings is just a waste of time. -Tim Is it really silly? Or does it just bother you that the lack of a rationale for this decision makes the W3C look terrible? Apparently not just to outsiders, at that. If it weren't for the impact it has on lots of xml-dev readers, I'd say we ought to drop it completely. Unfortunately, these workings affect a _lot_ of people outside of the W3C's corridors. I'd love to drop it, if it didn't matter so much. It's a barrel of laughs, indeed, quite silly... Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 cbullard at hiwaay.net Fri Sep 3 03:14:41 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:38 2004 Subject: OPEN LETTER: Standards must stand on their own References: <4.2.0.58.19990903095835.00c88ca0@203.41.126.17> Message-ID: <37CF20CB.7B5D@hiwaay.net> Don't know if I like the idea of multiple namespaces, but.. >James Robertson wrote: > > This has highlighted what I think is > an important point: > > "Standards must speak for themselves. > They must be clearly 'the right way' > to solve the problem. If they require > advocates, then they have failed." Any idea, whether you get beyond it or not, requires advocates. Few ideas which adapt existing technology or ways of working are accepted with a Duh slap, and a why didn't I think of that. What is required, as has been pointed out, is rationale in the face of honest differences. > If a standard is not well received on a list > like this, then what chance will they have > in the real world? There, if a standard is > not liked, it will be ignored. This would be > a terrible waste for all involved. You must have been in school when HTML was launched. The debates were real and vigorous. There are many reasons not to like a standard or an implementation. The proof and the acceptance is in the implementation. Even then, there may be better ideas but the market will rule. There have been some very lucid articles on ZD-Net and elsewhere as people have begun to understand that market rules do not tend to benefit the consumer. Sometimes, it is better to question the freebie, investigate the claims of originality and appropriateness, and understand tech before investing. That is just good sense. Waste is a fact of industry. > Standards should not be controversial. They > should not 'innovate'. They should solve a > problem the 'best way' based on the real > world experiences of all involved. Agree and disagree. There is plenty of literature that claims relational databases are all you need. I can cite from experience efforts to make PDF the sole accepted standard for digital documents in some domains. World experience is not sufficient. The acclaimed solution often depends on the local domain or politic. > If there is no experience to guide us in > an area, don't create a standard. Wait. > Experience will come ... No it won't. I agree standards should be created once products reach commodity status, but if you wait for experience you will only get a standard no one understands or understands why it should be standard. At some point, as the buzzard says to the next buzzard, "Patience my ass, I'm gonna kill me something." Science and standards depend on repeatable results. > With respect to the XHTML spec, it means > that it should go back to draft status, > and remain there until a solution presents > itself that is unarguably elegant, and > practical. Foolish. It should be argued over like meat in a wolves den. It is important. It should also be noted that wolves fight but also live in communal packs. They cannot choose to be wolves, and that is the difference here. This group can. > If this cannot be done now, don't release > the standard. If the world is not ready to > create a single defensible standard, then it's > not ready for a spec at all. And would not be ready for government if individuals did not choose to govern. You live under law or you don't. Civil disobedience is the alternative. It is, for the individual, sometimes the best alternative. In other words, if XHTML As Spec'd is unimplementable, don't implement it. Your choice. If others do and it works, then they made a better choice. This was the same choice made about HTML originally. There were better ideas and better systems. Care to roll back the clock to 1991 or stay in the fray? > In conclusion, I would like to draw parallels > with other standards bodies. The IETF, for example, > has a very good history with standards. Standards > such as HTTP 1.1 were released without much fanfare. > Everyone looked at it, admired it, and in due course > implemented it. All with very little argument or > discussion. Wrong. Running code and rough consensus. IETF defines working designs which have to be proved by implementation. Very practical. The difference is, the IETF is not a consortium. Anyone can sign up for the debate and get the details. The argument here is about W3C processes that result in decisions not justified by rationale. It creates an atmosphere of suspicion, mistrust, and fear. > Other bodies, such as the ISO, hold the other > position. People tend to look at their standards > and become frightened by their complexity. ISO > standards have a long history of not being used. Wrong. HTML is based on an ISO standard. ISO has a long history of responsibility, credibility, attention to detail and process, and a reputation for good product. There are many ISO standards in use every day, some good, some not as good. However, they have produced many standards and not all of them succeed. That could happen to XHTML but not for lack of interest. Again, XHTML is not a standard; it is a consortium-owned technology. It is the schema for an application. > So I say again: > > Standards must speak for themselves. No. Implementations must prove them. Markets can adopt the products. But people, individuals, speak for their work. That is the primary and most defensible argument in this long and yes, silly debate. 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 jtauber at jtauber.com Fri Sep 3 03:44:10 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:38 2004 Subject: ATTN: Please comment on XHTML (before it's too late) References: <009a01bef581$a464fa60$c1d7f0cf@javadev.cwi.cablew.com> Message-ID: <010501bef5ad$f8b7e060$0300000a@cygnus.uwa.edu.au> joubin wrote: > James Tauber wrote: > >Mind you, hierarchical organisation isn't that good a general solution as it > >forces you to prioritise axes. > > This is true only if you _must_ map an n-dim space (n>1) with a _single_ > hierarchy. You can certainly map an n-dim space with n hierarchies, where > the relationships between hierarchies are isomorphic to the relationships of > the dimension of space. Wouldn't it be factorial in n? If you wanted to check for XHTML 1.0 Strict, you'd have to match http://www.w3.org/xhtml/1.0/Strict http://www.w3.org/xhtml/Strict/1.0 http://www.w3.org/1.0/Strict/xhtml http://www.w3.org/1.0/xhtml/Strict http://www.w3.org/Strict/xhtml/1.0 http://www.w3.org/Strict/1.0/xhtml 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 Fri Sep 3 03:48:52 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:38 2004 Subject: XHTML & Schemas References: <37CD441A.1FF39F6E@prescod.net> <002001bef4e3$19ad64a0$0300000a@cygnus.uwa.edu.au> <37CE8C54.50138CFB@prescod.net> Message-ID: <013801bef5ae$affc1340$0300000a@cygnus.uwa.edu.au> > I don't follow this at all. What is the value in namespaces if they > cannot be used in style rules, schema rules and other such > name-triggered processes. I didn't say they cannot be used, I suggested that the be used *in conjunction with something else*. > David's whole argument is that three namespaces make it more difficult > to use namespaces as triggers because you must now trigger on three > names instead of one. The reverse is true if your trigger wants to distinguish between strict/transitional, etc. A validator is such a trigger. If there is one namespace, then something other than *just* namespaces must be used to trigger validation. That was my point. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net <pipe>Ceci n'est pas une pipe</pipe> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Sep 3 04:48:22 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:38 2004 Subject: ATTN: Please comment on XHTML (before it's too late) References: <009a01bef581$a464fa60$c1d7f0cf@javadev.cwi.cablew.com> <010501bef5ad$f8b7e060$0300000a@cygnus.uwa.edu.au> Message-ID: <37CF3744.AD617DEF@pacbell.net> You'd think that with all this flamage, someone would have caught some more bugs. I've BCC'd this to the editor of the XHTML spec -- which ought to ensure that this gets fixed. Consider these two lines from "HTMLspecialx.ent": <!ENTITY amp "&"> <!-- ampersand, U+0026 ISOnum --> <!ENTITY lt "<"> <!-- less-than sign, U+003C ISOnum --> Now, we all know that's not the correct way to write those two declarations. The replacement text is incorrect -- it's not a reference to the relevant character, as required by 4.6 of the XML spec and the additional constraint in 4.3.2 that the replacement text be well formed. However, I'll avoid causing more flamage and not provide my personal preferred declaration ... which, naturally, doesn't match the literal entity value found in the example of 4.6, since the spec doesn't require it to do so! ;-) - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Fri Sep 3 07:14:13 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:38 2004 Subject: schema v. validation spec, content models considered bad (was Re: XHTML & Schemas) Message-ID: <000201bef5cc$0d86e3b0$4ff96d8c@NT.JELLIFFE.COM.AU> From: David Megginson <david@megginson.com> >I know that it's the wrong thing to have the document point to its >stylesheet, and right now, I'm leaning towards considering a schema as >a specialized stylesheet (or a stylesheet as a kind of schema). This comes down to the difference between a schema and a validation specification. The latter is a function that is applied to a document: some useful kinds of validation languages can be implemented using stylesheet languages. A schema language can be more than a validation specification: notably it can give rules for building new documents. These rules could potentially involve many more issues; for example, validation results are sometimes regarded as returning a truth value (in fact, in real life we see that validators return information about errant tags, so validation in practise is not a mere function returning a truth value) but a schema languag could include more information about how to build the document: for example, that certain subelements should be automatically inserted by a editing tool when the user inserts an element. This kind of building-schema may be closer to what a forms language does, but it is schematic information that does not have anything to with validation. (I think my email on this was lost this week so I'll repeat:) this XHTML namespace issue is exactly the same one that I was trying to point out in that "XML Namespaces are dead" thread. That to tie a namespace to a schema puts the cart before the horse. A name is different from a use of the name; a schema is just one use of a name. On the WWW, the application with the highest claim to attach a schema to a namespace is the browser and not a schema tool. For new, independent, controlled schemas, this is not so critical; but the more language has variants and subsets and additional requirements imposed by various implemention, the less a namespace URI can invoke a particular schema. When we have an evolving family of variants (both the DTDs of HTML and the implicit DTDs of each of the tools that accept HTML documents) it is an incorrect analysis to think that these DTDs (or the namespace URIs strict, transitional, etc) represent schemas in the general sense. They merely represent the tightest validation specifications possible for the document. They do not show what schema the user had in mind when creating a document, or what schema future users should use; look at the "tidy" tool: it makes this process explicit...the DTD given is not the schema used to build but merely the strictest possible validation specification. There is another issue here too, b.t.w. That is that a lot of this problem comes from the idea that a schema involves a content model: that the parent determines the children. A "parent model" paradigm would resolve this issue to a large extent; SGML/XML is too reliant on simple automata/grammar theory in this. The "content model" works against extensibility; a "parent model" allows extensibility: it would say "the element myhtml:blink is allowed in html:p elements" without having to rewrite the DTD for html:p. In other words, IMHO some of the namespace problems that we can see with XHTML flow from the content-model paradigm of DTDs (and XML Schemas). Many people have found DTDs inappropriate for some kinds of jobs (Tim Bray has been very consistent in commenting on this) but the schema proposals have missed the mark: the problem will not be relieved by using instance syntax or sugar-coating architectural forms (as architypes) or adding inheritence or open/closed content models (excellent though all these may be). Extensibility requires that sometimes a child must be able to choose its parent, just as much as a parent can choose its child. 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 donpark at docuverse.com Fri Sep 3 08:45:28 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:38 2004 Subject: schema v. validation spec, content models considered bad (was Re: XHTML & Schemas) In-Reply-To: <000201bef5cc$0d86e3b0$4ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <000001bef5d8$69a03280$daf7fea9@w21tp> Rick, I completely agree with your conclusion. DTD sucks, XML-Schema is only marginally better, we need something more flexible. You might be interested in reading an interesting paper Dave Raggett (the HTML 4.0, Tidy guy) wrote that includes your 'parent model' idea. The paper is at: http://www.w3.org/People/Raggett/dtdgen/Docs/ I wouldn't mind having this 'Assertion Grammars' replace the current XML-Schema proposal. Frankly, I am tired of tip-toeing around what W3C thinks is the right way of doing things. I had a great time reading it and I am sure it will definitely shake some of you up. It is a must read for everyone. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nicmila at vscht.cz Fri Sep 3 09:28:05 1999 From: nicmila at vscht.cz (Miloslav Nic) Date: Mon Jun 7 17:14:38 2004 Subject: XSL-like DTD References: <000001bef5d8$69a03280$daf7fea9@w21tp> Message-ID: <37CF78FD.58D101D6@vscht.cz> After reading the paper bellow, just a quick thought. Is there any reason why XSLT-like validator would not be feasible? XSLT is very powerful, you do not need to learn a new syntax as XSL will be commonplace in a couple of years. We could do calculations inside XSL-DTD, we could have a very fine control over document structure, ... From davidc at nag.co.uk Fri Sep 3 11:54:03 1999 From: davidc at nag.co.uk (David Carlisle) Date: Mon Jun 7 17:14:38 2004 Subject: Why namespaces? Message-ID: <199909030954.KAA17904@nag.co.uk> Paul Prescod wrote > In XSL you would just use local names. URI-prefixed names are not useful > because you can't mix XHTML with other vocabularies *anyhow*. > > If you really did want to use URIs you could do something along the > lines of: > > <xsl:template match='P[uri()=="$html1" or uri()=="$html2" ...'> > > </xsl:template> No. match='P' matches a P from the currently declared default namespace so at most one of the clauses in that or filter could possibly be true. You need something like: <xsl:template match='html1:P |html2:P | html3:P'> </xsl:template> You can't just `use local names'. (Of course you could make one of the three the default and not use a prefixed form for that one) It appears that XHTML is defined as an application of XML 1.0 rather than XHTML 1.0 + namespaces, so it isn't at all clear why it has to have _any_ namespace allocated. In particular since conformance by DTD (with no pre-processing to normalise prefixes) is mandated, <html xmlns="..."> is GOOD, but <css:html xmlns:css="..."> which is totally equivalent to the above acording to the namespace REC, is BAD So XHTML distinguishes between equivalent forms of a document (according to the namespace REC) thus would be better described as an XML 1.0 application and not mention namespaces at all, wouldn't it? David xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From c.galiano at ua.es Fri Sep 3 12:09:22 1999 From: c.galiano at ua.es (Cristobal Galiano Fernandez) Date: Mon Jun 7 17:14:38 2004 Subject: XSL wanted... References: <37C52436.45ECBC92@ua.es> Message-ID: <37CF9FBF.5C4BBCB7@ua.es> A days ago I wrote without response.... Cristobal Galiano Fernandez wrote: > I need a generic XLS file that giving a XML file give de > Javascript functions > > 1) XML File > > <?XML VERSION="1.0" RMD="NONE"?> > <AUTHORS> > <AUTHOR> > <FIRSTNAME>Alexander</> > <INITIAL1>D</> > <SURNAME>Hildyard</> > </> > <AUTHOR> > <FIRSTNAME>Anon</> > <EMAIL>nobody@nowhere.com</> > </> > <AUTHOR> > <SURNAME>Twilite</> > <INITIAL2>M</> > <SPECIALFLAGS> > <FLAGS1>TRUE</> > <FLAGS4>TRUE</> > </> > </> > <PSEUDOAUTHOR> > <TITLE>I24X79</> > </> > </> > > 2) Javascript functions asociated (generated via XSL) > > function AUTHORS() > { this.PSEUDOAUTHOR = new Array(); > this.AUTHOR = new Array(); > return this; > } > function AUTHOR() > { this.SPECIALFLAGS = new Array(); > this.INITIAL2 = new Array(); > this.EMAIL = new Array(); > this.SURNAME = new Array(); > this.INITIAL1 = new Array(); > this.FIRSTNAME = new Array(); > return this; > } > function PSEUDOAUTHOR() > { this.TITLE = new Array(); > return this; > } > function SPECIALFLAGS() > { this.FLAGS4 = new Array(); > this.FLAGS1 = new Array(); > return this; > > thanks in advance > > Crist?bal > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 Fri Sep 3 12:53:45 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:38 2004 Subject: Why namespaces? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F4F@sohos002.ied-support.net> David Brownell wrote: > Mark Birbeck wrote: > > > > So, how else do you make the distinction? You can't use DTDs if the > > XHTML is inside another doc - so what else? > > But "XHTML inside another doc" is the very combining of vocabularies > (modularization etc) that XHTML 1.0 isn't intended to address. > I understand modularization (in the context of XHTML) to be the breaking up XHTML into a number of modules - tables, lists, block text features, scripts and so on. I understand "XHTML inside another document" to be something different, and is illustrated by the MathML example in the proposal. As with any mixing of vocabularies in a document, it requires a namespace for each vocabulary. XHTML 1.0 *is* intended to address that, although through no fault of its own, it cannot create combined documents that can be validated. Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Fri Sep 3 13:02:57 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:38 2004 Subject: Why namespaces? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F50@sohos002.ied-support.net> Edd Dumbill wrote: > From my reading of your post it seems to be confusing the prefix with > the namespace itself. The namespace URI reference identifies the > namespace. So, yes, namespaces can be used to distinguish > vocabularies globally, put prefixes can't. > > So in the first example you have in an attribute of a containing > element: > > xmlns:com="http://foo.bar.org/commands/onesense" > > and the second > > xmlns:com="http://foo.bar.org/commands/anothersense" > > Therefore implementations shouldn't assume anything from a prefix, but > derive their meaning from the namespace prefix binding. Indeed as I > understand it you can reuse a prefix within an instance, but bound to > a different namespace. That was my point, Edd. I was saying to James that *if* namespaces were only being used to allow differentiation within a document then all you need are the prefixs ns1, ns2, ns3, etc. However, I was disagreeing with him, and saying that we need to differentiate globally, in which case prefixes are insufficient. Other than that, I agree with everything else you say on '3 namespaces'. Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Sep 3 13:49:10 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:38 2004 Subject: Why namespaces? References: <199909030954.KAA17904@nag.co.uk> Message-ID: <37CFA700.91875A17@prescod.net> David Carlisle wrote: > > <xsl:template match='html1:P |html2:P | html3:P'> > > </xsl:template> > > You can't just `use local names'. You can if you use local-name(). You're right that the abbreviation I was trying to use does not work. > It appears that XHTML is defined as an application of XML 1.0 rather > than XHTML 1.0 + namespaces, so it isn't at all clear why it has to have > _any_ namespace allocated. > ... > So XHTML distinguishes between equivalent forms of a document (according > to the namespace REC) thus would be better described as an XML 1.0 > application and not mention namespaces at all, wouldn't it? You would think.... Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Fri Sep 3 13:50:54 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:38 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F52@sohos002.ied-support.net> Ann Navarro wrote: > However, moving forward from HTML 4.0, which is what the > future work in XHTML does, isn't necessarily bound. I know, but I'm being more specific; won't you have to leave the legacy namespaces untouched when you move forward? Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Fri Sep 3 14:04:12 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:38 2004 Subject: why distinctions within XHTML? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F55@sohos002.ied-support.net> The world needs the ability to nest XHTML inside XML and XML inside XHTML as soon as possible, true. But that will take schemas if you want validation, so there's nothing XHTML can do about that. The world also wants lots of neat little chunks of parts of XHTML to put in their mobile phones and toaster browser code. But that's still early days. But what the world needs now ... is a definition of HTML that conforms to XML standards, that can be validated before having meta-information added. You therefore cannot hold it back for the other stuff, nice to have as it would be. Mark > -----Original Message----- > From: Lauren Wood [mailto:lauren@sqwest.bc.ca] > Sent: 02 September 1999 19:51 > To: XML-Dev Mailing list > Subject: Re: why distinctions within XHTML? > > > On 2 Sep 99, at 11:05, David Brownell wrote: > > > For the record, some of my feedback back in March to the XHTML work > > was that the basics of the modularization stuff should be in the > > first release, since it's that fundamental. I'd even > support holding > > back a 1.0 release to ensure modularization is covered. > > I would agree with this. I think the world needs the modularization > as soon as possible and the current XHTML 1.0 brouhaha is taking > time and energy away from that for little gain. > > > 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) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 3 14:04:14 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:38 2004 Subject: why distinctions within XHTML? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F56@sohos002.ied-support.net> But it CAN be mixed with other vocabularies!!! It just can't be validated. > -----Original Message----- > From: Hunter, David [mailto:dhunter@Mobility.com] > Sent: 02 September 1999 22:53 > To: XML-Dev Mailing list > Subject: RE: why distinctions within XHTML? > > > > From: Paul Prescod [mailto:paul@prescod.net] > > Sent: Thursday, September 02, 1999 4:26 PM > > > > David Brownell wrote: > > > > > > The current "10% solution" (three namespace URIs) is IMNSHO > > the wrong > > > tack -- either don't address it at all, or hold out for a complete > > > solution, but don't put something in that's widely > > perceived as broken > > > and is universally acknowledged as incomplete! > > > > I agree and I would feel the same about a single namespace. We don't > > need no steekin namespaces (yet!). > > I agree as well. While I feel that having a single universal XHTML > namespace is a really good thing, it isn't actually needed > until XHTML can > be mixed with other XML vocabularies, so I'd be more than > happy to leave it > out until such time as that's feasible. > > xml-dev: A list for W3C XML Developers. To post, > mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and > on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 mnutter at fore.com Fri Sep 3 14:12:48 1999 From: mnutter at fore.com (Mark Nutter) Date: Mon Jun 7 17:14:38 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <199909022024.QAA17002@locke.ccil.org> References: <4.1.19990902125831.04533b20@mail.webgeek.com> Message-ID: <4.2.0.58.19990903080617.00c14680@pophost1.fore.com> At 04:24 PM 09/02/99 -0400, you wrote: >What Simon wants, of course, is the rationale. *What* was the compelling >argument that made the HTML WG reverse itself on this point, so close >to PR? Are we sure there was a (singular) compelling argument? What if the WG reached its conclusion after a long and convoluted debate (such as the debate that's been going on here lately)? Supplying a concise rationale might be a "non-trivial" task, might it not? I'm trying to avoid taking sides here, but I'm getting a sense that perhaps conditions might be ripe for the evolution of conspiracy theories that aren't really accurate or helpful. I've been learning a lot from the discussion, and I hope the flow of information isn't impeded by anybody feeling that they have to watch what they say. Pardon the intrusion, I'll sit back and return to just watching the show again. Thanks for your patience. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Mark Nutter, <mnutter@fore.com> Internet Applications Developer FORE Systems When birds start perching on the lawn, it's time to mow it. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Fri Sep 3 14:51:02 1999 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:14:39 2004 Subject: Why namespaces? References: <A26F84C9D8EDD111A102006097C4CD0D0E8F4F@sohos002.ied-support.net> Message-ID: <37CF701A.206975A3@isogen.com> Mark Birbeck wrote: > > I understand "XHTML inside another document" to be something different, > and is illustrated by the MathML example in the proposal. As with any > mixing of vocabularies in a document, it requires a namespace for each > vocabulary. XHTML 1.0 *is* intended to address that, although through no > fault of its own, it cannot create combined documents that can be > validated. I must point out that the SGML architecture mechanism enables exactly the ability to mix element types from different "vocabularies" while retaining the ability to validate the document against any of the vocabularies in isolation. Documents are mapped to architectures (document type *definitions*). Each architectural mapping defines a "view" over the document that reflects only those parts of the document mapped to the architecture. This view, which is logically another XML document, can then be validated against the architectural DTD without interference from any other view. This "view" idea in architectures is very similar to the concept of views in relational databases: it's an abstraction of a document expressed as another document, just as a database view is an abstraction over a set of tables expressed as another table or set of tables. There are a few constraints, the most severe being that each different view must be rooted at the document element (and in the examples below I've invented an "xlinkdoc" element type so that XLink can be used as an architecture--XLink editors please take note). In the abstract processing model for architectures, each view over the base document maintains pointers back to the base document--imagine a DOM environment where you have the base DOM tree and then one additional DOM tree for each different architectural view where each architectural DOM node points back to the base ("client") node from which it was constructed, and visa versa (each base node points to all of the architectural nodes constructed from it). This enables a processor to work in any and all views and navigate to the others. For example, you might find the HTML view DOM, walk about in it until you find something of interest, then navigate back to the base element to get its local details, and go from there. Or you might walk the base DOM and check all the architectural mappings (follow the pointers to its architectural DOM nodes) to see if its mapped to anything you recognize. The key is that you have all the data all the time--you don't just create the architectural view and throw away the base document (that's why you can't think of architectures as simply a transform in the A-in-B-out sense (although as Paul Prescod points out, architectural mappings are transforms in the mathematical sense)). If I'm using XHTML and Xlink in the same document, the same base element could be both an XHTML "a" element and an XLink "simple" at the same time, which I might indicate like so: <xhtml:a xlink:type="simple" href="#something">this is a link no matter how you slice it</xhtml:a> [or like so: <xlink:simple (oops nothing defined for doing it this way! Help! My document's been taken over by an autocratic spec hobbld by an overly-simple maping mechanism that imposes element type names on me with no recourse.)>] >From an architecture view point, the local element type "xhtml:a" is mapped to two architectural elements: "a" in the XHTML architecture and "simple" in the XLink architecture. From a DOM perspective, this could be represented like so: (Within the same overall DOM memory space:) Base DOM: ... Node [node000] Class = ElementNode TagName = "xhtml:a" ArchitecturalNodes: node001, node002 XHTML View DOM: ... Node [node001] Class = ElementNode TagName = "a" ClientNode: node000 XLink View DOM: ... Node [node002] Class = ElementNode TagName = "simple" ClientNode: node000 A processor can easily see that the base element "xhtml:a" is both an HTML A element and an XLink simple element and do whatever processing it thinks is appropriate. [Note that for this to be completely rigorous, there must be some formal and machine-validatable binding between each DOM and its governing architecture (see below)]. With the architecture mechanism I can also use my own element type names and still have a clear mapping. E.g., I could do this: <mydoc xhtml:type="HTML" xlink:type="xlinkdoc"> ... <mylink xhtml:type="A" xlink:type="simple" href="#foo">it's a link</mylink> ... </mydoc> Note that you have *exactly the same information* about the element "mylink" that you had about the "xhtml:a" element, namely that it is both an "A" element in XHTML and a "simple" element in XLink. Actually you have more information, because it's also a "mylink". The syntactic difference is trivial: I've moved the mapping to XLink from the GI to another attribute. But I've also freed up the local GI to be whatever I want it to be. One way to think of namespace prefixes on element types is as a shorthand for attribute-based architectural mapping. Note, for example, that XLink *cannot require* the use of namespace prefixes because one of its requirements is that you can use your own element type names and map them to the XLink semantics (that is, it allows you to have a "mylink" element and not always use "xlink:simple"). This is, I think, the general case, which of course the namespace mechanism cannot support. [Which suggests that namespace syntax must be a special case of a more general mechanism which the W3C has not yet defined.] Alternatively, the XHTML spec could define "A" as a specialization of "simple" (which simple was designed to enable), which would make the architectural DOMs for "mydoc" look like this: (Within the same overall memory space:) Base DOM: ... Node [node000] Class = ElementNode TagName = "mylink" ArchitecturalNodes: node001 XHTML View DOM: Node [node001] Class = ElementNode TagName = "A" ClientNode: node000 ArchitecturalNodes: node002 XLink View DOM: Node [node002] Class = ElementNode TagName = "simple" ClientNode: node001 That is, I can have multiple levels of specialization: mylink ISA "A" ISA "simple" (therefore, mylink ISA simple). The architectural mapping rule is that elements in the base document that are not explicitly mapped to an architecture are simply ignored for that view, thus, if I have this document: <?xml version="1.0"?> <?IS10744 arch name="xhtml" system-id="http://w3.org/.../PR-XHTML.xml"?> <?IS10744 arch name="xlink" system-id="http://w3.org/.../DR-XLink.xml"?> <mydoc xhtml="html" xlink="xlinkdoc"> <foo>This is purely mine</foo> <metadata xhtml="header"> this is mine and xhtml's </metadata> <stuff xhtml="body"> <p xhtml="p"><mylink xhtml="a" xlink="simple" href="foo">both HTML's and XLink's</mylink></p> </stuff> </mydoc> We now have three views of this document: 1. The base view, looking only at the element type names. These map to my private semantics, whatever they might be. 2. The HTML view: <html><header></header><body><p><a href="foo">Both HTML's and XLink's</a></p></body></html> This maps to the XHTML semantics. 3. The XLink view: <xlinkdoc><simple href="foo">Both HTML's and XLink's</simple></xlinkdoc> This maps to the XLink semantics. With appropriate pointers back and forth, of course. The "<?IS10744 arch" PIs in the example above are the "architecture use declarations" and do essentially what the namespace declarations do except they do more: 1. They define a local name for the architecture (analogous to the namespace prefix). This name is then taken to be the name of an attribute that defines the mapping to names in the achitecture (e.g., "xhtml='A') Note that when DTD declarations are present, these mappings can be fixed in the DTD rather than having to be specified on each element instance, which can be a significant space savings in non-trivial documents. You can't do this with namespaces. 2. They point to the resource that serves to define the architecture as a whole (in this case I've pointed to the W3C-managed specs for XHTML and XLink, which are the one true definitions of these architectures). This binds the document to a set of *semantic* definitions. The architecture mechanism does not (and cannot) say how the semantics are defined (apart from presuming some use of prose). Therefore, this could be any number of things, formal and informal, including XML Schemas, program code, UML drawings, EXPRESS schemas, whatever. 3. To enable architectural validation, they can point to a set of DTD declarations: <?IS10744 arch name="xlink" system-id="http://w3.org/.../PR-XHTML.xml" dtd-system-id="http://w3.org/.../xhtml-strict.dtd" ?> Note that in this example I've got one architecture, "XHTML", but I'm suggesting that there are different architectural DTDs that I can choose to validate against. This reflects my view that there is one set of general semantics with different structural constraints that the architecture allows. This part of the declaration binds the document to a machine-readable set of names (the names defined in the DTD declarations). That is, if I use "xhtml='foo'" I can now use an automatic and completely generic process to detect that the name "foo" is not in the XHTML vocabulary (that is, I don't have to have built-in knowledge of XHTML rules to do this validation, unlike namespaces, where there is no defined mechanism for defining vocabularies and therefore no way to have a generic vocabulary validator). The architecture standard stipulates DTD-syntax declarations because that's all we had, but once XML Schemas are standardized by the W3C, they would be an alternative--the key is machine processibility and validatability. Note that there is no requirement that the DTD declarations be fetched unless validation is actually requested--this has the interesting side of effect of letting you eat your DTD-less document and still have the cake of DTD-full validation. I think that's pretty cool. 4. To enable attribute name mapping, you can declare the name of an attribute for remapping attribute names unique to that architecture (by default, attribute names map to architecture names if they're the same as in the architectural DTD--the use of explicit mappings eliminates the need to read the architectural DTD or build knowledge of it into an architecture-aware processor): <?IS10744 arch name="xhtml" system-id="http://w3.org/.../PR-XHTML.xml" dtd-system-id="http://w3.org/.../xhtml-strict.dtd" arch-renamer-att="xtml-names" ?> There's more stuff you can specify, mostly having to do with controlling various optional features that enable automapping of names to architectures in the context of DTD-full processing, so these features are really not practical in a general XML environment. Architecture-aware processing is already implemented for SAX through the SaxArch package and has been in James Clark's SP parser for years (and therefore, in anything built from SP as long as the facility is exposed). Because architectural mappings are defined using attributes, there's absolutely no difficulty in writing code that constructs architectural views in a DOM-type setting--it's just normal XML processing where you key off of attributes. I have personally implemented architecture-aware processing in a variety of processing contexts, including ADEPT command language, perl, Python, VB, etc. Finally, note that the features provided by SGML architectures through the use of attributes could be provided in a much more convenient and complete way in an XML Schema mechanism--I fully expect the final XML Schema mechanism to do this and will not consider any mechanism that doesn't do this to be either complete or useful for my needs as a practitioner and integrator. That's because *none* of the problems I solve in my work can be solved effectively or completely without the use of architectures for the simple reason that the information systems my clients have and work with are complex and require a sophisticated representation system. Namespaces are of little or no value in these environments. They don't hurt, particularly, but they don't help either and therefore simply add unnecessary complexity to an already complex system. Cheers, E. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 3 14:52:49 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:39 2004 Subject: End of the XHTML thread (summary attached) Message-ID: <14287.48259.507622.343122@localhost.localdomain> I think that it's time to let the XHTML threads die out for a while. This has been an incredibly useful (if verbose) discussion, because we've flushed out a lot previously-unspoken assumptions that people have made about XML, HTML, Namespaces, Schema processing, and the Web. For the record, here's my summary of what I believe to the be most important points to come out during the discussion: 1. It is clear that their is not yet a consensus among XML developers that the kind of light-weight HTML Namespace model that I and many others have advocated is the right thing. That means that I may have been wrong in believing that in choosing three XHTML Namespaces the HTML WG was going against an obvious majority opinion in the developer community, though is it going with an obvious majority opinion either -- opinions are all over the place. 2. Namespaces and versioning is a problem that will not go away, and the lack of a standard, accepted solution is causing a lot of confusion and wasted time, both inside and outside the W3C. 3. Opinions are also very much divided on XML schemas: they are either the magic missing piece that will complete the XML puzzle and make the whole thing work, or a pointless distraction that is keeping us from getting on with serious work now. 4. The closed process of the W3C is no longer acceptable -- the W3C is fast losing the trust of the developer community, which is, after all, the community that will make or break each spec by deciding whether or not to bother implementing it. Silence inevitably leads to speculation and to conspiracy theory-mongering (even among employees of member companies!). 5. Further to #4, the HTML WG has stumbled by publishing a major change without a rationale. The situation (probably unfairly) makes the WG look high-handed and arbitrary, and the lack of a public explanation to accompany the public change allows rumour and innuendo to rush in and fill the gap. The WG might want to look at Paul Prescod's carefully-reasoned arguments in this thread as a model for how they could defend the change. Those of us on W3C WGs should all take this as a cautionary tale, especially since the same thing happened last year to the XML WG when we suddenly changed the Namespaces spec with no convincing public explanation. Well, that's about it. Let's all let this issue lie for a while, and then see where we are when the dust has had time to settle. Thank you all for participating, and I would still encourage everyone to make their opinions known to the W3C through one of the e-mail addresses listed in the XHTML spec. Thanks, and all the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Fri Sep 3 15:13:50 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:39 2004 Subject: Consensus and Community (W3C and xml-dev) References: <4.1.19990902125831.04533b20@mail.webgeek.com> <4.2.0.58.19990903080617.00c14680@pophost1.fore.com> Message-ID: <37CFC968.563B@hiwaay.net> Mark Nutter wrote: > > At 04:24 PM 09/02/99 -0400, you wrote: > >What Simon wants, of course, is the rationale. *What* was the compelling > >argument that made the HTML WG reverse itself on this point, so close > >to PR? > > Are we sure there was a (singular) compelling argument? What if the WG > reached its conclusion after a long and convoluted debate (such as the > debate that's been going on here lately)? Supplying a concise rationale > might be a "non-trivial" task, might it not? That the discussion is long and convoluted does not relieve the authority of documenting the rationale for the change. When doing a review, it is common practice to note the objection to the text, the reason for the objection, and the suggested change and consequence of the change. Two points are being advanced that are separable and simple: 1. Multiple namespaces in a single vocabulary are unnecessary and complex. This can be confirmed or refuted by citing requirements, examples, and counterexamples. 2. The process of closed deliberations and closed documentation of rationale used by the W3C impedes the progress of developing, understanding and implementing the technology. It engenders fear, mistrust and suspicion. The delegates of the consortia are responsible for these outcomes. A separate but valid debate is if if the W3C can be said to be creating standards at all. The process and constitution of authority suggests to me that the W3C creates technology, not standards. There is nothing wrong with that and in fact, it is a better path for consortia. The W3D (VRML, X3D) consortium works with ISO to co-develop standards. The consortium creates the technology, and ISO is the authority for the standard. This arrangement is working. The W3D as a member of the W3C works with the technology within which its products must function. Because the processes of the W3C are closed to non-members, and if those here consider the XML users, developers, vendors, etc. a Community, then events like this are PRECISELY when you should become involved even if the noise level is high. Stick to the issues, don't kick each other, do let it pass when you do (humans here all; we get emotional and that is a strength), and push on. There is the difference in community and consortia. Without tolerance, self-restaint, and compassion, you have little chance of reaching consensus. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Fri Sep 3 15:25:31 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:39 2004 Subject: Why namespaces? References: <A26F84C9D8EDD111A102006097C4CD0D0E8F4F@sohos002.ied-support.net> <37CF701A.206975A3@isogen.com> Message-ID: <37CFCC2E.1E7B@hiwaay.net> W. Eliot Kimber wrote: > > This "view" idea in architectures is very similar to the > concept of views in relational databases: it's an abstraction of a > document expressed as another document, just as a database view is an > abstraction over a set of tables expressed as another table or set of > tables. Excellent, Eliot. You might want to take some time to review the concepts of OLAPs (online analytical processors) in conjunction with this synthesis of relational and hierarchical 'views'. The axes and coordinate concepts should look familiar to you. Note the additions to SQL used to work with the n-dimensional cubes, and the fact that regular table structures and SQL can be used to get the same results. The issues of naming are also interesting. It occurs to me that simple prefixing isn't sufficient because namespaces nest. There is an extensive document on the Microsoft developers site about OLAP technology. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 3 15:30:22 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:39 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <A26F84C9D8EDD111A102006097C4CD0D0E8F52@sohos002.ied-suppor t.net> Message-ID: <4.1.19990903092830.03ea4dd0@mail.webgeek.com> At 12:22 PM 9/3/99 +0100, Mark Birbeck wrote: >Ann Navarro wrote: >> However, moving forward from HTML 4.0, which is what the >> future work in XHTML does, isn't necessarily bound. > >I know, but I'm being more specific; won't you have to leave the legacy >namespaces untouched when you move forward? Pardon the Friday morning confusion, but ....so? Have 3 now -- have 1 for modularization (or whatever the result is) -- everyone deals with it. Just as you'll deal with the namespaces from any other mix-and-match portion that people will be coming up with. This really is a non-problem for me. (and yes, I know that is one side of a very wide gulf) Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Fri Sep 3 15:55:53 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:39 2004 Subject: Why namespaces? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F57@sohos002.ied-support.net> David Carlisle wrote: > Paul Prescod wrote > > In XSL you would just use local names. URI-prefixed names are not useful > > because you can't mix XHTML with other vocabularies *anyhow*. > > > > If you really did want to use URIs you could do something along the > > lines of: > > > > <xsl:template match='P[uri()=="$html1" or uri()=="$html2" ...'> > > > > </xsl:template> > > No. > > match='P' matches a P from the currently declared default namespace > so at most one of the clauses in that or filter could > possibly be true. > You need something like: > > <xsl:template match='html1:P |html2:P | html3:P'> > > </xsl:template> > > You can't just `use local names'. (Of course you could make one of the > three the default and not use a prefixed form for that one) Not quite. A template of 'P' would match all elements that have a local name 'P', regardless of the namespace they came from, *unless* another template was more precise. For example: <xsl:template match="P"> do this most times </xsl:template> <xsl:template match="strict:P"> but do this on others </xsl:template> <xsl:template match="xlink:*"> and do this for anything in one particular namespace </xsl:template> XSLT uses a scoring mechanism to work out which template should be used when there is ambiguity. > It appears that XHTML is defined as an application of XML 1.0 rather > than XHTML 1.0 + namespaces, so it isn't at all clear why it > has to have _any_ namespace allocated. I think each XML grammar needs its own namespace, since we want to be able to mix documents within 'documents' all over the shop in manners that we had never thought of in advance. We therefore need EVERYTHING to be XML 1.0+namespaces. Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Mark.Birbeck at iedigital.net Fri Sep 3 16:14:35 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:39 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F5A@sohos002.ied-support.net> It's a non-problem for me too. All I'm referring to is that one of your emails said that you have three namespaces now, and then later you'll choose one of then to extend. I'm saying, yes, have three namespaces now, but that you will have to devise another one for extension - since you need the legacy ones to remain intact as long as there is ever any legacy HTML around to convert. So it's not three namespaces ... it's four. It was probably a slip of the tongue on you part in the original email. In fact, I'm not even sure if I can be bothered to press send it seems so obvious ... ooops Mark > -----Original Message----- > From: Ann Navarro [mailto:ann@webgeek.com] > Sent: 03 September 1999 14:30 > To: Mark Birbeck; xml-dev@ic.ac.uk > Subject: RE: How about over 1,000,000 XHTML Namespace URIs? > > > At 12:22 PM 9/3/99 +0100, Mark Birbeck wrote: > >Ann Navarro wrote: > >> However, moving forward from HTML 4.0, which is what the > >> future work in XHTML does, isn't necessarily bound. > > > >I know, but I'm being more specific; won't you have to leave > the legacy > >namespaces untouched when you move forward? > > Pardon the Friday morning confusion, but ....so? > > Have 3 now -- have 1 for modularization (or whatever the result is) -- > everyone deals with it. > Just as you'll deal with the namespaces from any other mix-and-match > portion that people will be coming up with. > > This really is a non-problem for me. (and yes, I know that is > one side of a > very wide gulf) > > Ann > --- > > Author of Effective Web Design: Master the Essentials > Coming in September --- Mastering XML > > Founder, WebGeek Communications http://www.webgeek.com > Vice President-Finance, HTML Writers Guild http://www.hwg.org > Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Fri Sep 3 16:40:35 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:39 2004 Subject: XHTML & Schemas Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFE5A@cc20exch2.mobility.com> > From: Paul Prescod [mailto:paul@prescod.net] > Sent: Thursday, September 02, 1999 4:58 PM > > Are you saying is that the XML schema specification should have a > special-case hack for detecting an "xhtml" processing instruction? No, I'm saying that the different flavours of XHTML are application-specific, not language-specific. (That is, there should be *one* XHTML *language*, even though *XHTML applications* may recognize different flavours of that language.) One language = one schema [= one DTD]. This is why I keep saying there should [eventually] be one XHTML namespace, to identify that "this is XHTML". Then that XHTML should be passed on to an XHTML application, for processing; since that application is really the only application that would even care if this is loose, strict, or frameset XHTML, a processing instruction is good enough to let it know. If the XHTML *isn't* going to be passed on to the XHTML application, then nobody really cares if it is strict or loose or frameset. (e.g., If a search engine is going to be searching XHTML pages it isn't going to be processing the XHTML for display, but it doesn't really care if those pages are in one flavour or the other anyway. It just wants to be able to find the XHTML.) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 3 16:45:38 1999 From: Michael.Kay at icl.com (Kay Michael) Date: Mon Jun 7 17:14:39 2004 Subject: arbitrary characters in XML document? Message-ID: <93CB64052F94D211BC5D0010A800133170F0A6@wwmess3.bra01.icl.co.uk> > Hi, I have a question about dealing with multiple character sets. > > I have an application where I want to store data in XML and retrieve > it later. Now a good chunk of the data I want to store is coming > straight from the user and I have little control over exactly which > character set the user is using. If you don't know or care what the encoding is, then you are not storing characters, you are storing bytes, and you should handle it the same way as other binary data, e.g. in Base64 encoding. Otherwise bytes like x03 that are not legal XML characters will floor you. 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 donpark at docuverse.com Fri Sep 3 16:47:58 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:39 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <4.2.0.58.19990903080617.00c14680@pophost1.fore.com> Message-ID: <000101bef61b$cc130120$114bfea9@w21tp> >I hope the flow of information isn't impeded by anybody >feeling that they have to watch what they say. It is worse than that. Have you noticed that most, if not all, of the participants in this discussion are 'independents'? I don't see anyone from Microsoft or Sun jumping up and down over this issue. The effects are clear, but the cause is confidential. 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 jmg at trivida.com Fri Sep 3 16:51:48 1999 From: jmg at trivida.com (Jeff Greif) Date: Mon Jun 7 17:14:39 2004 Subject: why distinctions within XHTML? References: <A26F84C9D8EDD111A102006097C4CD0D0E8F55@sohos002.ied-support.net> Message-ID: <0b4901bef61b$e5d27f00$a24630d1@trivida.com> The ability to put XHTML inside XML seems just to depend upon -- having a well-defined XHTML -- having a DTD or schema for the containing document that allows XHTML elements inside some of the XML elements it defined. Clearly the XHTML modularization will help with this. The ability to put XML inside XHTML is more problematic. Has anyone ever proposed some kind deferred validation -- the document is well-formed but not valid according to the XHTML DTD, but it becomes valid when the XML is transformed by the accompanying XSL stylesheet into XHTML? That is, the document with the XSL result tree substituted for the original XML becomes a valid document. In general, the application processing the document might be required, as instructed by the document contents, to process the document in several stages, deferring validation until some of those stages had completed. Is anyone working on something like this? Jeff ----- Original Message ----- From: Mark Birbeck <Mark.Birbeck@iedigital.net> To: XML-Dev Mailing list <xml-dev@ic.ac.uk> Sent: Friday, September 03, 1999 5:02 AM Subject: RE: why distinctions within XHTML? > The world needs the ability to nest XHTML inside XML and XML inside > XHTML as soon as possible, true. But that will take schemas if you want > validation, so there's nothing XHTML can do about that. The world also > wants lots of neat little chunks of parts of XHTML to put in their > mobile phones and toaster browser code. But that's still early days. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jjc at jclark.com Fri Sep 3 16:54:01 1999 From: jjc at jclark.com (James Clark) Date: Mon Jun 7 17:14:39 2004 Subject: Why namespaces? References: <A26F84C9D8EDD111A102006097C4CD0D0E8F57@sohos002.ied-support.net> Message-ID: <37CFDF4B.AA16913A@jclark.com> Mark Birbeck wrote: > A template of 'P' would match all elements that have a local > name 'P', regardless of the namespace they came from, Not true. It matches a P whose expanded-name has a local name of P and a null namespace URI. James xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 3 17:19:25 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:39 2004 Subject: why distinctions within XHTML? In-Reply-To: <0b4901bef61b$e5d27f00$a24630d1@trivida.com> References: <A26F84C9D8EDD111A102006097C4CD0D0E8F55@sohos002.ied-support.net> Message-ID: <4.1.19990903111904.0493f5c0@mail.webgeek.com> At 07:52 AM 9/3/99 -0700, Jeff Greif wrote: >The ability to put XML inside XHTML is more problematic. Has anyone ever >proposed some kind deferred validation Importing XML content into an XHTML document is also a function of modularization. Validation rules and how that might be accomplished is an open issue. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmellen at dlsc.dla.mil Fri Sep 3 17:43:16 1999 From: jmellen at dlsc.dla.mil (Mellen, James) Date: Mon Jun 7 17:14:39 2004 Subject: Wanted an XML DTD for an MSDS (848) Message-ID: <D4EF98BF06B3D211B42B0004AC57AFC003AE57DF@dlscex1.dlis.dla.mil> Hello, I am certain there has to be an XML compliant DTD for a Material Safety Data Sheet (MSDS). This DTD would ideally follow the X12 EDI standard for an 848. Any help would really be appreciated. Thank you. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From yiminz at timberline.com Fri Sep 3 18:45:22 1999 From: yiminz at timberline.com (yimin zhu) Date: Mon Jun 7 17:14:39 2004 Subject: No subject Message-ID: <2D722CFF0999D111AB860001FA375F1002FB714B@laposte.timberline.com> Could anybody give me some tips on how to manage XML document instances? We have a schema with a monstrous size, against which we can generate different document instances such as vendors, contractors, projects, estimates, and so on. Each document instance may have many recorder sets as well. How can we effectively and efficiently manage them as XML files? Yimin Zhu Timberline Software Corp. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wunder at infoseek.com Fri Sep 3 19:03:49 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:14:39 2004 Subject: XHTML & Schemas In-Reply-To: <805C62F55FFAD1118D0800805FBB428D02BBFE5A@cc20exch2.mobilit y.com> Message-ID: <3.0.5.32.19990903100151.00abb200@corp.infoseek.com> At 10:39 AM 9/3/99 -0400, Hunter, David wrote: > >(e.g., If a search engine is going to be searching XHTML pages it isn't >going to be processing the XHTML for display, but it doesn't really care if >those pages are in one flavour or the other anyway. It just wants to be >able to find the XHTML.) No, search engines do care, but they care differently. They do various special things with framesets, make heuristic guesses about what is content and what is navigation by interpreting text decoration, etc. Then people type queries like "computers" or "internet". Sigh. wunder (search engine engineer) -- Walter R. Underwood Staff Engineer, Infoseek Corp. wunder@infoseek.com http://software.infoseek.com/cce/ (my product) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Sep 3 19:02:29 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:39 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <4.2.0.58.19990903080617.00c14680@pophost1.fore.com> from "Mark Nutter" at Sep 3, 99 08:14:58 am Message-ID: <199909031738.NAA12449@locke.ccil.org> Mark Nutter scripsit: > Are we sure there was a (singular) compelling argument? Ann Navarro said there was. > I'm trying to avoid taking sides here, but I'm getting a sense that perhaps > conditions might be ripe for the evolution of conspiracy theories that > aren't really accurate or helpful. "Whenever two or more business people gather in one place it is to conspire against the public good." -- Adam Smith -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 3 19:22:14 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:39 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <199909031738.NAA12449@locke.ccil.org> References: <4.2.0.58.19990903080617.00c14680@pophost1.fore.com> Message-ID: <4.1.19990903132228.047ccf00@mail.webgeek.com> At 01:38 PM 9/3/99 -0400, John Cowan wrote: >Mark Nutter scripsit: > >> Are we sure there was a (singular) compelling argument? > >Ann Navarro said there was. Ah....no, I don't believe I said that. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken_north at compuserve.com Fri Sep 3 19:26:39 1999 From: ken_north at compuserve.com (Ken North) Date: Mon Jun 7 17:14:39 2004 Subject: Wanted an XML DTD for an MSDS (848) References: <D4EF98BF06B3D211B42B0004AC57AFC003AE57DF@dlscex1.dlis.dla.mil> Message-ID: <008301bef631$e78c13e0$0b00a8c0@grissom> From: Mellen, James <jmellen@dlsc.dla.mil> > I am certain there has to be an XML compliant DTD for a Material Safety Data > Sheet (MSDS). This DTD would ideally follow the X12 EDI standard for an > 848. James, The Commerce Desk Repository has X12 and EDIFACT messages, including an 848 under version V4011: http://www.commercedesk.com/content/workspaces/workspace.asp?LoadCurrentItem =True&WorkspaceID=Repository =================================================== Don't miss XML One Europe, London, October 6-8, 1999 http://www.xmlconference.com/xmleuro > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 Sep 3 22:34:44 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:39 2004 Subject: weekend reading - distributed XML development Message-ID: <199909032037.QAA17061@hesketh.net> After XML Developer Days in Montreal, my head's been buzzing with ideas about the prospect of a very different approach to XML vocabulary and application development than the committee model that is typically presented as the 'best' approach now. It's part 'worse is better', part 'let users think for themselves', and part 'so how can we harness this anarchy and make it productive?' I'd love to hear what people think - I expect that many folks out there will conclude that I've lost it, if you haven't already, but I really don't mind. It is a rough draft, written between chapters of a book approaching deadline, so there are undoubtedly flaws, which you're welcome to find. Enjoy! http://www.simonstl.com/articles/doubting.htm Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Sep 3 22:31:35 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:39 2004 Subject: Consensus and Community (W3C and xml-dev) In-Reply-To: <4.1.19990903132228.047ccf00@mail.webgeek.com> from "Ann Navarro" at Sep 3, 99 01:22:59 pm Message-ID: <199909032107.RAA19859@locke.ccil.org> Ann Navarro scripsit: > At 01:38 PM 9/3/99 -0400, John Cowan wrote: > >Mark Nutter scripsit: > > > >> Are we sure there was a (singular) compelling argument? > > > >Ann Navarro said there was. > > Ah....no, I don't believe I said that. I was in error: you said "some compelling arguments". -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 3 22:58:44 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:39 2004 Subject: weekend reading - distributed XML development In-Reply-To: <199909032037.QAA17061@hesketh.net> References: <199909032037.QAA17061@hesketh.net> Message-ID: <14288.13282.376306.774835@localhost.localdomain> Simon St.Laurent writes: > After XML Developer Days in Montreal, my head's been buzzing with > ideas about the prospect of a very different approach to XML > vocabulary and application development than the committee model > that is typically presented as the 'best' approach now. It's part > 'worse is better', part 'let users think for themselves', and part > 'so how can we harness this anarchy and make it productive?' I should mention that this was one of the main reasons that I supported the idea of Namespaces: since they are built on URIs, they allow *anyone* with Web space (or even an e-mail address) to create a globally-unique Namespace, and many of those, I imagine, will be used for inline markup in HTML documents. The idea of Namespaces is to decentralize the design effort, just as Simon would like, and then to let the market consolidate around what end up looking like the most important (and promising) proposals. There's an opportunity for a whole different, bottom-up process here, somewhat similar to what happens in the business world with the deregulation of the utilities and phone companies (put a windmill in your backyard and start selling power to the grid). 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 joubin at inch.com Sat Sep 4 01:46:12 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:39 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 01:54:39 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:39 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sat Sep 4 12:42:59 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:40 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <4.1.19990902101554.04278a70@mail.webgeek.com> References: <199909021400.KAA16537@hesketh.net> <4.1.19990902094108.0426dc40@mail.webgeek.com> <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <199909021442.KAA18395@hesketh.net> At 10:18 AM 9/2/99 -0400, Ann Navarro wrote: >What is so much harder to do if next it was said: Now that we're nice and >tidy with XHTML 1.0, we move forward with a single flavor, be it <whatever >one is chosen>, and we modularize that, and extend that? If I a) believed that was in fact the group's direction and b) believed it would be possible, once three namespaces had been unleashed and software written I might think that in fact it wouldn't be so difficult, and that this three-vs.-one issue was just a minor curve in the road. Unfortunately, I doubt a, and my doubt in b makes a pretty irrelevant anyway. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sat Sep 4 14:19:33 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:40 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <4.1.19990902101554.04278a70@mail.webgeek.com> References: <199909021400.KAA16537@hesketh.net> <4.1.19990902094108.0426dc40@mail.webgeek.com> <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <199909021442.KAA18395@hesketh.net> At 10:18 AM 9/2/99 -0400, Ann Navarro wrote: >What is so much harder to do if next it was said: Now that we're nice and >tidy with XHTML 1.0, we move forward with a single flavor, be it <whatever >one is chosen>, and we modularize that, and extend that? If I a) believed that was in fact the group's direction and b) believed it would be possible, once three namespaces had been unleashed and software written I might think that in fact it wouldn't be so difficult, and that this three-vs.-one issue was just a minor curve in the road. Unfortunately, I doubt a, and my doubt in b makes a pretty irrelevant anyway. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sat Sep 4 14:31:56 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:40 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <4.1.19990902101554.04278a70@mail.webgeek.com> References: <199909021400.KAA16537@hesketh.net> <4.1.19990902094108.0426dc40@mail.webgeek.com> <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <199909021442.KAA18395@hesketh.net> At 10:18 AM 9/2/99 -0400, Ann Navarro wrote: >What is so much harder to do if next it was said: Now that we're nice and >tidy with XHTML 1.0, we move forward with a single flavor, be it <whatever >one is chosen>, and we modularize that, and extend that? If I a) believed that was in fact the group's direction and b) believed it would be possible, once three namespaces had been unleashed and software written I might think that in fact it wouldn't be so difficult, and that this three-vs.-one issue was just a minor curve in the road. Unfortunately, I doubt a, and my doubt in b makes a pretty irrelevant anyway. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sat Sep 4 14:32:28 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:40 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <4.1.19990902101554.04278a70@mail.webgeek.com> References: <199909021400.KAA16537@hesketh.net> <4.1.19990902094108.0426dc40@mail.webgeek.com> <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <199909021442.KAA18395@hesketh.net> At 10:18 AM 9/2/99 -0400, Ann Navarro wrote: >What is so much harder to do if next it was said: Now that we're nice and >tidy with XHTML 1.0, we move forward with a single flavor, be it <whatever >one is chosen>, and we modularize that, and extend that? If I a) believed that was in fact the group's direction and b) believed it would be possible, once three namespaces had been unleashed and software written I might think that in fact it wouldn't be so difficult, and that this three-vs.-one issue was just a minor curve in the road. Unfortunately, I doubt a, and my doubt in b makes a pretty irrelevant anyway. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sat Sep 4 14:39:39 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:40 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <199909021442.KAA18395@hesketh.net> References: <4.1.19990902101554.04278a70@mail.webgeek.com> <199909021400.KAA16537@hesketh.net> <4.1.19990902094108.0426dc40@mail.webgeek.com> <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <199909041242.IAA09463@hesketh.net> At 10:45 AM 9/2/99 -0400, Simon St.Laurent wrote: >If I > >a) believed that was in fact the group's direction > [etc.] This just popped up in my mailbox (twice?!), though I sent it Thursday. I am _not_ trying to restart the XHTML debate. If you just got this mysteriously late message, please note the timestamp and ignore it. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 Sep 4 17:54:07 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:14:40 2004 Subject: Why namespaces? Message-ID: <A26F84C9D8EDD111A102006097C4CD0D0E8F5C@sohos002.ied-support.net> James Clark wrote: > Mark Birbeck wrote: > > > A template of 'P' would match all elements that have a local > > name 'P', regardless of the namespace they came from, > > Not true. It matches a P whose expanded-name has a local > name of P and a null namespace URI. Many, many, apologies. I was looking at Section 5.5 of XSLT which discusses the pecking order in which patterns would be matched. I understood it to mean that if I had: <xsl:template match="x:para"> ... </xsl:template> it would score higher than: <xsl:template match="para"> ... </xsl:template> when processing the first 'para' node in the tree: <doc xmlns="z"> <para xmlns="x" /> <para xmlns="y" /> </doc> but lower (actually, not at all) when processing the second 'para' element. Although this scoring mechanism is right, the mistake I made was thinking that the template rules were expanded in the context of the node that was being processed - i.e., that: match="para" would be: match="x:para" in one situation and: match="y:para" in another. However, looking at XPath again (Section 2.3), I realise that the node context is from the element that contains the XPath expression (in this case the template), and not the source document. And this is obviously why as a rule XPath doesn't provide the default namespace as one of the namespaces provided in the node context - because it would be the wrong default (from XSLT, in this case, not the source). So, as you say, the definition of the pattern 'para' would be just that ... 'para' (or <NULL>:para as an expanded name). And, patterns with a NULL namespace will only match elements from the default namespace in the source document. Sorry if I caused any confusion. Best regards, Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 18:47:58 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 18:49:07 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 19:03:51 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 19:55:16 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:40 2004 Subject: listserver gone mad ? (was: Re: ATTN:....) Message-ID: <000a01bef6ff$6937cab0$dcd7f0cf@javadev.cwi.cablew.com> Dear All, Please note that I am _not_ the party that is repeatedly RE-posting my singular post of 9/2 to xml-dev, and that I am as annoyed by this as you are. Best Regards, Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 20:41:57 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 20:41:57 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 20:53:23 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 20:53:25 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ejfreed at infocanvas.com Sat Sep 4 21:17:42 1999 From: ejfreed at infocanvas.com (Erik James Freed) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) In-Reply-To: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> Message-ID: <NCBBICOBAHLCGGGGCEIEOECGELAB.ejfreed@infocanvas.com> I always wondered why the Java name space semantics and syntax were not used. The heirarchical 'dot' notation has pretty broad acceptance... I know -get my head out of the clouds :-() erik -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of joubin Sent: Thursday, September 02, 1999 11:28 AM To: Kay Michael; XMLDev list Subject: Re: ATTN: Please comment on XHTML (before it's too late) From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Sat Sep 4 22:04:01 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:40 2004 Subject: Consensus and Community (W3C and xml-dev) References: <000101bef61b$cc130120$114bfea9@w21tp> Message-ID: <37D17B93.F5BB834B@pacbell.net> Don Park wrote: > Mark Nutter wrote: > >I hope the flow of information isn't impeded by anybody > >feeling that they have to watch what they say. > > It is worse than that. Have you noticed that most, if not all, of the > participants in this discussion are 'independents'? I don't see anyone from > Microsoft or Sun jumping up and down over this issue. You don't see most folk with official roles at W3C saying very much here at all on this issue, that is, ... > The effects are clear, but the cause is confidential. ... the reason being those W3C member confidentiality agreements. Which easily mask all manner of shady dealings, without needing to even be called "conspiracy". (Though we really do need some good muckraking journalism coverage of W3C lately!!) That is, it's specifically those who know what's going on best who are "impeded" by knowing they "have to watch what they say". - Dave p.s. With respect to XHTML, it'd be easy enough to do a better job (i.e. fix the broken bits) ... but the hard part is to get a browser to support it. Luckily there's source to Mozilla -- a "one namespace" solution for that part of the world doesn't seem wholly outrageous if there exists a concrete proposal. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Sat Sep 4 23:02:42 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> From: Kay Michael <Michael.Kay@icl.com> >I seem to recall, at the time Namespaces was being debated, a lone voice >saying that of course namespaces should be hierarchic rather than >single-level. Shame that none listened. Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical spaces. But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, pretty) when the __information__ that the notational system is designed to convey is disregarded? (Further motivation: A hierarchical naming context will greatly facilitate 'modularization'.) /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc > >Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at qub.com Sun Sep 5 01:03:33 1999 From: paul at qub.com (Paul Tchistopolskii) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) References: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> Message-ID: <00b201bef72a$703410a0$5df5c13f@PaulTchistopolskii> ----- Original Message ----- From: joubin <joubin@inch.com> To: Kay Michael <Michael.Kay@icl.com>; XMLDev list <xml-dev@ic.ac.uk> Sent: Thursday, September 02, 1999 11:27 AM Subject: Re: ATTN: Please comment on XHTML (before it's too late) > From: Kay Michael <Michael.Kay@icl.com> > > >I seem to recall, at the time Namespaces was being debated, a lone voice > >saying that of course namespaces should be hierarchic rather than > >single-level. Shame that none listened. > > Exactly. The whole point of URI/URL schemas (AFAIU) is to map hierarchical > spaces. > > But XML-NS simply uses the cumbersome notation (it ain't, strictly speaking, > pretty) when the __information__ that the notational system is designed to > convey is disregarded? > > (Further motivation: A hierarchical naming context will greatly facilitate > 'modularization'.) Namespaces should be hierarchic. I think that now most of XML developers would agree. Is there any procedure for voting things like this? I think if 90% of XML developers would now vote for namespaces to be hierarchic, it may change something. Rgds.Paul. PS. I guess if voting would become more popular procedure than it is now we'l get more efficient movement, because the nature of maling-list or any newsconference does not provide enough statistics. Definately, namespaces are *so* important that manking 'not perfect' desision in this area would affect many ( if not all of) XML applications, so I think that voting on issues like this is reasonable. Also in some cases voting may decrease the level of useless agression. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= paul@pault.com www.renderx.com www.pault.com XMLTube * Perl/JavaConnector * PerlApplicationServer =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 5 02:02:10 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:40 2004 Subject: How about over 1,000,000 XHTML Namespace URIs? In-Reply-To: <4.1.19990902101554.04278a70@mail.webgeek.com> References: <199909021400.KAA16537@hesketh.net> <4.1.19990902094108.0426dc40@mail.webgeek.com> <4454C011BDE5D211B6C800609776E54016CD24@master.design-intel ligence.com> Message-ID: <199909021442.KAA18395@hesketh.net> At 10:18 AM 9/2/99 -0400, Ann Navarro wrote: >What is so much harder to do if next it was said: Now that we're nice and >tidy with XHTML 1.0, we move forward with a single flavor, be it <whatever >one is chosen>, and we modularize that, and extend that? If I a) believed that was in fact the group's direction and b) believed it would be possible, once three namespaces had been unleashed and software written I might think that in fact it wouldn't be so difficult, and that this three-vs.-one issue was just a minor curve in the road. Unfortunately, I doubt a, and my doubt in b makes a pretty irrelevant anyway. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.sun.com Sun Sep 5 05:10:49 1999 From: Jon.Bosak at eng.sun.com (Jon Bosak) Date: Mon Jun 7 17:14:40 2004 Subject: Namespaces in XML and XHTML Message-ID: <199909050304.UAA02082@boethius.eng.sun.com> Several people have suggested to me that a recent article of mine on XML namespaces might serve as a useful reference in the current discussions of namespaces in XHTML. An edited version of that article appears below. W3C members can find the original, dated 21 August, in the archives of the W3C XML Plenary (w3c-xml-plenary). It should be understood that this edited version represents nothing more than my personal opinion. It should also be understood that I am speaking here neither in my role as Chair of the W3C XML Coordination Group nor in my role as Chair of the W3C XML Plenary, but simply as an interested individual. W3C members should read the original to regain its original context. With the exception of quotations from other writers, used here by permission, and excerpts from publicly available documents, this work is my own. I must acknowledge the kind assistance of Tim Bray, James Clark, Dave Hollander, Eve Maler, Murray Maloney, David Megginson, Makoto Murata, Bill Smith, C. M. Sperberg-McQueen, and Lauren Wood in preparing this article. However, this acknowledgement should not be taken to imply their endorsement of its conclusions, in whole or in part. With the exception of material explicitly attributed to others, all opinions expressed in the following are mine, and I am entirely responsible for any errors or omissions. Jon Bosak Los Altos, California 4 September 1999 ------- Sources ------- The Namespaces Recommendation is at http://www.w3.org/TR/1999/REC-xml-names-19990114/ The best explanation of namespaces was written by James Clark and can be found at http://www.jclark.com/xml/xmlns.htm James's paper should be required reading for anyone involved in a discussion of namespaces. ------------------------------ What are namespaces all about? ------------------------------ Namespaces are about unique identification; they are not about meaning. Identification is necessary to the establishment of meaning, but it does not constitute meaning in itself. ----------------------------- What are namespaces good for? ----------------------------- It might be thought that mere identification is not worth much, but the designers of the namespace recommendation thought otherwise. Namespace declarations give us a way to confer upon element types and attribute names a unique identity. This does not tell us anything about what such names mean, but it does provide a way to unambiguously associate an unlimited number of different kinds of processes with objects having the names so distinguished. It allows us to say, "this thing here has a certain quality (its type or name) that is identical to the corresponding quality of the thing in that place over there," regardless of where, when, and in what context these things are actually discovered, together or separately. On the basis of that ability, we trust that we can apply processes to elements having a particular type, or to attributes having a particular name, and be reasonably sure that such processes will not be applied to other elements or attributes that seem to have the same type or name but really belong to some other category. This is considered to be a Good Thing. My favorite description of the function of namespaces comes from one of the editors of the Namespaces Recommendation, Tim Bray: namespaces are a device "for allowing programmers to write programs that will reliably find the items of information that they are designed to process even in a distributed and heterogeneous environment." Another, I think equally valid, view of the function of namespaces as they are defined in the Recommendation was given to me by another one of the editors, Dave Hollander: allowing us to avoid name collisions is an essential step toward being able to form new documents consisting of pieces from other documents without forcing us to change the element types or attribute names. ---------------------------------- What kind of thing is a namespace? ---------------------------------- A namespace is a collection of names. Each name in this collection is a pair consisting of the namespace name and a colon-free XML 1.0 name. The namespace name has the form of a URI reference. URIs were chosen for this purpose primarily because they (or at least their URL subset) are under the control of a naming authority. A URL in this role is really performing the function that URNs are intended to perform; URLs were allowed to serve in this place because it's possible to administer URLs so that they work as URNs, and because URNs were an unproven technology. A namespace is an abstract object. Namespaces live in the same place as other abstract objects such as the set of letters of the alphabet, the set of words in the English language, and the set of integers. The namespace itself is distinct from anything that might be associated with it and belongs to a level of reality different from the kinds of things that we typically would want to associate with it. (Whether names have real existence is an interesting question. Persons wishing to pursue this matter can start with the article in any large encyclopedia under the heading "Realism" or "Nominalism," where they will discover that this issue, while not completely resolved, has already received some attention.) -------------------------------------- What kind of thing is not a namespace? -------------------------------------- Anything that is not a name is not a part of a namespace; a namespace can have nothing but names in it. Here are some important examples of things that are not namespaces: - A list of the names in a namespace - A sequence of characters that can be interpreted as a list of the names in a namespace - A description of the things named by the names in a namespace - A set of constraints on the things named by the names in a namespace - A set of procedures associated with the things named by the names in a namespace ----------------------------------- What does a namespace URI refer to? ----------------------------------- The URI in a namespace declaration may or may not refer to an actual resource that can be retrieved by a computer; if it does, the resource so identified may or may not have useful things to tell us about things labeled with the names associated with the URI. The statement in the Namespaces Recommendation that "It is not a goal that it [the namespace URI] be directly usable for retrieval of a schema (if any exists)" is not mere rhetorical fluff but rather represents a concrete position taken by the XML Working Group after months of debate and in direct opposition to an equally concrete point of view to the contrary. In the word's of James Clark's paper (cited above): The role of the URI in a universal name is purely to allow applications to recognize the name. There are no guarantees about the resource identified by the URI. Some future Namespaces Recommendation _could_ say that namespace URIs are expected to resolve to a resource or are required to resolve to a resource. However, the Namespaces Recommendation that we actually have chose, very deliberately, to say that the utility of Namespaces in XML does not depend on what (if any) resource is at the other end of a URI. As James notes in the same paper: It would of course be very useful to have namespace-aware validation: to be able to associate each URI used in a universal name with some sort of schema (similar to a DTD) and be able to validate a document using multiple such URIs with respect to the schemas for all of the URIs. The XML Namespaces Recommendation does _not_ provide this. A good reason for not providing an explicit association between namespaces and schemas is to allow namespaces to be associated with things other than schemas and to allow them to be associated with multiple expressions of the same schema, as for example a schema expressed as a DTD and the same schema expressed using the eventual W3C XML Schema language. -------------------------------------------------------- What kinds of things can be associated with a namespace? -------------------------------------------------------- Just about anything can be associated with a namespace. Some of the more useful kinds of things that can be associated with namespaces are stylesheets, Java classes, DTDs, Active-X objects, extended linking groups, schemas, and prose descriptions. ---------------------------------------------------------------------- Is a there a one-to-one correspondence between namespaces and schemas? ---------------------------------------------------------------------- With the understanding that this question has meaning only in the relatively small class of all possible uses of namespaces in which they are being used in conjunction with schemas, the answer is no, there is not a one-to-one correspondence between namespaces and schemas. One namespace may be associated with multiple schemas; it has been common practice for years to apply multiple schemas (DTDs) to documents in order to check them against different sets of constraints. Conversely, it is easy to imagine cases where multiple namespaces might be used within documents that conform to a single schema. David Megginson has provided a simple example: a geographical markup language...might use separate Namespaces for land elevation, coastline information, and land use to help avoid naming conflicts... And, of course, a DTD can be generated for any arbitrary well-formed document that happens to include names from multiple namespaces. This scenario is admittedly artificial, but it proves that the association of multiple namespaces with a single schema is always possible. Since there is no necessary association between a namespace and anything in particular, there is no necessary association between a namespace and a schema, and it follows from this that all arguments based on the assumption of a necessary mapping from a single namespace to a single schema are invalid on their face. This includes in particular the argument that XHTML should use more than one namespace because it specifies more than one DTD. This is not to say that the conclusion that XHTML should have multiple namespaces is false, it's just to say that you can't adduce a one-to-one mapping between namespaces and schemas as a premise for that argument. ------------------------------------- Should XHTML use multiple namespaces? ------------------------------------- I agree with David Megginson that "the HTML WG [should] maintain a single HTML Namespace as long as practical and find another mechanism to indicate flavours and versioning." Among the reasons that can be brought for this view, I find the following most convincing: - The main argument for specifying three namespaces for XHTML rests on the assumption that there is a one-to-one association between namespaces and schemas. This is not true. - A second argument for specifying three namespaces is that it's intended to indicate that XHTML actually specifies three different tag languages and that <h2> in one of these languages means something basically different from <h2> in the other two. In my opinion, <h2> means basically the same thing in all three versions. This is why we call all three of them "XHTML." HTML 4 has three DTDs, too, but no one has suggested that HTML 4 is actually three different languages. Lauren Wood has pointed out to me that SoftQuad's HTML authoring tool has used something like 15 different HTML DTDs in the lifetime of the product. It would seem strange to say that the people using the product were actually working in 15 different languages, all of them called HTML. This is not what we usually mean by the word "language." I think that the HTML WG should reconsider whether it's really defining three different languages, being careful to distinguish between a machine-readable structural description such as that provided by a DTD and a complete human-readable statement of its meaning such as that provided by a complete and accurate prose description. If the HTML WG decides to maintain the position that XHTML is defining three different languages, then it should be ready to explain how an <h2> in one would materially differ in meaning from an <h2> in another, "meaning" here being expressed in terms of the intention of the person who causes elements to have the type "h2." - Another way of making what I believe to be essentially the same point is that distinctions between a strict <h2> and a transitional <h2> are not reflected in actual machine processing outside of validation. - If XHTML really is several languages and the similarly named elements of those languages really are different from each other, then those different languages are going to require different HTML DOMs. Jon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sunker at telkom.net Sun Sep 5 07:06:58 1999 From: sunker at telkom.net (sunker@telkom.net) Date: Mon Jun 7 17:14:40 2004 Subject: Unicode Message-ID: <61D3A6AB14FED211856500001C055D9633DFBE@FS01> Hi all, I have some problem with unicode in chinese characters. any body have some simple xml used this problem. How to change the latin characters display into chinese characters display. when i write: <?xml version='1.0' encoding="ISO-639"> -->> DOES N0T WORK FOR ENCODING <problem> <language xml:lang='cn'>Chinese language</language> -->> not change in chinese characters </problem> thanks.. http://www.geocities.com/researchtriangle/campus/7211 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 5 09:53:04 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:40 2004 Subject: Hierarchical Namespaces (was Re: ATTN: Please comment on XHTML (before it's too late)) References: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> <00b201bef72a$703410a0$5df5c13f@PaulTchistopolskii> Message-ID: <000001bef773$ea9fe640$0300000a@cygnus.uwa.edu.au> > Namespaces should be hierarchic. I think that now most of > XML developers would agree. Namespace URI's are hierarchical already, so all it would take is prefix matching. I briefly suggested this when namespaces first came out and again in more detail in a couple of posts last week. Upon further reflection, it wouldn't even need a modification to XPath (although such a modification could make prefix matching cleaner). As far as I can tell, all you would need to do is something like: p[starts-with(namespace-uri(),"http://www.w3.org/xhtml1/")] James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net <pipe>Ceci n'est pas une pipe</pipe> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 5 10:24:40 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:40 2004 Subject: XHTML & Schemas References: <37CD441A.1FF39F6E@prescod.net> <010b01bef530$fddbd330$4602a8c0@capella.co.il> <37CE9CE0.58B3AF87@prescod.net> Message-ID: <022001bef777$136e09a0$4602a8c0@capella.co.il> Paul Prescod <paul@prescod.net> wrote: > Oren Ben-Kiki wrote: > > ... If people want to have a single > > namespace for XHTML, they should first go and re-write the above paragraph > > in the XSchema draft. Right? > > What would you rewrite it to? Let's say you have three schemas for XHTML > on your hard drive or on the web. Let's say that you have a document > like this: > > <MYDOC> > <P xmlns="http://www.w3.org/TR/XHTML">This is supposed to be loose.</P> > <P xmlns="http://www.w3.org/TR/XHTML">This is supposed to be strict.</P> > </MYDOC> > > How would you select the schema to use for each? I'll try to formulate the outline of a general solution (you did ask :-). <Outline> 1. Allow a document to declare "I was created with the intention of satisfying the following schema". A schema identification is a MIME type. I know what the chances of all that are, so we'd probably see schemas named by URIs. It doesn't really matter for the rest of the points. For the people who claim that a document should not declare its own stylesheet/schema/whatever - One must specify _something_ that allows the application to know what document type this is. This is known, today, as a MIME type. Why mix things up by inventing another typing system? How the document is associated with a MIME type isn't really within XML's realm. But just like HTML had add a META tag, even though HTTP is expected to provide the relevant data, I'd expect there to be a directive which would specify the meta information of an XML document (<?META?>) - be it a MIME type, an XSchema, or whatever. For Davig Megginson, who wants the same document to live under more then one XSchema - (i) this problem applies to MIME types in general, bring it up there; (ii) application are free to ignore a the document's specified meta data and use a different one (they often do, anyway). 2. All of this has nothing whatsoever to do with namespaces. The XSchema itself refers to names - and hence, makes use of namespaces to uniquely define these names. Period. There's no other restriction of special relationship between schemas and names. 3. Actually fetching the schema is a tricky matter. I have some notions but that's not a critical issue - there are several obvious ways to tackle it; I'm not going to fuss over it unless something twisted is suggested :-) 4. Given that Schemas can export and import stuff, the problem of "modularization" is already solved. If you want to mix and match MathML with XHTML and YourML, simple create your own super-schema which refers to these three, and you are done. The power you'll have mixing pieces from different schemas would depend on only one thing - the strength of the schema language itself. Making intelligent use of namespaces reduces the need for powerful constructs in this language - but does not remove the need altogether. I fully trust the XSchema WG to come up with an adequate set of constructs, if they put their mind to it. </Outline> With regard to your sample document. The application won't to be able to distinguish between two 'p' elements unless there was _something_ different about them. This something might be anything at all expressible in the XSchema language. For example, suppose I could say in an XSchema "if attr 'A' contains 'VALUE', the element obeys a rule from this schema, otherwise a rule from that schema" then your document would look like: <MYDOC> <P xmlns="http://www.w3.org/TR/XHTML" type="loose">This is supposed to be loose.</P> <P xmlns="http://www.w3.org/TR/XHTML" type="strict">This is supposed to be strict.</P> </MYDOC> A more typical example might be: <MYDOC> <xhtml:p xmlns="http://www.w3.org/TR/XHTML"> This is a paragraph with some <math:equation>equation</math:equation> in it. </xhtml:p> </MYDOC> This would require that in an XSchema one would be able to say "the element define in this schema may also contain the following attributes/elements". Much simpler then your case, and demonstrates why namespaces are a great help for mixing and matching. <SideNote> I fully agree with you on what should be done in XHTML for now, which is to remove any reference to namespaces from the XHTML specs until this is finalized in some recommendation. Only then, when we know how it is to be done, should namespaces be added to the relevant drafts/recommendations. Doing anything else is, IMVHO, irress^H^H^H^H^H^Hpremature. </SideNote> 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 paul at qub.com Sun Sep 5 12:08:44 1999 From: paul at qub.com (Paul Tchistopolskii) Date: Mon Jun 7 17:14:40 2004 Subject: Hierarchical Namespaces (was Re: ATTN: Please comment on XHTML (before it's too late)) References: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> <00b201bef72a$703410a0$5df5c13f@PaulTchistopolskii> <000001bef773$ea9fe640$0300000a@cygnus.uwa.edu.au> Message-ID: <00f101bef787$5d699a00$5df5c13f@PaulTchistopolskii> > > Namespaces should be hierarchic. I think that now most of > > XML developers would agree. > > Namespace URI's are hierarchical already, so all it would take is prefix > matching. I briefly suggested this when namespaces first came out and again > in more detail in a couple of posts last week. > > Upon further reflection, it wouldn't even need a modification to XPath > (although such a modification could make prefix matching cleaner). As far as > I can tell, all you would need to do is something like: > > p[starts-with(namespace-uri(),"http://www.w3.org/xhtml1/")] Maybe we have a different understanding of what is hierachical ? http://www.w3.org/TR/xhtml1/strict Do I understand right that version 2 would cause http://www.w3.org/TR/xhtml2/strict By the way - XT is now using xmlns:xsl=http://www.w3.org/XSL/Transform/1.0 This is smart. ;-) In opposite , the article ( http://www.jclark.com/xml/xmlns.htm ) ( by the same author! ;-) shows us: xmlns:HTML="http://www.w3.org/TR/REC-html40 Isn't it *not* that smart? Would't it be better to have: xmlns:HTML="http://www.w3.org/HTML/4.0 instead ? When I upgraded to the new version of XT, it was very polite for XT to notify me that I should change my good old stylesheet to use that new namespace. I guess that my *next* upgrade would go even smooter, because current namespace is providing some clue because of it's hierarhical form. > > Namespaces should be hierarchic. I think that now most of > > XML developers would agree. Rgds.Paul. PS. Actualy there are still some more problems, but thinking about more complex things would be easier after I'l understand some simple things. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 5 21:04:42 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:14:40 2004 Subject: ATTN: Please comment on XHTML (before it's too late) In-Reply-To: <00b201bef72a$703410a0$5df5c13f@PaulTchistopolskii> References: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> <00b201bef72a$703410a0$5df5c13f@PaulTchistopolskii> Message-ID: <199909051901.OAA07961@bruno.techno.com> [Paul Tchistopolskii:] > PS. I guess if voting would become more popular procedure > than it is now we'l get more efficient movement, because > the nature of maling-list or any newsconference does not > provide enough statistics. Definately, namespaces are *so* > important that manking 'not perfect' desision in this area > would affect many ( if not all of) XML applications, so > I think that voting on issues like this is reasonable. Interesting idea. A straw poll of stakeholders and developers, regardless of whether they have a voice within the W3C process, might influence that process. To be effective, all voters would have to make their votes public, as well as the rationale behind each vote. As it happens, because of W3C procedures, the voting done *within* the W3C is just a straw poll, anyway. It can only be a good thing to have one more straw poll available, especially if it is a poll of knowledgable, passionate individuals, rather than vested business interests. Such a poll might even become additional input for the W3C's Director's decision-making process. (That would be completely up to him, of course. I gather that he is allowed to consider or ignore anything he likes.) The voting idea appeals to me for several other reasons. I find these discussions in xml-dev extremely valuable, but I'm often left wondering who convinced who about what, if anything. I sometimes need to know that somebody's point (which I may not have fully understood) was or was not answered to that person's satisfaction. In the play "Twelve Angry Men" (all of which takes place in a jury room), the characters repeatedly vote on whether to convict the defendant. They can't leave the room until they're all lined up on the same side of the issue. In the first vote, it's 11-1 in favor of conviction. This excellent and demanding play is about how each of eleven votes are changed, one by one. In any important deliberation, one can easily imagine people going for one side or the other just to get an issue decided, usually by voting with the majority. (One of the votes in "12 Angry Men" changes exactly when the majority changes, to the unanimous disgust of the other 11 voters, regardless of which side they were on.) One can easily imagine passionate and unresolvable disagreements on any given issue, resulting in the technical-committee equivalent of a "hung jury". My 13 years of service on various ISO committees tells me that, in such a case, *both* sides are invariably *right*, and the real problem is that we're attempting to resolve the wrong issue, or to resolve several issues in the wrong order. A "hung jury" situation is neither to be feared, nor to be swept under the rug by any sort of administrative fiat; it is to be learned from and acted upon. It's very worthwhile to sort things out carefully, and it can be done if everyone has the goal of making a good standard, rather than meeting some private goal. There are no substitutes for shared goals, honesty or tenacity. For example, one has to be obedient to the muse of good design, when necessary, and say, "You have destroyed my case. You are right. Congratulations! Let's move on." I have seen this kind of graciousness repeatedly on this xml-dev list. One also has to stick to one's guns, until one's point is understood and answered. Some would call this rude behavior; in standards deliberations, I call it "working". I see this less often on this list, and I think that voting would make it more commonplace, by identifying those who need to be convinced. Some readers might not like the passion, and some writers might run out of patience. That happens. *shrug* Who would pay for the voting and publication machinery? Maybe a voter should pay $10 for the privilege of voting on a given issue, and certify that it's his or her own personal money that is being spent in this way. That would tend to indicate that votes would not be made lightly, and keep the ballot box from being bought by any given business interest. It would also pay for supporting the publication of votes made by people who may need to change their minds, and to say why they changed their minds. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 fax +1 972 994 0087 pager (150 characters max): srn-page@techno.com 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 ann at webgeek.com Sun Sep 5 21:57:05 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:40 2004 Subject: an unfilled need Message-ID: <4.1.19990905155519.0409f3a0@mail.webgeek.com> Through several recent private conversations, it has become very clear to me (and I believe to those others), that the XML community is facing a significant unfilled need. One that if left unfilled as we move forward with new and more complex activities, will result in even more difficulties than we currently face. That need is: a formal deterministic means of discovery. The authors of the namespace recommendation firmly stand behind the *intent* of the rec, in simply providing a name. The "rest of the world", is looking for a means of discovering what belongs with that name, it's associated definitions, semantics, and other data that may be necessary to complete their operations. In most ways, both groups are "right". Proposed continued work within the XML space at the W3C may address this in part, but not, in my opinion, in full. Many of the arguments we face in namespaces come about due to the unspoken argument that either a: they simply didn't go far enough, or b: additional work is necessary to complement them. This assertion has never really come to the forefront in our discussions on this topic. Until that time, these arguments over the appropriate choices in namespaces, in XHTML or anywhere else, will only proliferate. Rather than trying to second guess what those mechanisms may be, I'd personally prefer to simply not address the question of namespaces in XHTML until we know more (meaning remain silent on the issue in the XHTML PR, or purposefully defer within the spec): rather than being forced to make a choice between 1 or 3. Though if I must choose, my choice is still with 3, in that I find it easier to scale back granularity at a later date, than to add it. Food for thought at all levels, not just for this one issue. Respectfully, Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sun Sep 5 23:06:24 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:40 2004 Subject: Standards and Straw Polls In-Reply-To: <199909051901.OAA07961@bruno.techno.com> References: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> <00b201bef72a$703410a0$5df5c13f@PaulTchistopolskii> <199909051901.OAA07961@bruno.techno.com> Message-ID: <14290.55874.990261.422758@localhost.localdomain> Steven R. Newcomb writes: > The voting idea appeals to me for several other reasons. I find > these discussions in xml-dev extremely valuable, but I'm often left > wondering who convinced who about what, if anything. I sometimes > need to know that somebody's point (which I may not have fully > understood) was or was not answered to that person's satisfaction. In the XML Infoset WG, inside the Evil Empire, we have recently (and informally) taken up the following discussion pattern: 1. Introduce a point 2. Brief statements of opinion on all sides 3. Straw poll 4. Further, detailed discussion, if warranted Step #3 often shows so little support that the original proponent of a point chooses to drop it, or shows so much that we don't have to waste time on further discussion -- it's a very effective tool, especially since a small minority (say, someone like me) can often make a disproportionately large amount of noise. 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 Sun Sep 5 23:24:08 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need In-Reply-To: <4.1.19990905155519.0409f3a0@mail.webgeek.com> References: <4.1.19990905155519.0409f3a0@mail.webgeek.com> Message-ID: <14290.56269.189604.432980@localhost.localdomain> Ann Navarro writes: [on Namespaces] > That need is: a formal deterministic means of discovery. Discovery of what? Structural rules are easy enough, but they buy you almost nothing -- after all, if you give me an arbitrary piece of XML with a DTD, my software can tell you whether it's valid or not, but not what it means. [snip] > The "rest of the world", is looking for a means of discovering what > belongs with that name, it's associated definitions, semantics, and > other data that may be necessary to complete their operations. I cannot imagine how we could accomplish this, without simply mapping to an artificially restricted set of a-priori meanings. For example, for displaying HTML in a browser all the meaning you need is a collection of flow objects ("block text", "link", "graphic", etc.), but what kind of schema language or other discovery mechanism could allow software automatically to determine the meaning of <irony>Have a nice day!</irony> or <task> <tools-required> <tool>spanner</tool> <tool>needle-nosed pliers</tool> <tools-required> <steps> <step>loosen the main bolt with the spanner</step> <step>pull out the blue wire with the needle-nosed pliers</step> </step> </task> ? My point is that it's a pointless task, at least without access to much more advanced artificial intelligence than is currently available. In the mean time, though, it is entirely possible to write software that *does* know what it's looking for, such as a search engine that knows that HTML <cite> can hold a book title, or a Newsroom system that knows that XMLNews <subject-name> holds a description of one of the subjects of a News story. Namespaces are valuable precisely because they allow software to find markup that it knows about and to do something useful with it. While the Utopian vision of software that can figure out how to deal with what it *doesn't* know about is enticing, we're so far away from any practical implementation right now (except, again, for artificially-restricted subsets) that standardizing would be a waste of time. That's not to say that there's no point in standardizing some of those tiny subsets by providing facilities for linking to structural schemas and stylesheets, but it does mean that structural schemas and stylesheets provide don't solve the problem of what markup means -- so far, and for the forseeable future, that knowledge is hard-coded in the software itself at some level. 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 joubin at inch.com Sun Sep 5 23:58:44 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:41 2004 Subject: the necessary software infrastructure for open collaborative bodies Message-ID: <004801bef7ea$96102140$528ef0cf@javadev.cwi.cablew.com> A colleague recently asked me to check out http://www.collab.net/ [which I wish to make clear that I have no connection to (or $ interest) in any shape or form]. However I bring this up in this context since the point (by Paul) raises a related issue: the need for a software solution that provides the supporting informational infrastructure for _open_ creative collaborations (such as XML-DEV). I would assume that a prototype of such a system could be glued together using open protocols and boxes; if not, perhaps maybe interested developers should pool resources to define and create such a (policy driven) system. [I am certainly willing to contribute to this effort.] /br/ Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc -----Original Message----- From: Paul Tchistopolskii <paul@qub.com> [snip] > Is there any procedure for voting things like this? [snip] >PS. I guess if voting would become more popular procedure >than it is now we'l get more efficient movement, because >the nature of maling-list or any newsconference does not >provide enough statistics. Definately, namespaces are *so* >important that manking 'not perfect' desision in this area >would affect many ( if not all of) XML applications, so >I think that voting on issues like this is reasonable. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 6 01:04:45 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:41 2004 Subject: ATTN: Please comment on XHTML (before it's too late) In-Reply-To: <199909051901.OAA07961@bruno.techno.com> from "Steven R. Newcomb" at Sep 5, 99 02:01:39 pm Message-ID: <199909052341.TAA27417@locke.ccil.org> Steven R. Newcomb scripsit: > In the play "Twelve Angry Men" (all of which takes place in a jury > room), the characters repeatedly vote on whether to convict the > defendant. They can't leave the room until they're all lined up on > the same side of the issue. In the first vote, it's 11-1 in favor of > conviction. This excellent and demanding play is about how each of > eleven votes are changed, one by one. Helluva good Henry Fonda movie, too. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 docuverse.com Mon Sep 6 01:25:19 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:41 2004 Subject: Namespaces in XML and XHTML In-Reply-To: <199909050304.UAA02082@boethius.eng.sun.com> Message-ID: <000901bef7f6$6aa89080$3859fea9@w21tp> Jon, Thanks for the great article. It was as refreshing as a cool breeze after an Indian summer riot. I agree entirely with every point made and second his proposal that the HTML WG reconsider. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From joubin at inch.com Mon Sep 6 03:08:55 1999 From: joubin at inch.com (joubin) Date: Mon Jun 7 17:14:41 2004 Subject: Namespaces in XML and XHTML Message-ID: <009101bef805$2a25ae30$528ef0cf@javadev.cwi.cablew.com> Jon, Your paper was lucid and informative. However, it is silent on why (xml) namespaces are not (or should not be) hierarchical. Do you wish to elaborate on this aspect of namespaces? An abstract space doesn't necessarily have to be flat; and structured space intrinsically implies _nothing more_ than a formal relationship between its subsets. [In line with your reasoning regarding "abstract spaces", I refer you to the space of the Rationals, which is of course formally related to space of Integers; a relationship which some folks have found to be of some utility.] >(Whether names have real existence is an interesting [question ... which] >has *already* received some attention.) [*emphasis is mine*] The School of Symbols and Numerology (China, Zhou Dynasty, ~240 BC) :-) Best Regards, Joubin _____________________________________________________________________ member, alpha zero LLC 202.462.1655 dc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From aray at q2.net Mon Sep 6 03:36:58 1999 From: aray at q2.net (Arjun Ray) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need In-Reply-To: <4.1.19990905155519.0409f3a0@mail.webgeek.com> Message-ID: <Pine.LNX.3.95.990905220058.4031B-100000@mail.q2.net> On Sun, 5 Sep 1999, Ann Navarro wrote: > That need is: a formal deterministic means of discovery. That's an AI problem at root, and for now, a will-o'-the-wisp. > Rather than trying to second guess what those mechanisms may be, I'd > personally prefer to simply not address the question of namespaces in > XHTML until we know more (meaning remain silent on the issue in the > XHTML PR, or purposefully defer within the spec): rather than being > forced to make a choice between 1 or 3. This seems prudent. The recent rounds were occasioned by the change from 1 to 3, but surely the more basic issue was whether the XHTML spec at the current stage should make any statement about namespaces at all, never mind how many. (So, as counterproposal, for now change the number from 1 to 0!) Is there a compelling reason to have statements about namespaces in the draft? Arjun xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 6 04:04:27 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:41 2004 Subject: Hierarchical Namespaces (was Re: ATTN: Please comment on XHTML (before it's too late)) References: <004b01bef570$de5f91a0$c1d7f0cf@javadev.cwi.cablew.com> <00b201bef72a$703410a0$5df5c13f@PaulTchistopolskii> <000001bef773$ea9fe640$0300000a@cygnus.uwa.edu.au> <00f101bef787$5d699a00$5df5c13f@PaulTchistopolskii> Message-ID: <00fc01bef80c$61aa4f80$0300000a@cygnus.uwa.edu.au> Paul wrote: > > > Namespaces should be hierarchic. I think that now most of XML developers would agree. I wrote: > > Namespace URI's are hierarchical already, so all it would take is prefix matching. I briefly suggested this when > > namespaces first came out and again in more detail in a couple of posts last week. [...] > > p[starts-with(namespace-uri(),"http://www.w3.org/xhtml1/")] Paul wrote: > Maybe we have a different understanding of what is > hierachical ? Perhaps I just didn't make myself clear :-) > http://www.w3.org/TR/xhtml1/strict > > Do I understand right that version 2 would cause > > http://www.w3.org/TR/xhtml2/strict Well, I don't know what the XHTML folk are planning, but it doesn't really matter. If you just what XHTML regardless of version or strictness, you would just say starts-with(namespace-uri(),"http://www.w3.org/xhtml") In other words, with prefix matching, you don't need to match exactly at a directory separator "/". > By the way - XT is now using > > xmlns:xsl=http://www.w3.org/XSL/Transform/1.0 > > This is smart. ;-) I liked it too, but this may change in light of the current XHTML namespace debate. > In opposite , the article > ( http://www.jclark.com/xml/xmlns.htm ) > ( by the same author! ;-) shows us: > > xmlns:HTML="http://www.w3.org/TR/REC-html40 > > Isn't it *not* that smart? You can still do prefix matching if they consistently use http://www.w3.org/TR/REC-htmlXX > Would't it be better to have: > > xmlns:HTML="http://www.w3.org/HTML/4.0 > > instead ? Probably, in as much as it keeps them free from their TR URL scheme, but, as I note above, if one is just doing prefix matching, the "/" separator isn't necessary (although I agree with you that it is neater to have). > PS. Actualy there are still some more problems, but thinking > about more complex things would be easier after I'l understand > some simple things. As I noted in an earlier post, any (single) hierarchical representation of a set of features forces you to prioritize axes (ie pick one permutation). If XHTML used: http://www.w3.org/TR/xhtml1/strict http://www.w3.org/TR/xhtml1/transitional http://www.w3.org/TR/xhtml2/strict http://www.w3.org/TR/xhtml2/transitional You could specify for version and underspecify for strictness, but *not* the other way around. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net <pipe>Ceci n'est pas une pipe</pipe> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From zzyzlane at gte.net Mon Sep 6 04:33:37 1999 From: zzyzlane at gte.net (Christopher Lane) Date: Mon Jun 7 17:14:41 2004 Subject: XHTML Brouhaha and a ? Question ? Message-ID: <37D32965.D51FAADD@gte.net> About this comment: | From: David Megginson <david@megginson.com> Subject: How do you determine success? Sorry to be harsh, but I almost never see the required HTML 4.0 DOCTYPE declaration at the top of Web pages | Sorry, David, you haven't seen any of the documents that I've written for my company's intranet, because I've used the required 4.0 DOCTYPE declaration on all my documents for at least two years. Before that I used the 3.2 version. I've also used the 'transitional' version because we have so many people in the company who've never figured out how to upgrade their browser from NS 2.0 or 3.0. My company (IBM) is also very heavily involved in pushing XML into reality, and since the advent of the XHTML 1.0 proposal, I've started using that as my standard. Hey, David, the web pages have always turned out beautifully! For the same reason of backward compatibility, I've been using the 'transitional' statement in the DTD. I never write any document using frames but if I did, I suppose I might have to consult the 'frameset,' and if I were actually implementing browser readable XML, I would most certainly have to consult 'strict.' I don't see any great conflicts here. Am I missing some key points? From my position on the ground, i.e., someone who uses a plain text editor every day to write HTML documents for a corporate intranet, I mostly have to worry about whether people's browsers can properly, or approximately, represent my mind's-eye vision of what the document should look like once it's ready to put in production. OK, here's my question. In Saturday's newspaper (Seattle Times-Post Intelligencer) I found an article on the front page of the business section stating that the XML standard was "in trouble" and "will certainly be delayed" because, and I'm quoting from memory here, "European companies will never agree to the standard as written." I haven't seen any comment in this group about what may have caused such an outburst in the press. I wondered if anyone here had any insight into what this latest imbroglio may be all about. Thanks, Christopher Lane E-mail at home: zzyzlane@gte.net E-mail at work: clane2@us.ibm.com page: http://home1.gte.net/zzyzlane/index.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Mon Sep 6 04:56:28 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need In-Reply-To: <14290.56269.189604.432980@localhost.localdomain> References: <4.1.19990905155519.0409f3a0@mail.webgeek.com> <4.1.19990905155519.0409f3a0@mail.webgeek.com> Message-ID: <3.0.1.32.19990905165428.0187fd80@mail.accessone.com> I should like to point out, with all due respect, that there is no software anywhere written to date in the world that "knows" the meaning of anything. I don't think anthromorphization serves any useful purpose here. David, I think your example is a bit strained here. Recognition of a citation doesn't seem to me to be materially different from recognition of <toollist>. As in all human communication (which includes XML or HTML no matter it's bias towards easy computer recognition of content), I think there's an assumed common referent for things like pliars and citations and such. Any marked departure from such common referents reduces the ability to communicate imho. I don't think any markup language is, or has the potential to be, a universal language. It does offer the opportunity, within a community of interest, for people to agree on the meaning and structure of information that's relevant to that domain and for people who become interested in that domain to rapidly become fluent in the vocabulary of that domain. I don't think it's appropriate for any single organization to attempt to set definitions (i.e. specify namespaces) for particular domains of interest. I see that as an exercise best left to those who know whatever particular domain they are creating a tagset/namespaces for. Sincerely, Dave LeBlanc At 05:25 PM 9/5/99 -0400, David Megginson wrote: >Ann Navarro writes: > > [on Namespaces] > > > That need is: a formal deterministic means of discovery. > >Discovery of what? Structural rules are easy enough, but they buy you >almost nothing -- after all, if you give me an arbitrary piece of XML >with a DTD, my software can tell you whether it's valid or not, but >not what it means. > > [snip] > > > The "rest of the world", is looking for a means of discovering what > > belongs with that name, it's associated definitions, semantics, and > > other data that may be necessary to complete their operations. > >I cannot imagine how we could accomplish this, without simply mapping >to an artificially restricted set of a-priori meanings. > >For example, for displaying HTML in a browser all the meaning you need >is a collection of flow objects ("block text", "link", "graphic", >etc.), but what kind of schema language or other discovery mechanism >could allow software automatically to determine the meaning of > > <irony>Have a nice day!</irony> > >or > > <task> > <tools-required> > <tool>spanner</tool> > <tool>needle-nosed pliers</tool> > <tools-required> > <steps> > <step>loosen the main bolt with the spanner</step> > <step>pull out the blue wire with the needle-nosed pliers</step> > </step> > </task> > >? > >My point is that it's a pointless task, at least without access to >much more advanced artificial intelligence than is currently >available. > >In the mean time, though, it is entirely possible to write software >that *does* know what it's looking for, such as a search engine that >knows that HTML <cite> can hold a book title, or a Newsroom system >that knows that XMLNews <subject-name> holds a description of one of >the subjects of a News story. Namespaces are valuable precisely >because they allow software to find markup that it knows about and to >do something useful with it. > >While the Utopian vision of software that can figure out how to deal >with what it *doesn't* know about is enticing, we're so far away from >any practical implementation right now (except, again, for >artificially-restricted subsets) that standardizing would be a waste >of time. > >That's not to say that there's no point in standardizing some of those >tiny subsets by providing facilities for linking to structural schemas >and stylesheets, but it does mean that structural schemas and >stylesheets provide don't solve the problem of what markup means -- so >far, and for the forseeable future, that knowledge is hard-coded in >the software itself at some level. > > >All the best, > > >David > >-- >David Megginson david@megginson.com > http://www.megginson.com/ > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Mon Sep 6 04:56:24 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need In-Reply-To: <4.1.19990905155519.0409f3a0@mail.webgeek.com> Message-ID: <3.0.1.32.19990905164223.0187eec0@mail.accessone.com> I'm reminded of the C++ standardization process where C++ was to be like C only as necessary and no closer. My point is that too much specification leads to too a rigid and inflexible standard that people won't use which is about as useless as no standard at all. Is there a compelling reason to specify all the names and meanings of names and scope of names in namespaces? Who will be the ultimate determinator of namespaces? This is just going to lead to politicalization imho. Dave LeBlanc At 03:58 PM 9/5/99 -0400, Ann Navarro wrote: >Through several recent private conversations, it has become very clear to >me (and I believe to those others), that the XML community is facing a >significant unfilled need. One that if left unfilled as we move forward >with new and more complex activities, will result in even more difficulties >than we currently face. > >That need is: a formal deterministic means of discovery. > >The authors of the namespace recommendation firmly stand behind the >*intent* of the rec, in simply providing a name. > >The "rest of the world", is looking for a means of discovering what belongs >with that name, it's associated definitions, semantics, and other data that >may be necessary to complete their operations. > >In most ways, both groups are "right". > >Proposed continued work within the XML space at the W3C may address this in >part, but not, in my opinion, in full. > >Many of the arguments we face in namespaces come about due to the unspoken >argument that either a: they simply didn't go far enough, or b: additional >work is necessary to complement them. This assertion has never really come >to the forefront in our discussions on this topic. > >Until that time, these arguments over the appropriate choices in >namespaces, in XHTML or anywhere else, will only proliferate. > >Rather than trying to second guess what those mechanisms may be, I'd >personally prefer to simply not address the question of namespaces in XHTML >until we know more (meaning remain silent on the issue in the XHTML PR, or >purposefully defer within the spec): rather than being forced to make a >choice between 1 or 3. Though if I must choose, my choice is still with 3, >in that I find it easier to scale back granularity at a later date, than to >add it. > >Food for thought at all levels, not just for this one issue. > >Respectfully, > >Ann >--- > >Author of Effective Web Design: Master the Essentials >Coming in September --- Mastering XML > >Founder, WebGeek Communications http://www.webgeek.com >Vice President-Finance, HTML Writers Guild http://www.hwg.org >Director, HWG Online Education http://www.hwg.org/services/classes > > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Mon Sep 6 05:46:54 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:14:41 2004 Subject: XHTML Brouhaha and a ? Question ? References: <37D32965.D51FAADD@gte.net> Message-ID: <37D339B6.8CDAF955@allette.com.au> Christopher Lane wrote: > OK, here's my question. In Saturday's newspaper (Seattle Times-Post > Intelligencer) I found an article on the front page of the business > section stating that the XML standard was "in trouble" and "will > certainly be delayed" because, and I'm quoting from memory here, > "European companies will never agree to the standard as written." I > haven't seen any comment in this group about what may have caused such > an outburst in the press. I wondered if anyone here had any insight > into what this latest imbroglio may be all about. I would guess that it's all about lines of copy for a newspaper story. The secret is to find the credible stories amongst the drivel. Three easy points are: a) it's not a standard, it's a recommendation, b) it has already been released as version 1.0 and AFAIK there are no plans for version 2.0. c) by nature XML is internationalised, certainly much more than SGML ever was. I would be surprised if there were substantial issues that coincided strongly with political borders. Write it off as another poorly researched article. -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Sep 6 06:05:49 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:41 2004 Subject: XHTML Brouhaha and a ? Question ? Message-ID: <3.0.32.19990905210828.00b6a650@pop.intergate.bc.ca> At 07:39 PM 9/5/99 -0700, Christopher Lane wrote: >OK, here's my question. In Saturday's newspaper (Seattle Times-Post >Intelligencer) I found an article on the front page of the business >section stating that the XML standard was "in trouble" After a little work, I found the URL: http://www.seattle-pi.com/pi/national/net04.shtml It's about RosettaNet. -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 murata.makoto at fujixerox.co.jp Mon Sep 6 07:11:31 1999 From: murata.makoto at fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:14:41 2004 Subject: Fw: Fw: XHTML & Schemas Message-ID: <199909060515.AA01728@archlute.fujixerox.co.jp> Oren Ben-Kiki wrote: >Concretely, as long as the XSchema WG >keeps the "namespace == schema" rule, I don't see how you can decide to use >just one namespace for XHTML (much as I would like you to) - unless you are >betting they'll change this rule in the future. I am a member of the XML Schema WG. I believe that the XML Schema WG have no consensus. 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 david-b at pacbell.net Mon Sep 6 07:26:36 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need References: <4.1.19990905155519.0409f3a0@mail.webgeek.com> Message-ID: <37D35119.D05739D3@pacbell.net> Ann Navarro wrote: > > That need is: a formal deterministic means of discovery. Others called this an AI problem; I'll just ask why it'd be needed. Rather than looking at a thing and discovering some singular meaning from it, it's equally doable to look at that thing and recognize if it's something for which one or more meanings is known. Or to expect such a thing, and thus know how to handle it when it arrives. Those latter two approaches are tried and true ... and are also, in the big scheme of things, a lot safer. > The "rest of the world", is looking for a means of discovering what belongs > with that name, it's associated definitions, semantics, and other data that > may be necessary to complete their operations. I think that's unfair to the "rest of the world" -- of which I'm a member. I'm not looking for such a thing. I've worked with such systems in the past, can whip them up at need, and don't tend to use them very much. I certainly wouldn't want to see W3C get invested in any particular variant in that solution space. > Rather than trying to second guess what those mechanisms may be, I'd > personally prefer to simply not address the question of namespaces in XHTML > until we know more (meaning remain silent on the issue in the XHTML PR, or > purposefully defer within the spec): I hope this begins to reflect some kind of consensus -- "First, do no harm". The XHTML spec will be helpful without addressing the namespace issue -- a straight XML 1.0 application. Although I'd far prefer to see a single namespace defined for (X)HTML, it could wait for a while yet. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Sep 6 08:10:30 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:41 2004 Subject: XHTML Brouhaha and a ? Question ? References: <3.0.32.19990905210828.00b6a650@pop.intergate.bc.ca> Message-ID: <37D35B6A.AB22A42A@pacbell.net> Tim Bray wrote: > > At 07:39 PM 9/5/99 -0700, Christopher Lane wrote: > >OK, here's my question. In Saturday's newspaper (Seattle Times-Post > >Intelligencer) I found an article on the front page of the business > >section stating that the XML standard was "in trouble" > > After a little work, I found the URL: > > http://www.seattle-pi.com/pi/national/net04.shtml > > It's about RosettaNet. -Tim Interesting. At least one fact was wrong, making me believe that'd be true of some more. RosettaNet has been around for quite a bit longer than they said; perhaps they're confusing a website launch with the organization's birth a few years ago. That fact puts a very different spin on things -- namely, it is presented as if CTIA is objecting to something very new, not to something that's been in process for several years and which they had to have known about for some time. That whole big about privacy is bogus -- it's not like XML is the only technology by which ill-intentioned companies will exchange data about customers which don't want it done. Ditto the issue about needing a D&B number -- it's not like whatever European companies use in its place couldn't get added to the spec, if desired. Time before February, yep. Plenty of time. If resolving the issue were in fact a goal. I'm suspecting that the group that's objecting is just after negotiating power. Anyone who knows more about the CTIA, "based in Chicago", and its true intent (any particular corporate alliances?), please illuminate us! - 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 steven.livingstone at scotent.co.uk Mon Sep 6 10:38:45 1999 From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM) Date: Mon Jun 7 17:14:41 2004 Subject: XML-RPC interface for discussion groups Message-ID: <8DCB90532FF7D211B34400805FD48853644C4A@SENMAIL3> I have developed a first-cut COM component to implement an XMLRPC client for Automation aware products. I have created and modified discussions on the Discussion Group directly via Word - pretty cool. I also created a basic stand alone editor (still in what ever comes before Alpha development) which doesn't require Office and talks directlty to the DG via XMLRPC. Anybody wishing the COM dll or *basic* Word editor should mail me - I plan on doing more work on the editor when I get time. Cheers, Steven Steven Livingstone - http://www.deltabiz.com 07771 957 280 or +447771957280 Author - Professional Site Server 3, Wrox Press http://www.wrox.com/Store/Details.asp?Code=2696 Professional Site Server 3.0 Commerce Edition, Wrox Press http://www.wrox.com/Store/Details.asp?Code=2505 President, AIP Scotland. ceo@citix.com http://www.citix.com Join Association of Internet Professionals - http://www.citix.com/aip > -----Original Message----- > From: Dave Winer [SMTP:dave@userland.com] > Sent: 02 September 1999 18:28 > To: xml-dev@ic.ac.uk > Subject: XML-RPC interface for discussion groups > > This document describes the XML-RPC interface implemented by UserLand > discussion groups. > > http://www.xmlrpc.com/discuss/msgReader$181 > > With a compatible editor you can easily create and edit web pages with > workstation editors that are not browser based. It's a way, thru > scripting, > to work around limits in the browser as an editing environment, without > giving up the convenience of direct-connect thru HTTP. > > Support is in development, in the community, for Emacs, BBEdit, > AppleScript, > ShockWave and Windows COM-compatible editors such as MS-Word, and no doubt > others. We are also working with other discussion group software vendors > to > support this specification. > > For UserLand, this is the back-end for our editorial groupware system, and > a > new web writer's tool we have in development. But the interface can be > used > for all kinds of workflow and groupware. The more the merrier! > > Dave Winer > UserLand Software > > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shyutz at ms1.hinet.net Mon Sep 6 11:18:38 1999 From: shyutz at ms1.hinet.net (shyutz@ms1.hinet.net) Date: Mon Jun 7 17:14:41 2004 Subject: =?big5?B?Rnc6ILnvpKOwX6RqrmEhp9qkpKxypEYh?= Message-ID: <002b01bef849$683ecdc0$21cd4acb@flag.com.tw> ----- Original Message ----- ±H¥óªÌ: ·¨¨Ø¬Ã <gillyang@mail.flag.com.tw> ¦¬¥óªÌ: <Undisclosed-Recipient:;> ¶Ç°e¤é´Á: ¤¤µØ¥Á°ê88¦~9¤ë6¤é ¤U¤È 04:56 ¥D¦®: ¹ï¤£°_¤j®a!§Ú¤¤¬r¤F! > ½Ð¤j®a¤£­n¥´¶}¤@­Ó¥s°µ Pretty Park.exe ªºÀÉ®×,³o·|±N¦¹Àɮצ۰ÊÂà±Hµ¹§A³q°T ¿ý > ¤¤ªº©Ò¦³¦W³æ¡I > > ¨Ø¬Ã > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 6 12:03:39 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:41 2004 Subject: Crazy idea Message-ID: <02ba01bef84e$1041ae30$4602a8c0@capella.co.il> Mulling over the namespace/XSchema issue, I came up with the following notion. I wonder if it has ever been suggested, and what its chances are. A DTD/XSchema, as defined today, performs two tasks. One is to validate a document. The output of this is a single Boolean value. The other is to "complete" the document - that is, add defaults. The latter part seems like a transformation task to me, which raises the question: why not specify this as an XSLT stylesheet? Once you consider this, it becomes obvious that the first part can also be specified as a stylesheet, given that one introduces some way for a stylesheet to indicate an error in the input (say, <xsl:error>). Actually, that's a good idea by itself. I already simulate it in my stylesheets by emitting an obtrusive error boilerplate, but that's a kludge. Objections: - You need an XSLT processor instead of just an XSchema processor. Given that an XML system is likely to have an XSLT processor anyway, this might be viewed as removing a component instead of adding one. - Doing full XSLT processing is more expensive then "just" XSchema processing. Is it? The XSchema spec is already quite complex, what with schemas importing one another and so on. There's also the issue that if we'd be only using XSLT, then the effort that would have gone for writing XSchema processors would go instead for optimizing XSLT. - XSLT is be "too strong". After all, it is Turing complete. XSchemas are already stronger then DTDs, for a good reason, so this might be an advantage. Otherwise, it might be useful to define a subset of XSLT to use in "schema" stylesheets. - People would abuse it. That is, people would create "schema" sheets which would transform the document to something completely different then what you started with. There are several answers to this, ranging from "so what? anything good can be abused" to "define a strict subset of XSLT which can't be abused". My suggested compromise is to require that a "Schema" XSLT stylesheet should only emit "fixpoint" documents - that is, applying it a second time must be a no-op. This is trivially testable and satisfies most objections as to the difference between "validation/completion" and "transformation". - The XSchema WG would be out of job :-) Someone should consider what modifications, if any, are required for using XSLT in this capacity. We'd need <xsl:error> or something equivalent (a construct which is useful in general). There might be a need to pick a subset of XSLT. There may be other issues. The whole concept of using XSLT for validation would justify a separate spec. So the Schema WG would actually be quite busy formulating it. The benefits are obvious: - KISS. Just one spec, instead of two; just one implementation, instead of two. In fact, I'd consider this an overriding consideration. The burden of proof should be on the other side to justify the need for a separate spec :-) - Time to recommendation. The recommendation could be released very soon after the XSLT one. That should be much faster then the current expected time for XSchema to finalize (I think). This can be done since A lot of sticky issues in the XSchema spec are automatically resolved. How to reuse XSchema "modules"; specifying intelligent defaults; mixing namespaces within a document; etc. - Time to implementation. We get a strong, flexible, powerful schema mechanism with robust implementations, immediately. I don't doubt the ability of the XSchema WG to come up with a good recommendation, but how long would it take until we see it implemented properly? - Market acceptance. By tying schemas to XSLT, every time a company uses one, it automatically can make use of the other. This would increase the market penetration of both recommendations. The schema recommendation stands to make most of the advantage; given that XSLT processors would be available in browsers and servers as a matter of course, this would significantly lower the barrier for performing validation, as compared to obtaining a separate schema processor How about it? Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Sep 6 12:52:32 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:41 2004 Subject: HTML 4.0 and RosettaNet Story In-Reply-To: <37D32965.D51FAADD@gte.net> References: <37D32965.D51FAADD@gte.net> Message-ID: <14291.38881.247685.480098@localhost.localdomain> Christopher Lane writes: > Sorry to be harsh, but I almost never see the required HTML 4.0 > DOCTYPE declaration at the top of Web pages | > > Sorry, David, you haven't seen any of the documents that I've written > for my company's intranet, because I've used the required 4.0 DOCTYPE > declaration on all my documents for at least two years. Before that I > used the 3.2 version. I've also used the 'transitional' version because > we have so many people in the company who've never figured out how to > upgrade their browser from NS 2.0 or 3.0. Sure, lots of us have, but we're (a) specialists and (b) too small even to form a drop in the bucket. Personally, I've created a few thousand HTML 3.2 and 4.0 pages. > My company (IBM) is also very heavily involved in pushing XML into > reality, and since the advent of the XHTML 1.0 proposal, I've > started using that as my standard. OK, let's run a quick sanity check on IBM's top-level Web page (http://www.ibm.com/) as of 19990906T0635-0400: 1. It contains a DOCTYPE declaration for HTML 3.2, not HTML 4.0 (I wouldn't expect it to be using XHTML yet, since XHTML is not a REC, but IBM obviously hasn't bothered with HTML 4.0 at this corporate level). 2. The page fails a parse badly, because it contains elements and attributes not allowed by the HTML 3.2 DTD (including <spacer> and <nobr>). Granted, that's the corporate level, so I checked to see if the researchers did any better than the marketing people. In fact, they did (marginally), because at least alphaworks.ibm.com contains *no* DOCTYPE declaration rather than a misleading one. This isn't meant to diss IBM, but rather, to show that the state of conformance to HTML 3.2 and HTML 4.0 even among the best-behaved and best-intentioned players. When one player fails to conform to a standard, it's the player's fault; when most players fail to conform, it's the standard's fault. > OK, here's my question. In Saturday's newspaper (Seattle Times-Post > Intelligencer) I found an article on the front page of the business > section stating that the XML standard was "in trouble" and "will > certainly be delayed" because, and I'm quoting from memory here, > "European companies will never agree to the standard as written." > I haven't seen any comment in this group about what may have caused > such an outburst in the press. I wondered if anyone here had any > insight into what this latest imbroglio may be all about. Here's the story: http://www.seattle-pi.com/pi/national/net04.shtml It's not about XML, but about something "RosettaNet", which happens to use XML. Apparently, we in the XML community are supposed to be stunned and trembling that a major initiative like RosettaNet is in trouble, so I'm especially embarrassed to admit that I hadn't even heard of RosettaNet before I read the story. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Sep 6 12:59:13 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need In-Reply-To: <3.0.1.32.19990905165428.0187fd80@mail.accessone.com> References: <4.1.19990905155519.0409f3a0@mail.webgeek.com> <14290.56269.189604.432980@localhost.localdomain> <3.0.1.32.19990905165428.0187fd80@mail.accessone.com> Message-ID: <14291.40310.446757.934178@localhost.localdomain> David LeBlanc writes: > David, I think your example is a bit strained here. Recognition of > a citation doesn't seem to me to be materially different from > recognition of <toollist>. They're meant to show that there is an infinite variety of meanings available. I deliberately picked a couple of examples from outside HTML to show that meaning was more than structural rules (a <p> can contain a <cite>) or a tiny set of presentational rules (this is block text, this is a link). > As in all human communication (which includes XML or HTML no matter > it's bias towards easy computer recognition of content), I think > there's an assumed common referent for things like pliars and > citations and such. Any marked departure from such common referents > reduces the ability to communicate imho. Absolutely correct, but how can we capture those referents for automatic discovery? > I don't think any markup language is, or has the potential to be, a > universal language. It does offer the opportunity, within a > community of interest, for people to agree on the meaning and > structure of information that's relevant to that domain and for > people who become interested in that domain to rapidly become > fluent in the vocabulary of that domain. Yes, this is my original point. Any given group of users can agree on a severly restricted universe of meanings, but we're dealing with the problem of blind exchange, where the receiver does not necessariily belong to the same group as the sender: if I send you an arbitrary chunk of XML, how do you figure out what to do with it? My claim is that the problem is not solvable in the general case. > I don't think it's appropriate for any single organization to attempt to > set definitions (i.e. specify namespaces) for particular domains of > interest. I see that as an exercise best left to those who know whatever > particular domain they are creating a tagset/namespaces for. That was my point, more or less. 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 ann at webgeek.com Mon Sep 6 16:36:20 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need In-Reply-To: <37D35119.D05739D3@pacbell.net> References: <4.1.19990905155519.0409f3a0@mail.webgeek.com> Message-ID: <4.1.19990906103647.0409d430@mail.webgeek.com> At 10:28 PM 9/5/99 -0700, David Brownell wrote: >I hope this begins to reflect some kind of consensus -- "First, >do no harm". As always, this only reflects my personal thoughts and opinions, unless clearly and explicitly stated otherwise. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Mon Sep 6 16:31:45 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need In-Reply-To: <3.0.1.32.19990905165428.0187fd80@mail.accessone.com> References: <14290.56269.189604.432980@localhost.localdomain> <4.1.19990905155519.0409f3a0@mail.webgeek.com> <4.1.19990905155519.0409f3a0@mail.webgeek.com> Message-ID: <4.1.19990906102427.04097280@mail.webgeek.com> At 04:54 PM 9/5/99 -0700, David LeBlanc wrote: >I don't think it's appropriate for any single organization to attempt to >set definitions (i.e. specify namespaces) for particular domains of >interest. I see that as an exercise best left to those who know whatever >particular domain they are creating a tagset/namespaces for. And this doesn't suggest that. Leaving assertions of anthromorphization aside: In today's Web browser, there is built-in "knowledge" of what HTML elements are supposed to be and do. They have been programmed to recognize a <P> element as a new structural block, presented with a leading line space, text flush left, unless otherwise indicated in a style sheet or align attribute. Simple, primarily presentation information, but it's preprogrammed in how to deal with such elements. That it doesn't recognize and act upon the designed content model for P or UL or anything else, was a design decision of the *browser* programmer, one that could be questioned. Allowing for discovery, based on a schema, DTD, or whatever other defining mechanism is provided, lets tomorrow's Web browser have that same "knowledge" of a <foo> element, and any other knowledge deemed necessary or prudent by those who will be using said element. No one is suggesting we'll be creating Commander Data by doing this. Nor is it "will o' the wisp". I am not a software architect, I do not pretend to be one. Yet this is not an idea that is foreign to many who are, and even thought of as necessary by some of those. The "rest of the world", as it were, is trying to do this already. By all the misunderstandings that arise *outside of this forum* about the intent and usefulness of namespaces, it should be evident to everyone that there is a desire for such abilities, even if the more academic of us look down on it as ill-informed. It's certainly not something that should be laughed off the list. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Sep 6 17:09:18 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need In-Reply-To: <4.1.19990906102427.04097280@mail.webgeek.com> References: <14290.56269.189604.432980@localhost.localdomain> <4.1.19990905155519.0409f3a0@mail.webgeek.com> <3.0.1.32.19990905165428.0187fd80@mail.accessone.com> <4.1.19990906102427.04097280@mail.webgeek.com> Message-ID: <14291.55243.697468.921617@localhost.localdomain> Ann Navarro writes: > Allowing for discovery, based on a schema, DTD, or whatever other defining > mechanism is provided, lets tomorrow's Web browser have that same > "knowledge" of a <foo> element, and any other knowledge deemed necessary or > prudent by those who will be using said element. But what would it discover? Stylesheets can already tell you how <foo> should be rendered in a browser. What other kind of information could reasonably be discovered in the general case besides structural validation rules and possibly simple data-typing? Neither of those is going to tell my application much about <foo> if it doesn't know about <foo> already. > The "rest of the world", as it were, is trying to do this > already. By all the misunderstandings that arise *outside of this > forum* about the intent and usefulness of namespaces, it should be > evident to everyone that there is a desire for such abilities, even > if the more academic of us look down on it as ill-informed. I'm still confused about exactly what 'this' is. *What* is the rest of the world trying to do? I'm not asking for a software-architect's perspective, but just for a clear requirement. Perhaps an example would help. Here's an XML document (without Namespaces for now): <bllrp zata="-1"> <poiuk>112</poiuk> <pppzzz>g</pppzzz> <ttt>xxx<rte w="3"/></ttt> </bllrp> Now, imagine that my XML application has just received this piece of XML and knows nothing about the markup language used. What kind of information should it be able to discover automatically, so that it can process this document usefully? All the best, Daivd -- 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 brendan at w3s.ie Mon Sep 6 17:48:33 1999 From: brendan at w3s.ie (Brendan McKenna) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need In-Reply-To: Your message of "Mon, 06 Sep 1999 11:10:58 -0400." <14291.55243.697468.921617@localhost.localdomain> Message-ID: <199909061550.QAA27493@ns.w3s.ie> Hi, David Megginson wrote: : Perhaps an example would help. Here's an XML document (without : Namespaces for now): : : <bllrp zata="-1"> : <poiuk>112</poiuk> : <pppzzz>g</pppzzz> : <ttt>xxx<rte w="3"/></ttt> : </bllrp> : : Now, imagine that my XML application has just received this piece of : XML and knows nothing about the markup language used. What kind of : information should it be able to discover automatically, so that it : can process this document usefully? : I would say that that depended on the application. However, a 'general' XML browser -- in the sense that Netscape or IE are 'general' HTML browsers -- would need to be able to discover a means of validating the document -- whether it's one or more Schema's or DTD's is irrelevant -- and a stylesheet for displaying it, or take some 'appropriate' action (such as displaying the source in a 'raw' form) in the absence of one. Brendan -- Brendan McKenna Technical Director Phone: +353-(0)61-338177 x4143 W3 Services Ltd. Fax: +353-(0)61-338065 Innovation Centre Email: brendan@w3s.ie National Technological Park Limerick Ireland xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 6 17:51:55 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need Message-ID: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> At 10:28 PM 9/5/99 -0700, David Brownell wrote: >I hope this begins to reflect some kind of consensus -- "First, >do no harm". The XHTML spec will be helpful without addressing >the namespace issue -- a straight XML 1.0 application. Although >I'd far prefer to see a single namespace defined for (X)HTML, it >could wait for a while yet. No it can't! The damage is already starting to creep in - for example, look at IE5, which recognizes HTML tags using the hardwired prefix "html:" - something any moron can see is fragile and broken. But we can't reasonably get mad at Microsoft because the W3C just can't be bothered to define a name for HTML, something that would take about 15 minutes once they realized it was worth doing. Yes, I've raised this point repeatedly within the W3C - I don't know what the problem is. Maybe it's as Ann points out - since we haven't yet built a universal related-package-of-truth discovery mechanism for XML, they're going to punish us by denying us the limited (but real) benefits of a robust, reliable way to distinguish which tags are HTML and which aren't. Dammit, if the W3C obstinately refuses to give HTML a name for programmers to hang their hats on, I'm going to start a campaign right here in xml-dev for *us* to pick something, it'll be easier than designing SAX. -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 ricko at allette.com.au Mon Sep 6 18:52:12 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:41 2004 Subject: an unfilled need Message-ID: <004f01bef889$1f6763b0$5bf96d8c@NT.JELLIFFE.COM.AU> From: Arjun Ray <aray@q2.net> >On Sun, 5 Sep 1999, Ann Navarro wrote: > >> That need is: a formal deterministic means of discovery. > >That's an AI problem at root, and for now, a will-o'-the-wisp. I think people have misread Ann's comment. She is asking "for a means of discovering what belongs with that name, it's associated definitions, semantics, and other data that may be necessary to complete their operations." In other words, what declarations does this name appear in? What schema does this name participate in? This seems a reasonable thing to ask. 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 Patrice.Bonhomme at loria.fr Mon Sep 6 18:56:31 1999 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:14:42 2004 Subject: XML Database/Repository with content indexing ? Message-ID: <199909061659.SAA05197@chimay.loria.fr> <Hi/> I was wondering if it exists some XML database system that provide a content (full text) indexing mechanism. This system should be able to answer to this query : give me all documents that contains the expression "big blue" within their "/TEI.2/teiHeader/*/title" element(s). Thanks for all informations and pointers Pat -- ============================================================== bonhomme@loria.fr Tel : 03 83 59 30 52 / 06 11 34 03 85 http://www.loria.fr/~bonhomme Office : B.228 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Mon Sep 6 18:56:42 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:42 2004 Subject: Crazy idea References: <02ba01bef84e$1041ae30$4602a8c0@capella.co.il> Message-ID: <37D3EF98.BB075628@prescod.net> This "stylesheet as schema" idea comes around every so often but I think that it has one major flaw: stylesheets cannot drive syntax directed editors. > - XSLT is be "too strong". After all, it is Turing complete. > > XSchemas are already stronger then DTDs, for a good reason, so this might be > an advantage. Otherwise, it might be useful to define a subset of XSLT to > use in "schema" stylesheets. >From a mathematical point of view, I don't think that XSchemas are much stronger than DTDs. The set of tag-based languages they can describe are pretty much the same. The XSLT set of languages would be radically different. What's the XSLT equivalent for this content model: ((a*,(b|c)+,d)+|(d,(b|c)*,d?)+) On the other hand there are constraints that XSLT could support that schemas probably could not. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matthew at praxis.cz Mon Sep 6 19:04:04 1999 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:14:42 2004 Subject: an unfilled need References: <14290.56269.189604.432980@localhost.localdomain> <4.1.19990905155519.0409f3a0@mail.webgeek.com> <3.0.1.32.19990905165428.0187fd80@mail.accessone.com> <4.1.19990906102427.04097280@mail.webgeek.com> <14291.55243.697468.921617@localhost.localdomain> Message-ID: <37D3F46B.EAC60CBD@praxis.cz> > But what would it discover? Stylesheets can already tell you how > <foo> should be rendered in a browser. What other kind of information > could reasonably be discovered in the general case besides structural > validation rules and possibly simple data-typing? Neither of those is > going to tell my application much about <foo> if it doesn't know about > <foo> already. Wasn't this exactly the point of Jon Bosak's by-now-classic paper about XML and Java? Maybe this has been generally written off as shameless promotion of Sun's interests, but if so this seems like a shame to me, since the idea is absolutely brilliant. There should be a way to associate tags with Java classes (and preferably a generic mechanism that at least opens up the possibility of associating them with code of any kind). The class in question could be determined in a number of ways (stylesheet, schema, whatever) and would then consume the contents of the element, doing something useful. The nice thing about general-purpose programming languages is that this something could be absolutely anything. Matthew xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 at praxis.cz Mon Sep 6 19:16:16 1999 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:14:42 2004 Subject: an unfilled need References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> Message-ID: <37D3F74D.AA84B8FF@praxis.cz> > No it can't! The damage is already starting to creep in - for example, > look at IE5, which recognizes HTML tags using the hardwired prefix > "html:" - something any moron can see is fragile and broken. But we > can't reasonably get mad at Microsoft because the W3C just can't be bothered > to define a name for HTML, something that would take about 15 minutes > once they realized it was worth doing. Yes, I've raised this point > repeatedly within the W3C - I don't know what the problem is. On reading this I can't resist the temptation to raise once again the issue of W3C's confidentially rules, because this is a perfect example of the danger of this policy. On the one hand, after countless discussions on this topic with countless knowledgeable people of various backgrounds and viewpoints, I still can't for the life of me understand why this policy exists. The argument about information overload is convincing in the context of giving open access to voting on W3C recommendations and the like, but certainly doesn't preclude giving everyone access to the minutes of working group meetings and standards (sorry, recommendations) in progress. The argument that this will confuse people since the works in progress change so often is clearly bogus: in that case W3C members are spending good money (not to mention significant amounts of time) to be befuddled. The argument that members are paying money to be given advance access to this information is frightening and not obviously sensible. The competitors these companies might be concerned about are presumably all members as well. (The uncharitable view is that the primary motivation is to give members an elitist buzz every time they say: "Of course, I can't go into detail about this", but who could believe that?) There is, however, a very strong argument for changing this policy. Judging by recent discussion on this list, the W3C is losing some of its implicit authority in the XML community. No one objected to the W3C controlling XML at the onset because it was far from a foregone conclusion that XML was win over a number of plausible (but in retrospect clearly inferior) approaches. Now XML is mainstream and this no longer flies. Lack of complete buyin (not to mention open hostility) from XML developers is certainly not in the W3C's interest, and only opens the way for Microsoft and other major players to step in with their own proprietary (and inevitably less well thought out) approaches. I must be missing something. Can someone please set me straight? Matthew xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From czinkos at mail.matav.hu Mon Sep 6 19:18:28 1999 From: czinkos at mail.matav.hu (Zsolt Czinkos) Date: Mon Jun 7 17:14:42 2004 Subject: XML Database/Repository with content indexing ? References: <199909061659.SAA05197@chimay.loria.fr> Message-ID: <37D3F895.5BBF25D2@mail.matav.hu> Patrice Bonhomme wrote: > > <Hi/> > > I was wondering if it exists some XML database system that provide a content > (full text) indexing mechanism. This system should be able to answer to this > query : give me all documents that contains the expression "big blue" within > their "/TEI.2/teiHeader/*/title" element(s). > > Thanks for all informations and pointers I've read that Oracle8i can do it. See http://www.oracle.com . Best, Zsolt Czinkos xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 6 19:21:39 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:14:42 2004 Subject: an unfilled need In-Reply-To: <37D3F46B.EAC60CBD@praxis.cz> Message-ID: <Pine.GHP.4.02A.9909061813260.29801-100000@mail.ilrt.bris.ac.uk> On Mon, 6 Sep 1999, Matthew Gertner wrote: > > But what would it discover? Stylesheets can already tell you how > > <foo> should be rendered in a browser. What other kind of information > > could reasonably be discovered in the general case besides structural > > validation rules and possibly simple data-typing? Neither of those is > > going to tell my application much about <foo> if it doesn't know about > > <foo> already. > > Wasn't this exactly the point of Jon Bosak's by-now-classic paper about XML and Java? Maybe > this has been generally written off as shameless promotion of Sun's interests, but if so this > seems like a shame to me, since the idea is absolutely brilliant. There should be a way to > associate tags with Java classes (and preferably a generic mechanism that at least opens up > the possibility of associating them with code of any kind). The class in question could be > determined in a number of ways (stylesheet, schema, whatever) and would then consume the > contents of the element, doing something useful. The nice thing about general-purpose > programming languages is that this something could be absolutely anything. While having a mechanism for relating classes (eg. java:com.goodwebguide.rating) with Web namespaces (eg. http://rating.goodwebguide.com/ns1/) would doubtless be handy, this just punts the hard problem into a different arena. Instead of software agents puzzling over what arbitrary XML data structures might be telling us, or useful for, they'll be puzzling over what arbitrary Java bean components can do for us. Mapping into beans is interesting (eg. we for example get the notion of get/set'able bean properties), but without taxonomies of java class behaviours, we're just as lost when dealing with an unknown java classes as with unknown XML data structures... I don't see any principled difference between these two problem scenarios: in both case you've got some previously unencountered Web resource (a URI-nameable thingy) and you want to know what it's useful for. Dan -- Daniel.Brickley@bristol.ac.uk Institute for Learning and Research Technology http://www.ilrt.bris.ac.uk/ University of Bristol, Bristol BS8 1TN, UK. phone:+44(0)117-9287096 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon Sep 6 19:26:10 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:42 2004 Subject: Crazy idea Message-ID: <009801bef88d$c9320bd0$5bf96d8c@NT.JELLIFFE.COM.AU> From: Oren Ben-Kiki <oren@capella.co.il> >A DTD/XSchema, as defined today, performs two tasks. One is to validate a >document. The output of this is a single Boolean value. The other is to >"complete" the document - that is, add defaults. > >The latter part seems like a transformation task to me, which raises the >question: why not specify this as an XSLT stylesheet? Once you consider >this, it becomes obvious that the first part can also be specified as a >stylesheet, given that one introduces some way for a stylesheet to indicate >an error in the input (say, <xsl:error>). Actually, that's a good idea by >itself. I already simulate it in my stylesheets by emitting an obtrusive >error boilerplate, but that's a kludge. >How about it? I have a note on "Using XSL as a Validation Language" at http://www.ascc.net/xml/en/utf-8/XSLvalidation.html also published in July Interchange magazine (ISUG). The implications of XPath are sketched out in the note "Axis Models and Path Models" at http://www.ascc.net/xml/en/utf-8/validaxis.html Francis Norton has a subsequent article "Generating XSL for Schema Validation" at http://www.redrice.com/ci/generatingXslValidators.html which gives an XSL stylesheet for generating an XSL validator from a DCD schema. (Francis has worked further on this line, and may update that article and the software sometime, I believe.) I think it is worthwhile to raise the possibility that validation is not really a binary function, though it is convenient to speak of it as such for rhetorical purposes. In fact, a validator that merely says "valid" or "invalid" is almost useless (not quite: it is still useful for giving structural preconditons that a progammer can use to reduce the number of cases their program has to deal with) and certainly unacceptable for users: it is the diagnostic information which is the useful thing. Rather than considering the diagnostics as nice side-effects that a validator may do, by using XSL we can make the diagnostic information the centre of attention for validation. This has a big impact on schemas: rather than the schema being a passive description, it should become a far more user-friendly and active thing: for example, a schema language might require that repeated groups of elements in content models should be given a name, which diagnostic messages can give to the user to help them. Or the schema could include declarations for error-recover from validity errors: if a certain element is found out of context, then repair it or sanitize it. I don't see why a schema should not include such things. For anyone interested, there are also other articles on various alternatives to DTDs and content models at http://www.ascc.net/xml/en/utf-8/schemas.html If anyone is going to the APWeb99 conference in Hong Kong later this month, I am giving a paper on this subject. Anyone in Taiwan can contact Academia Sinica Computing Centre; we are giving XML workshops that include the topic "Using XSL for Validation". 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 whisper at accessone.com Mon Sep 6 19:31:01 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:14:42 2004 Subject: HTML namespace (was: an unfilled need) In-Reply-To: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> Message-ID: <3.0.1.32.19990906103953.026b29d0@mail.accessone.com> At 08:54 AM 9/6/99 -0700, Tim Bray wrote: >Dammit, if the W3C obstinately refuses to give HTML a name for >programmers to hang their hats on, I'm going to start a campaign right >here in xml-dev for *us* to pick something, it'll be easier than >designing SAX. -Tim > Hmm.. how about something after C++: Any tag which does not have a namespace prefix or is not recognizably within a namespace is implicitly HTML. Any tag which is not prefixed or not contained within a namespace and is not defined by the version of HTML in use is an error. When I first wrote this I thought it didn't answer the problem posed by Tim, but then I realized that it does: if you don't have a doc header, you don't have an HTML document thus you don't have tags which are prefixed or within a namespace and thus the whole document is an error. This, of course, is going to fly merrily down the runway and smack into a wall consisting of all those pages out there that either don't use a doc header or don't use it correctly (as was pointed out by a nearby post about IBM's usage). Excuse me if I really did miss your point Tim. Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 6 19:54:58 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:42 2004 Subject: Crazy idea Message-ID: <00a701bef891$c7745970$5bf96d8c@NT.JELLIFFE.COM.AU> From: Paul Prescod <paul@prescod.net> >This "stylesheet as schema" idea comes around every so often but I think >that it has one major flaw: stylesheets cannot drive syntax directed >editors. Yes, but the idea is not "stylesheet as schema" but "validator implemented by stylesheet transformation language". As Francis Norton's tool (see previous email) shows, DCD (which is pretty suitable for a syntax-directed editor) validation can be implemented using XSLT. Also, why should a syntax-directed editor work outside-in (i.e., using content models). That the currently do so is because they use grammars where the children are keyed by the parent, but that is not the only way in which a grammar can be specified. I do not see why a syntax-directed editor could not key off path expressions instead of the curent element type. That is surely how global exclusions and inclusion exceptions in SGML work: you can or cannot insert this element type because some ancestor's (extended) content model has allowed or banned it. >From a mathematical point of view, I don't think that XSchemas are much >stronger than DTDs. The set of tag-based languages they can describe are Here here. >pretty much the same. The XSLT set of languages would be radically >different. What's the XSLT equivalent for this content model: > >((a*,(b|c)+,d)+|(d,(b|c)*,d?)+) It would be a lot of typing in XSLT, but it cannot see why it could not be done. It can be a transformed from a schema anyway. Another possibility is also that a validator need not perform all possible validations to be still useful. I have a note "Weaker Validation" at http://www.ascc.net/xml/en/utf-8/weakvalid.html on this. In particular, for documents in development is it useful to have a weaker validation. >On the other hand there are constraints that XSLT could support that >schemas probably could not. I think abbreviated RDF and XML namespaces should be test cases for XML schemas: if they can handle those, then we have a clear advance. 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 Sep 6 20:05:55 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:42 2004 Subject: an unfilled need In-Reply-To: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> Message-ID: <14291.64673.475435.922488@localhost.localdomain> Tim Bray writes: > Dammit, if the W3C obstinately refuses to give HTML a name for > programmers to hang their hats on, I'm going to start a campaign > right here in xml-dev for *us* to pick something, it'll be easier > than designing SAX. -Tim If MS and Netscape/Mozilla both buy into the same Namespace URI, then it won't much matter what the W3C says, but I'd still like to hope that the XHTML WG will give us a URI -- even just a NOTE with the line The XML Namespace URI for HTML is "http://www.w3.org/Markup/". would help prevent the nightmarish interoperability problems that are coming up. If we had this, I'd be willing to wait a while for XHTML proper. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Sep 6 20:16:27 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:42 2004 Subject: an unfilled need Message-ID: <3.0.32.19990906111905.00abd6c0@pop.intergate.bc.ca> At 01:54 PM 9/6/99 -0400, David Megginson wrote: >If MS and Netscape/Mozilla both buy into the same Namespace URI, then >it won't much matter what the W3C says, but I'd still like to hope >that the XHTML WG will give us a URI -- even just a NOTE with the line > > The XML Namespace URI for HTML is "http://www.w3.org/Markup/". > >would help Hmm, I observe that the namespace name hardwired to the prefix "xml:" is http://www.w3.org/XML/1998/namespace (amusing, since the namespace spec is dated January 1999). Anyhow, I seem to recall that Dan Connolly cooked this up on behalf of the W3C and there was a real good reason which I unfortunately forget for having a date in there. So by analogy, a candidate namespace name for HTML would be http://www.w3.org/HTML/1999/namespace And yes, a one-line NOTE on www.w3.org/TR would do the job. Hey there, HTML WG, any chance? If you pick a URI, we all promise not to complain about what it is. Right, 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 6 20:24:32 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:42 2004 Subject: W3C (was Re: an unfilled need) Message-ID: <00b801bef895$e9456f90$5bf96d8c@NT.JELLIFFE.COM.AU> From: Tim Bray <tbray@textuality.com> >Yes, I've raised this point >repeatedly within the W3C - I don't know what the problem is. I think there is missing stage in procedures at W3C. Some people want standards to allow plurality, others want standards to prevent useless duplication. The "we don't need XSL" kafuffle recently shows this. XML has attracted both peoples because its extensibility allows plurality but it has a fixed delimiter set which attracts the stern antiduplicationists. The antiduplicationist see schemas like this: we will make a universal schema language and then we can get rid of DTDs. But the WWW was built on allowing plurality. So the missing stage in procedures in the W3C is this: for every new XML technology proposed, there should be a mechanism first developed to allow alternatives. The stylesheet PI is an exemplar for this. In the case of schemas, before XML schemas are developed, we should have a mechanism for invoking them, otherwise what else is there but namespaces? I agree with Tim 100% here. Even if just as an interim, the W3C should introduce a schema declaration PI, which binds the document (or an element type) to a schema URL. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Sep 6 21:07:49 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:42 2004 Subject: an unfilled need References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> Message-ID: <37D41196.3DFAFFB6@pacbell.net> Tim Bray wrote: > > At 10:28 PM 9/5/99 -0700, David Brownell wrote: > >I hope this begins to reflect some kind of consensus -- "First, > >do no harm". The XHTML spec will be helpful without addressing > >the namespace issue -- a straight XML 1.0 application. Although > >I'd far prefer to see a single namespace defined for (X)HTML, it > >could wait for a while yet. > > No it can't! The damage is already starting to creep in - for example, > look at IE5, which recognizes HTML tags using the hardwired prefix > "html:" OK, I confess to overstating my real point: that the two issues could in fact be separated: * An DTD for XHTML is a useful thing in its own right, usable immediately in conjunction with other parts of the current XHTML draft. * The namespace structure of XHTML is separable, and in fact doesn't need a DTD (or schema) in order to be useful. (With a good DTD structure it just costs an <!ATTLIST...>!) It's clearly my preference to see one namespace. And I'll agree that the issue can't remain unresolved for too much longer, since people have needed this answer for longer than they've needed an official XHTML DTD. (How many unofficial DTDs have folk seen or used? Let me count the ways ... ;-) But since they're separable, it still seems reasonable to me that the XHTML PR train continue on its mad rush to REC status -- but that the namespace issue could be untied from the railroad tracks and led aside, first. > Dammit, if the W3C obstinately refuses to give HTML a name for > programmers to hang their hats on, I'm going to start a campaign right > here in xml-dev for *us* to pick something, it'll be easier than > designing SAX. -Tim I've thought the very thing. Not about committee design of a URL (pick a reasonable one and go with it), but about xml-dev acting as the nucleus around which a better solution can form. > http://www.w3.org/HTML/1999/namespace Sure, I'd vote for it. Now we need DTDs using this. Does anyone want to get one that's done right -- using conditional sections to disable transitional or frameset rules appropriately, rather than having three separate DTDs? :-) - 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 lauren at sqwest.bc.ca Mon Sep 6 21:27:17 1999 From: lauren at sqwest.bc.ca (Lauren Wood) Date: Mon Jun 7 17:14:42 2004 Subject: confidentiality in W3C WGs In-Reply-To: <37D3F74D.AA84B8FF@praxis.cz> Message-ID: <199909061929.PAA19983@gw.sqwest.bc.ca> The only really good reason I see for the confidentiality agreement that exists in several W3C Working Groups has marketing, public relations, and politics at its base. Imagine a lively WG discussion, in which two large member companies (let's call them A and B) disagree. The rest of the WG agrees with A and that's what goes into the spec. Maybe B gives in graciously, maybe B gives in less than graciously, maybe B doesn't give in at all. Then imagine the minutes are all public, and everyone can tell everyone else exactly what happened. The upshot is that some journalist, or maybe a public relations person in company A, starts making a big thing out of how company A "won" over company B in this issue. Next thing you know, company B starts fighting back in public, or refuses to give in graciously on any issue, or doesn't contribute properly to the discussions, or leaves the WG. Could this happen? Yes. I've had journalists call me to talk about specs such as the DOM or XML, and when I've said that there are discussions and sometimes companies disagree, I've had questions such as "tell me when company A won and company B lost" (no prizes for guessing which companies they were most concerned with). I've seen articles written about other standards committees (not in W3C) where the journalist has tried to make out there is a fight in every small disagreement, and to get quotes from any participant and twist them to make it look like a fight. Makes for better press, I guess. Not so great if you're on the WG involved, trying to get some consensus on sticky technical issues. That can be hard enough without press articles and PR problems getting in the way. So sometimes you need confidentiality, to build trust and a knowledge that what is said in a WG remains within that WG, so that people can concentrate on the technical work, and not on the politics. 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 david-b at pacbell.net Mon Sep 6 21:26:23 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:42 2004 Subject: an unfilled need References: <14290.56269.189604.432980@localhost.localdomain> <4.1.19990905155519.0409f3a0@mail.webgeek.com> <4.1.19990905155519.0409f3a0@mail.webgeek.com> <4.1.19990906102427.04097280@mail.webgeek.com> Message-ID: <37D415F0.1E628C73@pacbell.net> Ann Navarro wrote: > > Allowing for discovery, based on a schema, DTD, or whatever other defining > mechanism is provided, lets tomorrow's Web browser have that same > "knowledge" of a <foo> element, and any other knowledge deemed necessary or > prudent by those who will be using said element. > > I am not a software architect, I do not pretend to be one. Yet this is not > an idea that is foreign to many who are, and even thought of as necessary > by some of those. Those of us who _are_ software architects work with the issues of extensible systems all the time. At some level it always boils down to moving new code to someplace that can safely execute it, which has been done since the first set of patch cords leaped out of the primordial sea of circuitry onto a wall of clicking relays. Given that it's been getting done sucessfully for so long, and without addressing the "need" that started this thread, I still fail to see why the W3C should try to involve itself in such work. Whatever the W3C would try to dictate in this space, a better solution will come along within the year. And I suspect neither would get that much more use than the systems people use today. Plugins? Applets? Active-security-hole? Yoiks. - 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 oren at capella.co.il Mon Sep 6 22:38:14 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:42 2004 Subject: Crazy idea References: <02ba01bef84e$1041ae30$4602a8c0@capella.co.il> <37D3EF98.BB075628@prescod.net> Message-ID: <034801bef8a6$b2e90db0$4602a8c0@capella.co.il> Paul Prescod <paul@prescod.net> wrote: > This "stylesheet as schema" idea comes around every so often but I think > that it has one major flaw: stylesheets cannot drive syntax directed > editors. Validation is one thing, and assisted construction is another. Related issues, to be sure, but there is a lot of functionality you'd expect in "assisted document construction" which simply does not belong in validation. It is not at all clear to me that a specification for validation should consider these issues. That said... Stylesheets _can_ be used to assist construction, as in "transform an empty node matching the following criteria into ...". The compromise I suggested - that a "schema" stylesheet must be a no-op if applied twice - immediatly suggests that such stylesheets would be very useful in assisted construction. Just run the partial document through them, flag errors, and repeat until all errors are gone and the user is happy. > From a mathematical point of view, I don't think that XSchemas are much > stronger than DTDs. The set of tag-based languages they can describe are > pretty much the same. The mathematical point of view is all well and good, but in practice XSchemas meant to replace DTDs since they can do useful things DTD can't, period. If we accept XSLT, we'll know for certain that whatever we throw at it, it will be able to handle. With an XSchema type specification, there's allways the worry that some case has not been covered, and we'd need XSchema2.0 to make up for the lack. > The XSLT set of languages would be radically > different. What's the XSLT equivalent for this content model: > > ((a*,(b|c)+,d)+|(d,(b|c)*,d?)+) This can be done in XSLT by converting the regexp into a series of 'choose' statements. Admittedly, in this particular case, the result wouldn't be pretty. If it turns out that this sort of constraints is common, we might consider adding some extra ability into XSLT to make expressing them more convenient. > On the other hand there are constraints that XSLT could support that > schemas probably could not. And things which are trivial to express in XSLT which probably would be a pain to express in a schema language (e.g., if the element has an 'a' attribute with value 'v', it should not contain an 'e' sub-element). I have no idea what the overall effect on real-world schemas would be. It might be interesting to take some real world DTDs/XSchemas and convert them to XSLT, as a test. Note that whoever does that gains the benefit of an executable validation specification stronger then a DTD which runs today on his XML system of choice. Which brings up an interesting point: people who are interested in effective validation can use the XSLT way today. It might be that some people have already done so. Assume that it is a good way - that is, people get what they need from it. Further assume that XSchema recommendation will take a long time to finalize, and longer for implementations to become common, while XSLT implementations are much more widespread. The expected result would be that nobody would care about the XSchema recommendation in practice, regardless of the W3C. The only problem is that the W3C will, in the mean while, twist other recommendations to be compatible with XSchemas. For example, specifying three name spaces for XHTML - which brings us a full circle back to where we started a week ago :-) Have fun, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Sep 6 22:38:37 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:42 2004 Subject: an unfilled need In-Reply-To: <199909061550.QAA27493@ns.w3s.ie> References: <14291.55243.697468.921617@localhost.localdomain> <199909061550.QAA27493@ns.w3s.ie> Message-ID: <14292.9627.156385.196996@localhost.localdomain> Brendan McKenna writes: > I would say that that depended on the application. However, a > 'general' XML browser -- in the sense that Netscape or IE are > 'general' HTML browsers -- would need to be able to discover a > means of validating the document -- whether it's one or more > Schema's or DTD's is irrelevant -- and a stylesheet for displaying > it, or take some 'appropriate' action (such as displaying the > source in a 'raw' form) in the absence of one. Well, if that's all we need, we've got it already. Linking to a stylesheet is already standardized in a W3C Recommendation: http://www.w3.org/TR/xml-stylesheet/ The XML 1.0 DOCTYPE declaration provides a crude, per-document schema link, and once we have other kinds of schemas, we'll probably have a mechanism for linking to those as well. If that's all people want when they talk about "automatic discovery", then we have an easy road ahead, but it really buys very, very little. As Brendan rightly points out, meaning is not only document- but application-specific. 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 cbullard at hiwaay.net Mon Sep 6 22:41:54 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:42 2004 Subject: an unfilled need References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> <37D3F74D.AA84B8FF@praxis.cz> Message-ID: <37D4247B.4FD2@hiwaay.net> Matthew Gertner wrote: > > No one objected to the W3C controlling XML at the onset because it was far from a > foregone conclusion that XML was win over a number of plausible (but in retrospect clearly > inferior) approaches. Yes some did. The XML effort hijacked an international standard by subsetting it and putting the W3C trademark on it. The confidentiality rules of the W3C and the singleton control of its policy ensured that this standard would be modified and shaped by and for the goals of the members of a consortium. Some objected strenuously. As the twig is bent... By the way, nice article, Jon. It says what namespaces are and aren't. Otherwise, it ducks all of the issues the list is trying to address without any leadership. Yes, tie XML to Java. If that gets applications out the door and checks coming back, by all means, do that. Now, the rest of you should decide what you want to use namespaces for and just do it. You don't need permission and if you wait for it, you only fall behind in development. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Mon Sep 6 22:42:07 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:42 2004 Subject: confidentiality in W3C WGs References: <199909061929.PAA19983@gw.sqwest.bc.ca> Message-ID: <37D426E3.6EAA@hiwaay.net> Lauren Wood wrote: > > So sometimes you need confidentiality, to build trust and a > knowledge that what is said in a WG remains within that WG, so > that people can concentrate on the technical work, and not on the > politics. All true, Lauren. Yet it does not relieve the working groups of the responsibility for documenting issues and resolutions with regard to the contents of the work. Such procedures have been established and have worked in standards organizations for years. It is time for the W3C to develop and use these procedures. The results of not doing so are plain to all. It is the responsibility of those who undertook XML to do what is needed. That is the leadership, price and payment. Tim Berners-Lee must begin to restructure the leadership roles and responsiblities of the W3C to reflect the growing community. It is time for a touch of Washingtonian sagacity about the nature, use and preservation of power. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken_north at compuserve.com Mon Sep 6 23:08:02 1999 From: ken_north at compuserve.com (Ken North) Date: Mon Jun 7 17:14:42 2004 Subject: XML Database/Repository with content indexing ? References: <199909061659.SAA05197@chimay.loria.fr> Message-ID: <001701bef8ac$563f3980$0b00a8c0@grissom> Patrice Bonhomme wrote: > I was wondering if it exists some XML database system that provide a content > (full text) indexing mechanism. Yes. Oracle 8i interMedia and IBM DB2 UDB (w/ XML Extender) manage XML-enabled databases: - various indexing schemes to provide stemming, linguistic searches, and so on - section searches of XML docs - SQL queries over XML data using criteria such as CONTAINS 'impressionist' or ABOUT 'impressionist'. Also query over rich types such as images and audio. =================================================== Don't miss XML One Europe, London, October 6-8, 1999 XML, Java, and Database Magic (Oct. 7) http://www.xmlconference.com/xmleuro xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From xml at searchtools.com Mon Sep 6 23:15:03 1999 From: xml at searchtools.com (Avi Rappoport) Date: Mon Jun 7 17:14:42 2004 Subject: XML Database/Repository with content indexing ? In-Reply-To: <199909061659.SAA05197@chimay.loria.fr> References: <199909061659.SAA05197@chimay.loria.fr> Message-ID: <v04220504b3f9dcd32bad@[171.66.196.146]> At 6:59 PM +0200 9/6/1999, Patrice Bonhomme wrote: ><Hi/> > >I was wondering if it exists some XML database system that provide a content >(full text) indexing mechanism. This system should be able to answer to this >query : give me all documents that contains the expression "big blue" within >their "/TEI.2/teiHeader/*/title" element(s). Check out SIM (Structured Information Manager) at <http://www.mds.rmit.edu.au/sim_2.1/welcome.html>, sgrep at <http://www.cs.helsinki.fi/~jjaakkol/sgrep.html>, BUS (Bottom Up Search) at <http://savage.comeng.chungnam.ac.kr/~sgml/>, Cheshire at <http://cheshire.lib.berkeley.edu/> and the XQL proposal at <http://www.w3.org/TandS/QL/QL98/pp/xql.html>. Best of luck, Avi _______________________________________________________ Guide to Local Site, Intranet, and Portal 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 donpark at docuverse.com Mon Sep 6 23:59:03 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:42 2004 Subject: Namespace for HTML (Signup Here) In-Reply-To: <3.0.32.19990906111905.00abd6c0@pop.intergate.bc.ca> Message-ID: <000401bef8b3$86d9aec0$6645fea9@w21tp> Both Tim Bray and David Megginson proposed we settle on the Namespace URI for HTML. I think this is a clear enough and small enough task for us (XML-DEV) to accomplish here and now. Here are some candidates: 1) "http://www.w3.org/Markup/" - by David Megginson 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :) Lets just settle on one and start using it. If W3C balks, we can go with: 4) "http://www.xml.org/HTML/2000/Namespace" - (if Jon Bosak agrees) Signup by replying with one of the numbered options. If you are against this proposal, select this: 0) "hell://no.stinking.namespace/4/HTML" Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Tue Sep 7 00:08:37 1999 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:14:42 2004 Subject: Associated Press/ZDNet Blunder References: <10443A04FBE2D21182800008C7335C067784@poha.com> Message-ID: <37D440BD.16D6830F@finetuning.com> Hello everyone: I decided to try to get to the bottom of this quickly, before anyone wasted any more energy on it. I'm cross-posting it to the dev list FYI only (and, in all honesty, because i am a little curious if there are any exceptions with regard to any of the technical assumptions that I make below in number 6.) I still wonder why the associated press even bothered with it? It must have been a SLOW day...for them AND ZDNET. And, unfortunately, for a couple Seattle papers and at one or two in northern California (the only others i have heard about or seen first hand) over the last few days. Ultimately, the Associated Press is who i blame for this product of bumbling yellow journalism -- whoever wrote this "staff" release couldn't have even gone to even one of the web site's of any of the organizations involved for a second, and instead chose to take a chance at misrepresenting a situation that basically amounts to a non-issue in every way except politically -- Representing a slanted press release as if the information it provided was some kind of setback to XML standards is absolutely appalling. If anyone knows jesse's email, please forward it to him. ZDNet doesn't provide email links to any of the editors or writers on the site, and really, under the circumstances, i figured they probably aren't too concerned with making corrections anyway :-) So first, here's the link to AP's embarrasing prose http://www.freep.com/tech/qbnews4.htm I will now provide a brief list of facts that should wrap this all up in a jiffy. (okay maybe it's not so brief, but it's at least it will be researched and referenced accordingly -- hey! what a concept -- maybe i'll run it by AP :-) -- lisa 1. After researching this so-called "story" released by ZDNET, AP, and various local newspapers that obviously picked it up the AP wire, paraphrased it, without checking out any of the facts, and without contacting anyone to verify the story. I was able to find out everything in this email in a little more than twenty minutes. (I merely read every single document on the CompTIA website) -- then glanced over at RosettaNet, which was a no-brainer, because there is nothing specific on the either site about any "rejection" (only a press release from a month ago on the comptia site explaining that they have submitted "comments" to RosettaNet.) 2. CompTIA has only "submitted its comments" on RosettaNet's PIPs -- it hasn't "rejected" anything -- and this has NOTHING to do with the XML standard itself, nor will it affect any of the XML standards work in progress at the W3C, nor is there any vital XML standard in the works that is now going to held up, due to the submission of these comments. here's a quote right from CompTIA: > "Over the last five years we've gained significant expertise in developing and implementing process, technology and data standards > within the IT supply chain," said Reiner Schaaf, director of electronic commerce for Computer 2000 and chair of the CompTIA Europe > EC standards board. "As an organization, we need to support RosettaNet in its global initiative through our extensive and detailed > feedback on their specifications." 3. Additionally, there doesn't appear to be any sort of specification that was expected to be released next February of next year or anything that will now be held up. The statement amounts to little more than unsubstantiated heresay, at best. (Sheesh, at this rate, maybe AP is so confused it is referring to the core XML 1.0 W3C Recommendation standard that already came out TWO februaries ago :-) 4. http://www.comptia.org Background on the organization that has "rejected the XML standard": CompTIA - The Computing Technology Industry Association (CompTIA) is a not-for-profit organization that makes money selling certification training. Apparently, due to their "other" declared goals of improving ethics in the computer industry and being a largely POLITICAL force, in theory, for the whole IT industry they are able to remain not-for-profit. <opionion>Bottom line: This group lobbies congress to either get legislation passed or stop legislation it doesn't like from being passed, in the name of non-government interference and free enterprise, and stuff like that :-) Whether a particular proposed legislation is "good" or "bad" seems to hinge on whether its passing will cost money or generate money for the IT departments of the (mostly) very large corporations in the software/computer industry which make up its members. Just FYI: Here's their latest "battle" for instance -- trying to work it so IT companies can receive tax credits for the cost of training their employees they would have to train anyway. Nice angle, essentially free money for the IT companies -- even though IT training is something that all companies will have to be paying for... http://www.techcoalition.org </opinion> 5. <opinion>This week's media coverage was the result of the calculated measures of CompTIA, who apparently views XML's early and widespread implementation as a bit of a threat. CompTIA makes its money certifying IT people in many currently-implemented, largely proprietary, networking technologies (corba, COM, probably SAP, PeopleSoft). Not only are most of these technologies now integrating XML into their current framework -- any kind of generalized certification program is immediately going to leave its pupils instantly behind the times if they don't ALSO have some XML experience. In fact, it is already arguable that such experience could be deemed MORE important than the previously aforementioned technologies (especially at the rather limited and introductory skill level that a graduate from one of these programs, who otherwise had NO real world experience would have to offer. This company (ooops, not for profit organization) has spent a lot of time and money on its "certification" materials, and now, if they don't integrate XML training into their certification program in general, and quickly, because soon many of these complicated protocols will no longer be necessary now that XML is making it easy to exchange data. Ouch for them! No more complicated protocols for corporations to have to spend thousands of dollars on training courses for -- CompTIA makes its bread and butter on these complications. So the longer it can convince its members that they don't really "need" XML, the better for business...</opinion> 6. To CompTIA's defense, I suppose they could be just really, really, confused. As evidenced by this exerpt from their press release about their comments on the RosettaNet PIPs: > The ECSB, which reviewed all of the 42 RosettaNet Partner Interface Processes (PIPs) and the implementation framework, focused > its comments on regulatory, legal, revenue, privacy and tax guidelines faced by companies conducting business in multiple > countries. Specific comments concerned the inability to use an ANSI framework among large and small partners outside of the US, > standard identification protocols such as the DUNS number that are not prevalent in Europe, Asia and Latin America and the > requirement for UCC/EAN GTIN numbers that are not sufficient to uniquely identify trade globally. Any XML E-commerce standard will undoubtedly be incorporating all of these identification mechanisms into its larger framework. At least, these were non-issues over a year ago when RosettaNet began (the article is also incorrect when it says the organization was just launched in June -- we all know that!) > The standards-setting group, called RosettaNet, > was launched with much ballyhoo in June to > harness the XML software language to speed the > transmission of data across electronic networks > linking computer and software makers, parts > suppliers and distributors. I'm not even going to bother pointing out the other inaccuracies... 7. This part is just plain silly: > > The review also addressed problems communicating name and address purchase information across country boundaries, > requirements of identification of country of origin and destination within the information technology fulfillment chain. These "technical" issues were some of the first to be solved. Only the politics of such transactions still need to be determined. The legal ramifications of such transactions are still very much up in the air. But "communicating" country and identification information across international boundaries? I think almost ANY XML-based specification would have that covered :-) 8. In conclusion: what a sad, sad day for american journalism indeed -- 9. The moral: think twice before you take an AP story at face value -- this little episode should prove once and for all that they are NOT checking for accuracy, verifying sources, or doing anything else that ANY respectable news bureau, much less one of the two or three bureaus who, if anything, should be taking EXTRA precautions due to their position of privilege in the eyes of the public at large (rather than setting new records of inaccurate, sloppy reporting). The technical ramifications: NULL SET Okay in all fairness, this took me about an hour to finish writing it up, not just the twenty minutes to research -- but if I were to print a story on XML.com I'd have to get original quotes and additional factual verifications from every organization involved -- and i'm not sure i wish to commit any more time to clearing up someone else's misinformation. I'm still not convinced that I'm not just playing right into their political press machine by writing about it at all, much less giving them additional coverage online :-) Hope this has been helpful in clearing up this press mess. Needless to say, if anyone feels that anything contained in this email is inaccurate, speak up and set me straight -- as long as you can reference the source of your "corrected" information -- so we don't just end up in heresay circles again, ok? take care, lisa rein http://www.finetuning.com Orin Rehorst wrote: > > Please comment on the following (source; > http://www.zdnet.com/anchordesk/story/story_3824.html): > <http://www.zdnet.com/anchordesk/story/story_3824.html):> > > The Computing Technology Industry Association rejected a proposed standard > for XML software that would speed the easy exchange of data between > networks. The group said the proposal skewed toward American firms and would > prevent European companies from taking part. The move is likely to delay > release of an XML standard, which previously had been expected next > February. Jesse's take: Given the importance of XML to the Net's future, > this is a disappointing and foolish setback; and smacks of anti-American > sentiment. > > Regards, > Orin Rehorst > Port of Houston Authority > > ========================================== > XML/EDI Group members-only discussion list > Homepage = http://www.xmledi.com > > Brought to you by: Online Technologies Corporation > Home of BizServe - www.bizserve.com > > TO UNSUBSCRIBE: Send email to <xmledi-list-request@lists.bizserve.com> > Leave the subject blank, and > In the body of the message, enter ONLY: unsubscribe > > Questions/requests should be sent to: owner-xmledi-list@bizserve.com > To join the XML/EDI Group complete the form located at: > http://www.geocities.com/WallStreet/Floor/5815/mail1.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lee at fastwater.com Tue Sep 7 00:37:23 1999 From: lee at fastwater.com (Lee Fife) Date: Mon Jun 7 17:14:42 2004 Subject: Namespace for HTML (Signup Here) References: <000401bef8b3$86d9aec0$6645fea9@w21tp> Message-ID: <37D44269.2216CDB2@fastwater.com> My vote: either 3 or 4. -Lee Don Park wrote: > Both Tim Bray and David Megginson proposed we settle on the Namespace URI > for HTML. I think this is a clear enough and small enough task for us > (XML-DEV) to accomplish here and now. > > Here are some candidates: > > 1) "http://www.w3.org/Markup/" - by David Megginson > 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray > 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :) > > Lets just settle on one and start using it. If W3C balks, we can go with: > > 4) "http://www.xml.org/HTML/2000/Namespace" - (if Jon Bosak agrees) > > Signup by replying with one of the numbered options. > > ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Tue Sep 7 01:19:58 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:14:42 2004 Subject: Namespace for HTML (Signup Here) References: <000401bef8b3$86d9aec0$6645fea9@w21tp> <37D44269.2216CDB2@fastwater.com> Message-ID: <37D44C8B.60684AD8@allette.com.au> Lee Fife wrote: > My vote: either 3 or 4. > > -Lee Rather than getting a boxful of mail like this, could we ask someone to tally the votes? Might I suggest that a subject reflecting the voters choice be used, for example "Re: Namespace for HTML (3 or 4)" with nothing in the body? Don Park, you started this and I would have no problem with entrusting you with the count, but if you can't do it, I could (if there were no objections). All votes would be made available to anyone who asked (making the process accountable :-) after the deadline. -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at qub.com Tue Sep 7 01:14:52 1999 From: paul at qub.com (Paul Tchistopolskii) Date: Mon Jun 7 17:14:42 2004 Subject: Hierarchical namespaces. Re: Namespace for HTML (Signup Here) References: <000401bef8b3$86d9aec0$6645fea9@w21tp> Message-ID: <010301bef8be$5961aa00$5df5c13f@PaulTchistopolskii> > Both Tim Bray and David Megginson proposed we settle on the Namespace URI > for HTML. I think this is a clear enough and small enough task for us > (XML-DEV) to accomplish here and now. I'm having impression that I'm stupid, but I don't think that designing even trivial hierarchy is small and easy task, if taking into account that almost any hierarchy should consider future inheritance. The URIs will appear in thousands of documents. I guess that folks who designed UNIX were not happy with their 'creat' syscall ( instead of 'create' ). It's to illustrate my point that sometimes just one character matters. Of course, the URIs problem it's a small problem if comparing it with other problems of XML. Anyway. The URI is very importent chunk of information about the namespace. Maybe it's my mistake to consider it to be important, but my experience shows me that when designing public API's spending just one day thinking about good naming convention is importent. In case that I have missed some previous attempt of W3C to design the structure of URI sufficient for a long run, could anybody please point me the URL I can read on this? > Here are some candidates: > > 1) "http://www.w3.org/Markup/" - by David Megginson The best one. I like it more than other variants. It is clear hierarchy : Vendor Area But it is not perfect. Were is the word HTML here? What would be the relation with XHTML ? I think this name could be improved to become: http://www.w3.org/Markup/HTML Which would allow http://www.w3.org/Markup/XHTML In the future. 1. I don't think TR or other versioning information should be presented in the URI, but I'm not sure. 2. I think that because namespaces are common for all other standarts one should think about the flexible, reasonable and expandable hierarchy of namespaces. 2. I don't think just simple prefix matching would work on long run. For example, I can imagine a situation when some new vendor comes with something 'inherited from' http://www.w3.org/Markup/HTML/ But it would cause http://the.vendor.id/Markup/HTML/extension > 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray > 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :) Don't think the information should be duplicated. The URI will already appear in the 'namespace' instruction, so there is no need in word 'namespace'. I don't think information about the dates should be in the URI. Vendor Area Subarea may be enough for most cases. Unfortunately there is no way to do some complex things with trivial inheritance, but I don't think it would be a problem. My idea is that namespaces URIs should not be as chaotic as they are now. It is public API ! Who was blaming MS ? ;-) Again - maybe I'm missing something. Conclusion. I don't think URIs should be just some abstract and unpredictable strings because URIs are part of XML public API. Namespaces affect every part of XML. 'Saving' one day not designing this part of public API seems strange. If that day has been spend already - is there any way to check what was the descision ? Rgds.Paul. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= paul@pault.com www.renderx.com www.pault.com XMLTube * Perl/JavaConnector * PerlApplicationServer =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mgl at cereus7.com Tue Sep 7 01:53:55 1999 From: mgl at cereus7.com (mgl@cereus7.com) Date: Mon Jun 7 17:14:42 2004 Subject: XML through XSL to HTML translation Message-ID: <199909062355.QAA11535@proxy3.ba.best.com> Hi there XML/XSL folks, I have a need to generate HTML pages (for 4.x and above browsers) and would like to mainly author in HTML but would like to use XML for data storage and XSL to "insert" the XML data into the HTML code. The problem I'm facing at this point is that there seems (a) no tools for creating XSL style sheets that emit HTML (without hand coding the entire HTML, i.e. <BODY> etc., etc.) nnd/or (b) No existing tools for encoding HTML with data references as an XSL style sheet automatically. My current thoughts are to author the HTML and then go back and put comments into the HTML that specify where the data extracted from the XML should go and then translate (somehow) that HTML document into an XSL style sheet so that when I use XML + XSL the result becomes well formed HTML. As there is currently (as far as I can find) one browser (IE5) that supports XSL directly and many of my target systems are non-MS-using companies, just using XSL (via IE5) is not an answer. If this has previously been discussed to death, I appologize and humbly ask someone to send me the results / post-mortem or whatever. If not, I'd love to hear anyone with tools, ideas and/or alternatives. Regards, Michael Lehman System Architect Cereus Design Corp. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Tue Sep 7 02:43:07 1999 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:14:42 2004 Subject: xmlns:html="foo" - a cross-browser solution? References: <000401bef8b3$86d9aec0$6645fea9@w21tp> Message-ID: <37D464F9.FB8DC8DE@finetuning.com> Idea: Right now, millions of confused HTML authors are anxiously waiting to use namespaces, even though most of them are not sure why. I'm not usually one to give HTML special treatment :-), but it might be worthwhile in this case: there are a billion versions of the HTML specs out there, all those HTML Doctypes addresses, W3C website addresses for the specs themselves, and whatever else someone might mistake for the correct URI value (should one ever be chosen). With all this in mind, how can we just pick out a single HTML NameSpace URI amongst ourselves during one holiday-ish afternoon on a mailing list and then expect for that value (or any other single value) to be wholeheartedly "adopted" by every past, present, and future follower? That gave me an idea: What about allowing ANY unique URI value to be declared within the html namespace; they would just be used for rendering well-formed HTML from within a browser (all it really should be used for anyway)... This way, the IE5+ and Mozilla 5+ html namespace declarations could at least be made compatible -- next time around -- no excuses :-) Something like this: <webpage xmlns="http://www.mytagset.com" xmlns:html="http://www.aolownusnow.com/mozilla/html/whatever" > or <webpage xmlns="http://www.mytagset.com" xmlns:html="http://www.aolareourpals.com/ie/html/whatever" > Which is really just this to their respective, embedded processors: <webpage xmlns="http://www.mytagset.com" xmlns:html="foo" > Since each browsers' HTML display behavior is essentially hardcoded in, making its rendering behavior effectively application-specific anyhow. Wouldn't it at least be helpful to have that next time around thing cleared up? This would also make things "easy" for all walks of HTML authors -- and keep things backwards-and-forwards-compatible. Would this create other problems I haven't thought of yet? 2. And we are NOT talking about XHTML, right? XHTML is the components made up of well-defined collections of HTML elements, and XHTML must have an explicitly-defined Namespace, etc..... Right? :-) thanks, lisa Don Park wrote: > > Both Tim Bray and David Megginson proposed we settle on the Namespace URI > for HTML. I think this is a clear enough and small enough task for us > (XML-DEV) to accomplish here and now. > > Here are some candidates: > > 1) "http://www.w3.org/Markup/" - by David Megginson > 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray > 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :) > > Lets just settle on one and start using it. If W3C balks, we can go with: > > 4) "http://www.xml.org/HTML/2000/Namespace" - (if Jon Bosak agrees) > > Signup by replying with one of the numbered options. > > If you are against this proposal, select this: > > 0) "hell://no.stinking.namespace/4/HTML" > > Best, > > Don Park - mailto:donpark@docuverse.com > Docuverse - http://www.docuverse.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Tue Sep 7 04:01:25 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:42 2004 Subject: xmlns:html="foo" - a cross-browser solution? References: <000401bef8b3$86d9aec0$6645fea9@w21tp> <37D464F9.FB8DC8DE@finetuning.com> Message-ID: <37D4725B.DAC8F996@pacbell.net> Lisa Rein wrote: > > That gave me an idea: What about allowing ANY unique URI value to be > declared within the html namespace; Somehow I don't think making the prefix ("html") become a reserved word is the right way to go ... - 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 aray at q2.net Tue Sep 7 06:23:49 1999 From: aray at q2.net (Arjun Ray) Date: Mon Jun 7 17:14:43 2004 Subject: an unfilled need In-Reply-To: <37D3F74D.AA84B8FF@praxis.cz> Message-ID: <Pine.LNX.3.95.990907004212.8336L-100000@mail.q2.net> On Mon, 6 Sep 1999, Matthew Gertner wrote: > No one objected to the W3C controlling XML at the onset because it was > far from a foregone conclusion that XML was win over a number of > plausible (but in retrospect clearly inferior) approaches. Now XML is > mainstream and this no longer flies. Actually, the origin of XML as a W3C activity was irregular: it didn't become an approved activity until Summer '97, at which point the ERB+WG structure (with a "closed but public" mailing list) was reorganized into the new WG+SIG (and the mailing list was sucked into the Members Area.) The original list did make of use of W3C facilities (generously extended), but my impression is that there was a "wait and see" approach at work, and XML wasn't really -ahem- assimilated until it had proved itself in the form of the Nov'96 draft. > Lack of complete buyin (not to mention open hostility) from XML > developers is certainly not in the W3C's interest, and only opens the > way for Microsoft and other major players to step in with their own > proprietary (and inevitably less well thought out) approaches. I would argue that it was in Microsoft et al's *interest* to "close" XML to the wider community. How else could they exploit standardization as a marketing tool? I'll just point out that namespaces were discussed exhaustively at least twice on the WG/SIG. Avaliable to the public is the discussion of Microsoft's "Structured Data" proposal in May '97: SD5 was about namespaces. <URL:http://lists.w3.org/Archive/Public/w3c-sgml-wg/1997May/> Very very unfortunately, the discussion preceding the XML Namespaces Draft was on the new list, which the public can't see. (Since the SIG has been dead for a year, the reasons why the archive shouldn't be made public seem to be political.) Arjun xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gregg at informalsoftware.com Tue Sep 7 06:59:30 1999 From: gregg at informalsoftware.com (GW) Date: Mon Jun 7 17:14:43 2004 Subject: Who's actually into VML? Message-ID: <199909070501.WAA04363@proxy4.ba.best.com> Hi - Was wondering if anyone on the list is actually using VML for anything? It's supported in IE5, and so forth but I never see it mentioned on this list; hence I question its viability, reality, whether to invest in the technology or not. Anyone have opinions on whether VML has life? Thanks! xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Sep 7 07:23:54 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:43 2004 Subject: an unfilled need Message-ID: <00f301bef8f2$139be330$5bf96d8c@NT.JELLIFFE.COM.AU> >On Mon, 6 Sep 1999, Matthew Gertner wrote: > >> No one objected to the W3C controlling XML at the onset because it was >> far from a foregone conclusion that XML was win over a number of >> plausible (but in retrospect clearly inferior) approaches. Now XML is >> mainstream and this no longer flies. > > Lack of complete buyin (not to mention open hostility) from XML > >developers is certainly not in the W3C's interest, and only opens the > > way for Microsoft and other major players to step in with their own > > proprietary (and inevitably less well thought out) approaches. I disagree on both counts. Firstly, W3C does not control XML to the extent that they can control other syntaxes, because XML is SGML. Secondly, I think that if Microsoft made a successor to XML, it is quite possible it could be better than XML is, learning from experience. If Microsoft cares to give me a million dollars, I am prepared to develop such a thing! 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 donpark at docuverse.com Tue Sep 7 07:48:44 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:43 2004 Subject: RFP: Namespace URI for HTML In-Reply-To: <37D44C8B.60684AD8@allette.com.au> Message-ID: <000001bef8f5$1cd5c440$5be0fea9@w21tp> All right. I wanted to see the momentum build visually on XML-DEV but I guess there is enough interest to do this proper. Request for Proposal: Namespace URI for HTML Propose what you would like to see as the Namespace URI for HTML. I will collect them all and post it on a public polling site (probably www.freepoll.com) so that we can all take a wack at it. Please send it to me personally rather than posting it to XML-DEV. Current candidates: 0) "hell://no.stinking.namespace/4/HTML" 1) "http://www.w3.org/Markup/" - by David Megginson 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :) 4) "http://www.xml.org/HTML/2000/Namespace" - (if Jon Bosak agrees) 5) "http://www.w3.org/Namespace/HTML/" - by Don Park (2nd try) Deadline for proposal is: September 8th, 1999. Voting can start on 9th and I think one week should be enough. Your comments are welcome. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From aray at q2.net Tue Sep 7 07:47:37 1999 From: aray at q2.net (Arjun Ray) Date: Mon Jun 7 17:14:43 2004 Subject: an unfilled need In-Reply-To: <00f301bef8f2$139be330$5bf96d8c@NT.JELLIFFE.COM.AU> Message-ID: <Pine.LNX.3.95.990907021521.8336N-100000@mail.q2.net> On Tue, 7 Sep 1999, Rick Jelliffe wrote: > Firstly, W3C does not control XML to the extent that they can control > other syntaxes, because XML is SGML. XML is a W3C trademark. I think that settles the "ownership" question. > Secondly, I think that if Microsoft made a successor to XML, it is quite > possible it could be better than XML is, learning from experience. Just as Outlook Express is a "better" newsreader than the many that went before. Experience is one thing. Track record is another. > If Microsoft cares to give me a million dollars, I am prepared to > develop such a thing! But Ricko, that's why they won't give you a million dollars!;) Arjun xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From aray at q2.net Tue Sep 7 08:43:32 1999 From: aray at q2.net (Arjun Ray) Date: Mon Jun 7 17:14:43 2004 Subject: an unfilled need In-Reply-To: <4.1.19990906102427.04097280@mail.webgeek.com> Message-ID: <Pine.LNX.3.95.990907025444.8336R-100000@mail.q2.net> On Mon, 6 Sep 1999, Ann Navarro wrote: > In today's Web browser, there is built-in "knowledge" of what HTML > elements are supposed to be and do. They have been programmed to > recognize a <P> element as a new structural block, presented with a > leading line space, text flush left, unless otherwise indicated in a > style sheet or align attribute. Well, this isn't really true. The popular browsers are inheritors of the Mosaic paradigm, which starts with an inherently different view of tags to begin with - as isolated (or "streamed") embedded commands; the concept of "element" doesn't pertain at all. Consider, for instance, this elaborate non-explanation of why </P> should make a difference: <URL:http://lists.w3.org/Archives/Public/www-style/1998May/0101.html> (This is also why, IMHO, stylesheets never had a chance with these browsers.) > Simple, primarily presentation information, but it's preprogrammed in > how to deal with such elements. [...] Allowing for discovery, based > on a schema, DTD, or whatever other defining mechanism is provided, > lets tomorrow's Web browser have that same "knowledge" of a <foo> > element, How? Either tomorrow's browser has the preprogramming, or it doesn't. Arjun xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at qub.com Tue Sep 7 09:06:13 1999 From: paul at qub.com (Paul Tchistopolskii) Date: Mon Jun 7 17:14:43 2004 Subject: XML belongs to itself. (Re: an unfilled need) References: <00f301bef8f2$139be330$5bf96d8c@NT.JELLIFFE.COM.AU> Message-ID: <029301bef900$2ee924a0$5df5c13f@PaulTchistopolskii> > >On Mon, 6 Sep 1999, Matthew Gertner wrote: > > > >> No one objected to the W3C controlling XML at the onset because it was > >> far from a foregone conclusion that XML was win over a number of > >> plausible (but in retrospect clearly inferior) approaches. Now XML is > >> mainstream and this no longer flies. > > > > Lack of complete buyin (not to mention open hostility) from XML > > >developers is certainly not in the W3C's interest, and only opens the > > > way for Microsoft and other major players to step in with their own > > > proprietary (and inevitably less well thought out) approaches. > > I disagree on both counts. Firstly, W3C does not control XML to the > extent that they can control other syntaxes, because XML is SGML. I disagree that XML is SGML ( I'l try to explain that XML is actualy UNIX ;-) but I agree that it is not *that* important who is 'controling' XML, because from my point of view XML is 'controling itself' more than any vendor or group could do. > Secondly, I think that if Microsoft made a successor to XML, it is quite > possible it could be better than XML is, learning from experience. If > Microsoft cares to give me a million dollars, I am prepared to develop > such a thing! It may be just a bit better ( more likely it would be 'a bit different'). The unbeatable thing about XML is the concept. You can not invent the better concept . ( OK, maybe you can - I don't know... ) XML is good because it is not a big invention - it's kind of reproducing well-known (old) UNIX concepts. If not going into much detail, we could say that the (whole) concept of UNIX was: 1. Everything is a text, because it's easier to read. 2. Do not build monsters but use pipes and small nice bulding blocks instead. The only difference is that XML says: 1. Yes, everything is a text, but we now also have not only English ( unicode ) and also text should be a bit better structured than 'a bunch of lines' ( 'bunch of lines' - is just a special case of a more general - but still trivial - tree structure ). It is kind of simplification, because UNIX has changed, there were more concepts in UNIX, 'everything' means 'mostly everything you need in the real life' e t.c. - I'm writing those 2 axioms because I think that XML has a success *only* because it follows those plain concepts of building scalable and open systems ( just making small change to one of the axioms ). There was no big choice when designing something to match the changed axiom. Sure, we'l get ps -ax and ps -ef. I don't think it is ( would be ) a significant problem or significat improvemet, like most of the problems discussed in maling lists. XML is good not because it is well-designed. Note 1. Maybe it is - it's hard to understand yet, some parts are much better than others ( many people are using XT in the real life, but some standarts are not used at all ). Note 2. Maybe it is - but the design process is unspecified. I can only guess what happens in the XSL FO WG, how do people make analyzis, do they talk to end-users e t.c. XML is a good old concept that works for years (UNIX). Nobody owns the concept. The concept owns itself. Remember when MS tried to introduce UNIX-killer? ( Now known as 'better UNIX than UNIX" ). Actualy, MS is now sponsoring perl ( which is UNIX 'all in one' ) for Windows. Good concept is hard to 'own' or 'kill' , more likely the concept will 'own' you ;-) Rgds.Paul. PS. My apologies for a bit 'abstract' posting - I now promise to stop flooding this malining list for a while, but I realy think that XML is very special case. With XML it is not *very* important who 'owns' the trademark or who is writing standards. I'm not saying that W3C develops bad standards - W3C does a great job. Any process could be improved, of course, but in general - I like the way it goes and I think that it would be hard to find more brilliant persons to make a descisions. Just - please - give a small vendors some way to vote ( just to provide a reality check ) - and it would be absolutely perfect ;-). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= paul@pault.com www.renderx.com www.pault.com XMLTube * Perl/JavaConnector * PerlApplicationServer =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 7 11:11:18 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:43 2004 Subject: confidentiality in W3C WGs Message-ID: <01BEF922.56308FE0@grappa.ito.tu-darmstadt.de> Lauren Wood wrote: > The only really good reason I see for the confidentiality agreement > that exists in several W3C Working Groups has marketing, public > relations, and politics at its base. > > [very good reasons for maintaining confidentiality snippped] > > So sometimes you need confidentiality, to build trust and a > knowledge that what is said in a WG remains within that WG, so > that people can concentrate on the technical work, and not on the > politics. I've only briefly been following this whole discussion, but I don't think anybody has asked for names of who wanted one namespace and who wanted three and who wanted the discussion to simply end because they were late for a flight. I believe what people requested was an explanation of why the change was made: at the very least, what arguments convinced the WG that it was worthwhile, and hopefully a discussion of the alternate positions and why they were rejected. This kind of information, whether normative, in a non-normative appendix, or simply provided in a forum like XML-DEV or an annotated specification, is very helpful in getting buy-in for a specification and, let's face it, a spec isn't useful if nobody buys in. In my experience, most people will listen to an explanation. They might still disagree, but the reaction is often, "Yipes! I see what you mean," and in any case explanations almost always help smooth the acceptance process. On the other hand, when somebody is told, "That's private," the feel rejected and throw out the good with the bad, not for technical reasons, but for purely human ones. -- 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 steven.livingstone at scotent.co.uk Tue Sep 7 11:10:21 1999 From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM) Date: Mon Jun 7 17:14:43 2004 Subject: Test - Pls Ignore Message-ID: <8DCB90532FF7D211B34400805FD48853644CAC@SENMAIL3> Steven Livingstone - http://www.deltabiz.com 07771 957 280 or +447771957280 Author - Professional Site Server 3, Wrox Press http://www.wrox.com/Store/Details.asp?Code=2696 Professional Site Server 3.0 Commerce Edition, Wrox Press http://www.wrox.com/Store/Details.asp?Code=2505 President, AIP Scotland. ceo@citix.com http://www.citix.com Join Association of Internet Professionals - http://www.citix.com/aip xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From digitome at iol.ie Tue Sep 7 11:16:17 1999 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:14:43 2004 Subject: an unfilled need Message-ID: <3.0.6.32.19990907100342.009fa980@gpo.iol.ie> >David Megginson wrote: > >: Perhaps an example would help. Here's an XML document (without >: Namespaces for now): >: >: <bllrp zata="-1"> >: <poiuk>112</poiuk> >: <pppzzz>g</pppzzz> >: <ttt>xxx<rte w="3"/></ttt> >: </bllrp> >: >: Now, imagine that my XML application has just received this piece of >: XML and knows nothing about the markup language used. What kind of >: information should it be able to discover automatically, so that it >: can process this document usefully? >: > [Brendan McKenna] > I would say that that depended on the application. Precisely! But the number of potential applications is infinite. The amount of stuff you would need to "discover" is infinite. That is why inventing declarative syntaxes for discoverable knowledge such as rendering semantics, interactive behaviour, computation etc. will always be a sandwich short of the full picnic. The most general way to deal with the fact that so much depends on the application, is to soft-code the application. In browser land, this is like saying that we should take out the hardwired rendering engine and download it along with the data. The PostScript printer approach. It is as Nicklaus Wirth put it : "Algorithms + Data Structures = Programs". In the XML world we can re-phrase this as "Java + XML = Programs" or "Perl + XML = Programs" or (my personal favourite) "Python + XML = Programs". A truly general solution needs both algorithm and data. The headling rush into XML seems to have caused people to loose sight of this and put all their faith in XML syntaxes doing *everything*. Whatever way you cut it, to truly general-purposify a "browser" you need to soft-code its algorithms. In some alternative universe you can write this:- <Package> <program language="Python"> Bank.Debit ( (bllrp.zata * rte.w )/ GoldenRatio ) </program> <data> <bllrp zata="-1"> <poiuk>112</poiuk> <pppzzz>g</pppzzz> <ttt>xxx<rte w="3"/></ttt> </bllrp> </data> </Package> This approach will get you there a lot faster than waiting for the "bank debit golden ratio rte interest group" to finalize their declarative syntax for what the bllrp element really means... regards, <Sean URI="http://www.digitome.com/sean.html"> Developers Day Co-Chair, 9th International World Wide Web Conference 16-19, May, 2000, Amsterdam, The Netherlands http://www9.org </Sean> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Tue Sep 7 11:19:21 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:43 2004 Subject: ANN: XML and Databases article Message-ID: <01BEF923.76896540@grappa.ito.tu-darmstadt.de> [My apologies if you get this twice -- my email's been on the blink and I'm not sure if the first message got through.] I've written an article about XML and databases -- why you might want to use a database with XML, what are some of the technical issues involved, how available middleware transfers XML documents to/from databases, and what software is currently available to do this. You can find the article at: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/XMLAndDatab ases.htm Comments welcome. -- 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 matthew at praxis.cz Tue Sep 7 11:34:10 1999 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:14:43 2004 Subject: W3C policies (Was Re: an unfilled need) References: <00f301bef8f2$139be330$5bf96d8c@NT.JELLIFFE.COM.AU> Message-ID: <37D4DC7D.7C17841E@praxis.cz> > I disagree on both counts. Firstly, W3C does not control XML to the > extent that they can control other syntaxes, because XML is SGML. > Secondly, I think that if Microsoft made a successor to XML, it is quite > possible it could be better than XML is, learning from experience. If > Microsoft cares to give me a million dollars, I am prepared to develop > such a thing! Just to be clear, the XML recommendation in itself is a fantastic piece of work, especially considering the tightrope that had to be walked between SGML traditionalists and HTML mainstreamers. Could it be better? Sure, and if anyone catches me drinking in a hotel lobby and wants to hear a long unfocused rant about how much I hate external entity references, I'm always amenable. The point is that for what XML tries to do (and I refer here only to the Feb98 recommendation) it is more than good enough. I can't imagine Microsoft or anyone else wanting to redo all this work for the sake of some marginal benefit. On the other hand, XML is incomplete. There seems to be a quite strong consensus (at least in this list, which I assume is somewhat representative) that the following aspects still need treatment if XML is going to live up to all the promises we have been proclaiming from the rooftops (universal data exchange, data perennity, application interoperability, world peace, etc.): 1) A better schema language than DTDs 2) Some means of finding out what semantics are associated with a document I thought I was going to type a long list, but it seems to me that this would actually be sufficient. There seems to be agreement that other important issues (like stylesheets and namespaces) are solved or at least well on their way. This might not seem clear in the case of namespaces, but most of the objections to the current spec are really just hankering for 2) in disguise. So the question is, would we rather see these things come about through some open process or by dictate from some corporate titan focused on its own self-interest? I don't want to sound like a starry-eyed idealist, but as XML folks we all understand the value of freely available information. Can't we leverage the network infrastructure provided by the Internet to reform the standards process into something more appropriate for this day and age? The argument that "it's a hell of a lot better than ISO" is not entirely satisfying. (No offense to any ISOers out there; I have no experience with this myself but I've heard a lot of people who do make this statement.) I read Lauren's post on this issue with interest and she makes a very sensible argument. I hadn't seen things from exactly this perspective, so I was glad to be exposed to this viewpoint. But I'm still not convinced. The press no longer controls the public's access to information. Open access to working group proceedings would presumably make it harder for journalists to misrepresent what went on between company A and company B, not easier, since anyone with a Web browser could surf over to the W3C and check it out themselves. If this forces companies to be more aware of how their actions could affect the way the public perceives them, isn't this an unambiguously good thing for everyone except for a handful of large and/or well-connected companies (and in the aggregate, probably for them too)? The word "political" keeps coming up in this context, and yes, we need to accept political realities. What I was trying to argue in my original post is that the choice is not between closed (i.e. non-publicly accessible) development of further XML-related standards (favored by larger companies and insiders) or open processes (favored by the unorganized masses). If this were the case, the political reality would be that the processes are going to stay the way there are. Actually, the W3C may well fail to provide for XML developer's needs in the areas I mentioned above and be preempted by some proprietary approach. This means that even those with a vested interest in maintaining the W3C confidentiality policy (and the power to make this happen) need to think twice about whether this is really in their interests. Taking a "direct democracy" approach where the public at large votes on major decisions in the XML standards process is politically unrealistic and not obviously desirable. We now have the technical means to do the same in the "real" political arena, but it is likely that people will decide to have knowledgeable representatives continue to do the vast majority of this work for them. But providing completely open access to all about what is going on inside the W3C's various groups would bring a ton of benefits, clearing away a lot of bad feelings and misunderstandings, opening critical and tricky decisions to widespread debate, enabling W3C members to participate more freely in outside discussions instead of brushing off interested and justified enquiries, etc., etc. Sure, there would be a couple of additional risks to watch out for, but the conclusion that these are of overriding importance is far from obvious. Matthew xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 at praxis.cz Tue Sep 7 12:01:11 1999 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:14:43 2004 Subject: Discovering semantics (Was Re: an unfilled need) References: <3.0.6.32.19990907100342.009fa980@gpo.iol.ie> Message-ID: <37D4E2CB.1AF7E943@praxis.cz> > Precisely! But the number of potential applications is infinite. The > amount of stuff you would need to "discover" is infinite. That > is why inventing declarative syntaxes for discoverable knowledge > such as rendering semantics, interactive behaviour, computation > etc. will always be a sandwich short of the full picnic. And rightly so, since this will enable software vendors to create their own sandwich, keeping the idea market open to innovation and progress. But that still leaves a hell of a lot of beer and potato salad for the standards makers: 1) Associating element types with rendering semantics Everyone agrees on this. We want a default way to view a document in a browser in some readable way. Right now the stylesheet associated with a document is specified in the document instance, but it could just as easily be placed in a central repository and retrieve via query. In addition, there's obviously no reason why several stylesheets couldn't be associated with a single document, au choix. I'm way out of my depth here, but presumably if font-makers can come up with universally understandable, orthogonal attributes like "sans serif", "bold" or "italic", then the same could be done for stylesheets. I'm no expert on aesthetics, but this would be cool even if I just got a list of available stylesheets with a descriptive name for each when I access a document. 2) Associating element types with other semantics ...maybe in the form of Java classes (beans or otherwise). You won't get a fully fledged application, of course, you could at least have a standard method for viewing (which might well be done through some other means than a stylesheet -- imagine a CML document), printing and editing. And there's no reason why arbitrary methods could not be available too. So I receive my "invoice" document and go to the central semantics repository to see what methods are available for it. If I find a method for, say, calculating the total price of the invoice, I don't have to duplicate this code in my application. Objections to putative methods for discovering semantics tend to be based on unrealistic expectations about what this could do. There isn't any need for "Java ontologies" or code that works everywhere in every situation in order to do useful stuff. If I can publish my schema in a central place alongside some code, then I am providing far more for others to reuse than if I publish the data alone. If others can extend my code (through aggregation or -- please! -- inheritance) then there is a real chance that a rich set of reusable syntaxes and associated code will spring up organically for a variety of application domains. So what if I have to go query the repository by hand and then hard-code the link to the appropriate application logic into my document instance? And if someone manages to figure out some basic hierarchical organization for the repository, a la Yahoo, well it would seem petty to bicker about a missing sandwich or two... Matthew xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 7 12:11:59 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:43 2004 Subject: an unfilled need In-Reply-To: <3.0.32.19990906111905.00abd6c0@pop.intergate.bc.ca> References: <3.0.32.19990906111905.00abd6c0@pop.intergate.bc.ca> Message-ID: <14292.58565.93178.895487@localhost.localdomain> Tim Bray writes: > At 01:54 PM 9/6/99 -0400, David Megginson wrote: > Hmm, I observe that the namespace name hardwired to the prefix > "xml:" is > > http://www.w3.org/XML/1998/namespace > > (amusing, since the namespace spec is dated January 1999). Anyhow, > I seem to recall that Dan Connolly cooked this up on behalf of the > W3C and there was a real good reason which I unfortunately forget > for having a date in there. Dan's suggestion is that if someone else ends up owning the w3.org domain some day, they're less likely to create their own, identical Namespace URI if the URI contains a stale date. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Sep 7 12:20:35 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:43 2004 Subject: Namespace for HTML (Signup Here) In-Reply-To: <000401bef8b3$86d9aec0$6645fea9@w21tp> References: <3.0.32.19990906111905.00abd6c0@pop.intergate.bc.ca> <000401bef8b3$86d9aec0$6645fea9@w21tp> Message-ID: <14292.58847.24153.172583@localhost.localdomain> Don Park writes: > Both Tim Bray and David Megginson proposed we settle on the Namespace URI > for HTML. I think this is a clear enough and small enough task for us > (XML-DEV) to accomplish here and now. No, I'm not proposing that quite yet -- the HTML WG is still discussing this issue, and things might still change before the XHTML REC comes out. > Here are some candidates: > > 1) "http://www.w3.org/Markup/" - by David Megginson > 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray > 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :) None of these is under our control -- they would have to be proposed from within the W3C, and I cannot see any being approved without the HTML WG's consent. > Lets just settle on one and start using it. If W3C balks, we can go with: > > 4) "http://www.xml.org/HTML/2000/Namespace" - (if Jon Bosak agrees) OASIS controls xml.org now, and they probably would not want to set themselves up in direct opposition to the W3C like this. > Signup by replying with one of the numbered options. Let's just wait a little while. We've made our opinions well-known on the XML-Dev mailing list, and I know that many people here have sent their comments into the Director or the HTML WG. I don't think that I'm breaching member-confidentiality rules by saying that our discussions here have been noticed. If anyone is really excited and cannot wait to act, go buy the namespaces.com domain so that we have somewhere to hang this sort of thing. purl.org might also be co-operative. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Sep 7 12:34:20 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:43 2004 Subject: MSFT is innocent, this time (was Re: an unfilled need) In-Reply-To: <Pine.LNX.3.95.990907004212.8336L-100000@mail.q2.net> References: <37D3F74D.AA84B8FF@praxis.cz> <Pine.LNX.3.95.990907004212.8336L-100000@mail.q2.net> Message-ID: <14292.59533.863961.498295@localhost.localdomain> Arjun Ray writes: > > Lack of complete buyin (not to mention open hostility) from XML > > developers is certainly not in the W3C's interest, and only opens > > the way for Microsoft and other major players to step in with > > their own proprietary (and inevitably less well thought out) > > approaches. > > I would argue that it was in Microsoft et al's *interest* to > "close" XML to the wider community. How else could they exploit > standardization as a marketing tool? I've been a Linux user since 1993 (and a Minix user before that) and am, in general, a rabid anti-Redmond person, but I'd like to point out (at the risk of breaching confidentiality) that Microsoft is not conspiring to keep XML secret, and that when its representatives have pushed on committees where I've been present, they've generally pushed for an earlier and simpler public release rather than a later or more complex one, and have often accepted compromises to help consensus. Others' mileage may vary, but my experience is that the big companies need XML to become an open commodity, while the smaller ones sometimes have more of an interest in obfuscation (because XML is just a side dish for the big ones but bread-and-butter for the small). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Veillard at w3.org Tue Sep 7 14:20:32 1999 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:14:43 2004 Subject: Namespace for HTML (Signup Here) In-Reply-To: <14292.58847.24153.172583@localhost.localdomain> References: <3.0.32.19990906111905.00abd6c0@pop.intergate.bc.ca> <000401bef8b3$86d9aec0$6645fea9@w21tp> <14292.58847.24153.172583@localhost.localdomain> Message-ID: <19990907082301.G6649@w3.org> I would just like to raise the point that, if within xml-dev an HTML naming space is designated, then it will just make things harder, software writer (and I'm one of those) will have to support 4 namespaces instead of 3 (or 2 instead of one), since I don't believe the XHTML WG would find it easy to change a Proposed REC draft (and all the implementation which are certainly be worked on in various places). As David said at least some of the WG members got the feedback especially Ann (and independantly of the technical issue itself she has done an impressive job at reading and answering people mails, hat off ...). Let's see what is the final outcome. > If anyone is really excited and cannot wait to act, go buy the > namespaces.com domain so that we have somewhere to hang this sort of > thing. purl.org might also be co-operative. too late, it's already reserved :-) Banyan Systems (NAMESPACE-DOM) 115 Flanders Road Westboro, MA 01581 US and the .org and .net are bought already too <grin/> Daniel -- 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, XML, http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 7 15:15:07 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:43 2004 Subject: What XML-dev can do (was Re: an unfilled need) In-Reply-To: <37D4247B.4FD2@hiwaay.net> References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> <37D3F74D.AA84B8FF@praxis.cz> Message-ID: <199909071317.JAA05607@hesketh.net> At 03:30 PM 9/6/99 -0500, Len Bullard wrote: >Now, the rest of you should decide what you want to use namespaces >for and just do it. You don't need permission and if you wait for it, >you only fall behind in development. and Matthew Gertner later wrote: >So the question is, would we rather see these things come about through >some open process or by dictate from some corporate titan focused on its >own self-interest? I don't want to sound like a starry-eyed idealist, >but as XML folks we all understand the value of freely available >information. Can't we leverage the network infrastructure provided by >the Internet to reform the standards process into something more >appropriate for this day and age? We already have an excellent forum for discussing all of these issues, for making proposals and presenting implementations. XML-dev has shown itself capable in the past of building standards through open process (SAX, DDML) and even in getting those standards widely adopted (SAX). There are no membership fees, there is no official process, there are no barriers. In the past, a lot of projects on XML-dev have faced an uphill fight until it became very clear that the W3C wasn't going to claim that space as its own turf and thereby obsolete our work. (In DDML's case, the proposal we wrote was submitted to the W3C as a Note and became one of several inputs to their schema project.) It doesn't seem sensible, however, to be afraid of the W3C. There are a lot of projects they don't seem interested in working on, and there are even more cases where people need standards (like the namespaces issues Len noted above) that go beyond what the W3C is currently providing. Matt's list included two possibilities: >1) A better schema language than DTDs >2) Some means of finding out what semantics are associated with a >document I'd add: 3) A way to associate prefixes with namespace URIs in DTDs (I could do that!) 4) Some means of discovering what kind of processing is needed for a document 5) A way to profile or subset XML itself (ties into 4 somewhat) 6) A set of tools for querying XML documents (discussed at W3C, but nothing yet) 7) A convention for mapping data types into DTDs (XML Authority has one) 8) Whatever else comes to mind - I'm only on my first cup of coffee. Some of these projects have been talked about at the W3C, some (Matt's #1) are enjoying the full thrills of W3C WGs. Others, though they might be useful, even easy, appear to have fallen off the radar. This doesn't even begin to get into the application development possibilities for XML, on which the members of this list are constantly working. The surface has barely been scratched, though. It's a lot of work, and I know it isn't always fun. Most of us do have other lives and all of that, and a significant portion of us have other lives already spent at the W3C. It does seem, however, like a lot of this could be rewarding. Personally, professionally, even politically. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 Tue Sep 7 15:41:22 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:14:43 2004 Subject: Why focus on HTML? References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca><37D3F74D.AA84B8FF@praxis.cz> <199909071317.JAA05607@hesketh.net> Message-ID: <014101bef937$73ad3040$1618ccce@pebbles> I've been reading the messages lately on the XML-DEV list and wanted to share an observation. You have a choice as to where you channel your energies. Rearchitecting HTML is going to be a problem because it is already so deeply rooted. It may look like fun, or a place of power, but that's an illusion. No one has the power to rearchitect it. It's a thing of nature. W3C is powerless, as are the browser vendors, as is the XML-DEV list. It doesn't matter what politics happen in W3C. They have no control over the HTML code that's already deployed, and very limited influence over the HTML that will be deployed in the future. Look at the low rate of adoption of everything related to web browsers and don't blame Microsoft for that, it's a market speaking, and big markets move s-l-o-w-l-y and for good reason. So, if you believe that, as I do, why not channel your energies into spaces where there is no installed base? XML opens all kinds of possibilities. Why not spread out and focus on implementations that use the net in new ways? Or try out some new ideas. Why channel all the energy into a place where not much can be done? My opinion only.. 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 dave at userland.com Tue Sep 7 16:44:55 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:14:43 2004 Subject: Why focus on HTML? References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca><37D3F74D.AA84B8FF@praxis.cz><199909071317.JAA05607@hesketh.net> <3.0.6.32.19990907074023.00984e90@mail.dt1.sdca.home.com> Message-ID: <014701bef940$64943410$1618ccce@pebbles> > More energy into actual XML apps and things like XML-RPC. Well, now that you mention it, there has been a lot of movement in XML-RPC-land in the last week. A summary is here: http://discuss.userland.com/msgReader$10661 The party is just beginning! Still lots of wide open space and room for creative contributions. 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 Mark.Volkmann at AGEDWARDS.com Tue Sep 7 16:58:22 1999 From: Mark.Volkmann at AGEDWARDS.com (Volkmann, Mark) Date: Mon Jun 7 17:14:43 2004 Subject: need XML DOM parser for COBOL Message-ID: <5D176C6118FFD211B3A700902761F0F0FC4327@hqexchn8.agedwards.com> I'm interested in using XML for data transport between a PC or Solaris box and a mainframe in an organization where COBOL is the preferred mainframe language. I've searched for a COBOL-based DOM parser to no avail. Is anyone aware of one? -- __ __ / \/ \ Object Computing, Inc. \ / ark (314)589-1617 pager \ / (314)955-8087 A.G.Edwards \ / olkmann volkmann@inlink.com \/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990907/128d9e41/attachment.htm From srn at techno.com Tue Sep 7 17:00:28 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:14:43 2004 Subject: ANN: XML and Databases article In-Reply-To: <01BEF923.76896540@grappa.ito.tu-darmstadt.de> (message from Ronald Bourret on Tue, 7 Sep 1999 11:23:47 +0200) References: <01BEF923.76896540@grappa.ito.tu-darmstadt.de> Message-ID: <199909071453.JAA01354@bruno.techno.com> [Ron Bourret:] > I've written an article about XML and databases -- why you might want to > use a database with XML, what are some of the technical issues involved, > how available middleware transfers XML documents to/from databases, and > what software is currently available to do this. You can find the article > at: > > http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xml/XMLAndDatabases.htm > > Comments welcome. I learned some interesting things from this article, for which I'm grateful. Recommended reading! I was disappointed that the grove paradigm (http://www.prescod.net/groves/shorttut/) was never mentioned, nor was GroveMinder (http://www.techno.com). The grove paradigm offers an ISO-defined meta-DOM to all notations, including XML. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 fax +1 972 994 0087 pager (150 characters max): srn-page@techno.com 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 mike.champion at sagus.com Tue Sep 7 17:04:10 1999 From: mike.champion at sagus.com (Michael Champion) Date: Mon Jun 7 17:14:43 2004 Subject: XML Database/Repository with content indexing ? References: <199909061659.SAA05197@chimay.loria.fr> Message-ID: <011601bef942$e91e7e00$5bbeb3c7@mccdell> ----- Original Message ----- From: Patrice Bonhomme <Patrice.Bonhomme@loria.fr> To: <xml-dev@ic.ac.uk> Sent: Monday, September 06, 1999 12:59 PM Subject: XML Database/Repository with content indexing ? > > <Hi/> > > I was wondering if it exists some XML database system that provide a content > (full text) indexing mechanism. This system should be able to answer to this > query : give me all documents that contains the expression "big blue" within > their "/TEI.2/teiHeader/*/title" element(s). My apologies if this goes out twice, but check out Software AG's soon to be released native XML database system at http://www.softwareag.com/tamino/ Also, the "XML and Databases" article pointed to by Ron Bourret's recent posting contains a nice summary of various XML database products. Mike Champion xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 7 17:15:14 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:43 2004 Subject: an unfilled need Message-ID: <3.0.32.19990907081729.00c01680@pop.intergate.bc.ca> At 12:55 AM 9/7/99 -0400, Arjun Ray wrote: >Actually, the origin of XML as a W3C activity was irregular: it didn't >become an approved activity until Summer '97, at which point the ERB+WG >structure (with a "closed but public" mailing list) was reorganized into >the new WG+SIG (and the mailing list was sucked into the Members Area.) Historically inaccurate. XML was an official W3C activity starting in July '96. The re-organization you describe (accurately) was part of a W3C-wide process regularization. It is correct to say that the W3C staff & management didn't really take XML seriously until the late spring of '97. -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 donpark at docuverse.com Tue Sep 7 17:42:02 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:43 2004 Subject: Namespace for HTML (Signup Here) Message-ID: <000201bef948$07f4d540$16a1fea9@w21tp> David and Tim, Sorry about misrepresenting your 'pleas' (see below) to the HTML WG as proposals to XML-DEV. Frankly, I am too much of an ego maniac to even consider begging an unreasonable group to make a reasonable decision. While I am certain that not all of the HTML WG members are unreasonable, I can not ignore the decision of the whole nor the hand of 'god' that took part in its unraveling decision. I took the initiative on the Namespace for HTML issue because it is less violent than asking W3C to disband the HTML WG and try again. It was less impossible than expecting W3C to reorganize itself. Will the HTML WG suddenly see the light? I prefer not to hold my breath in suspense and wait helplessly. Best, Don Park Docuverse <author name="David Megginson"> If MS and Netscape/Mozilla both buy into the same Namespace URI, then it won't much matter what the W3C says, but I'd still like to hope that the XHTML WG will give us a URI -- even just a NOTE with the line The XML Namespace URI for HTML is "http://www.w3.org/Markup/". would help prevent the nightmarish interoperability problems that are coming up. If we had this, I'd be willing to wait a while for XHTML proper. </author> <author name="Tim Bray"> "Hmm, I observe that the namespace name hardwired to the prefix "xml:" is http://www.w3.org/XML/1998/namespace (amusing, since the namespace spec is dated January 1999). Anyhow, I seem to recall that Dan Connolly cooked this up on behalf of the W3C and there was a real good reason which I unfortunately forget for having a date in there. So by analogy, a candidate namespace name for HTML would be http://www.w3.org/HTML/1999/namespace And yes, a one-line NOTE on www.w3.org/TR would do the job. Hey there, HTML WG, any chance? If you pick a URI, we all promise not to complain about what it is. Right, guys? </author> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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.Cooper at bender.com Tue Sep 7 17:44:33 1999 From: Clark.Cooper at bender.com (Cooper, Clark) Date: Mon Jun 7 17:14:43 2004 Subject: Article on using expat at www.xml.com Message-ID: <D9F2F531A55CD311AB5D0008C7B1A1955DF405@MBCALBEXC02.BENDER.COM> I've written an article for xml.com (http://www.xml.com) on using expat. Since I've seen requests on this mailing list for information on expat, I thought I'd let you know that it's currently running there. Clark Cooper Logic Technologies, Inc. cccooper@ltionline.com (800)424-4200 650 Franklin St., Suite 304 coopercc@netheaven.com ext 3984 Schenectady, NY 12305 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 dhunter at Mobility.com Tue Sep 7 18:22:13 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:44 2004 Subject: W3C policies (Was Re: an unfilled need) Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFE7D@cc20exch2.mobility.com> > From: Matthew Gertner [mailto:matthew@praxis.cz] > Sent: Tuesday, September 07, 1999 5:36 AM <snip/> > I read Lauren's post on this issue with interest and she makes a very > sensible argument. I hadn't seen things from exactly this perspective, > so I was glad to be exposed to this viewpoint. But I'm still not > convinced. The press no longer controls the public's access to > information. Open access to working group proceedings would presumably > make it harder for journalists to misrepresent what went on between > company A and company B, not easier, since anyone with a Web browser > could surf over to the W3C and check it out themselves. If this forces > companies to be more aware of how their actions could affect > the way the > public perceives them, isn't this an unambiguously good thing for > everyone except for a handful of large and/or well-connected companies > (and in the aggregate, probably for them too)? <snip/> I have to disagree with this one point, and agree with Lauren on this issue, and it's mostly because of my lack of faith in the press. :-) We all know that you can make "facts" and "numbers" say just about anything you want, even when those facts and numbers are publicly available. If an issue comes up in a W3C working group, and a member from company A disagrees with a member from company B, the press can very easily write up a bunch of articles about how "Ol' A and B are at it again. Like cats and dogs, those two are.". Everyone will either a) Not bother to go and read the archives to verify it. Why bother? They're not allowed to LIE when they're writing news stories! b) Go to the archives and find out that, yes indeed, A and B did disagree on that point! Boy, those two can never get along! In either case, the net result Lauren described will probably ensue. Representatives from A and B can no longer feel free to work together <em>properly</em> in the W3C. <em>OTOH</em>, summary information is always good. Don't give out the minutes of the meetings, or make public all of the emails, because we can get the results above. But if the working groups could make things like the following public: "There was also [insert issue here] involved in making this decision. Some members of the WG thought [insert opinion on issue here], but others [insert other opinion on issue here]. In the end, we came to this decision because of [A REASON]." then we wouldn't get all of the backlash against the W3C that has come up in the last week on xml-dev. It's not important who thought what about those issues, and anyone who feels they need to know is either nosy or a reporter looking for a story. Just my 2 <Canadian>cents</Canadian>. David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Sep 7 19:25:36 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:44 2004 Subject: XML belongs to itself. (Re: an unfilled need) Message-ID: <003a01bef956$d951e840$09f96d8c@NT.JELLIFFE.COM.AU> From: Paul Tchistopolskii <paul@qub.com> >I disagree that XML is SGML The XML Spec says XML is SGML (see the abstract). The SGML standard says XML is SGML (see ISO 8879 Annex L). 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 wunder at infoseek.com Tue Sep 7 19:26:08 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:14:44 2004 Subject: XML Database/Repository with content indexing ? In-Reply-To: <199909061659.SAA05197@chimay.loria.fr> Message-ID: <3.0.5.32.19990907102333.00bae100@corp.infoseek.com> At 06:59 PM 9/6/99 +0200, Patrice Bonhomme wrote: > >I was wondering if it exists some XML database system that provide a content >(full text) indexing mechanism. This system should be able to answer to this >query : give me all documents that contains the expression "big blue" within >their "/TEI.2/teiHeader/*/title" element(s). Ultraseek Server is a full-text search engine that handles XML. If most of your searches are by experts, with complex boolean queries and arbitrary element context, Ultraseek Server is not the answer. But if you want to find "big blue" in title elements, search for phrases, handle plurals in English, French, and other languages (stemming), then Ultraseek Server is a good fit. See: http://software.infoseek.com/ wunder -- Walter R. Underwood wunder@infoseek.com wunder@best.com (home) http://software.infoseek.com/cce/ (my product) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lauren at sqwest.bc.ca Tue Sep 7 20:58:22 1999 From: lauren at sqwest.bc.ca (Lauren Wood) Date: Mon Jun 7 17:14:44 2004 Subject: confidentiality in W3C WGs In-Reply-To: <01BEF922.56308FE0@grappa.ito.tu-darmstadt.de> Message-ID: <199909071900.PAA25558@gw.sqwest.bc.ca> On 7 Sep 99, at 11:15, Ronald Bourret wrote: > I've only briefly been following this whole discussion, but I don't think > anybody has asked for names of who wanted one namespace and who wanted > three and who wanted the discussion to simply end because they were late > for a flight. I agree that technical reasons for why the spec is the way it is, and reasons for change, should be made public. Particularly when the issue is controversial, as this one is. 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 cowan at locke.ccil.org Tue Sep 7 23:07:03 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:44 2004 Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial) Message-ID: <199909072144.RAA08372@locke.ccil.org> This is version 0.1 of a proposed technical corrigendum to XML 1.0 to incorporate the new characters of Unicode 3.0 into the allowable sets used in XML Names. It presumes that XML should not remain limited to an obsolete version of the Unicode and ISO 10646 standards. The new scripts handled are: Cherokee, Ethiopic, Khmer, Mongolian, Myanmar, Ogham, Runic, Syriac, Thaana, Unified Canadian Aboriginal Syllabics, Yi. These lists of new characters were constructed by using the current Unicode 3.0 data file from the Unicode Consortium and applying the rules given in Appendix B to it. This version of the proposal does not yet incorporate information from the Unicode 3.0 properties list. (Unicode 3.0 is technically still in beta, but the character list has been frozen for months now.) New BaseChars (BNF rule 85): [#x01F6-#x01F9] /* new Latin letters */ | [#x0218-#x021F] | [#x0222-#x0233] | [#x02A9-#x02AD] /* new IPA Latin letters */ | #x03D7 /* new Greek letters */ | #x03DB | #x03DD | #x03DF | #x03E1 | #x0400 /* new Cyrillic letters */ | #x040D | #x0450 | #x045D | [#x048C-#x048F] | [#x04EC-#x04ED] | [#x06B8-#x06B9] /* new Arabic letters */ | #x06BF | #x06CF | [#x06FA-#x06FC] | #x0710 /* new Syriac script */ | [#x0712-#x072C] | [#x0780-#x07A5] /* new Thaana script */ | #x0950 /* OM letters */ | #x0AD0 | [#x0D85-#x0D96] /* new Sinhala script */ | [#x0D9A-#x0DB1] | [#x0DB3-#x0DBB] | #x0DBD | [#x0DC0-#x0DC6] | #x0E2F / * new Thai characters */ | #x0EAF | #x0F00 /* Tibetan OM */ | #x0F6A /* new Tibetan letters */ | [#x1000-#x1021] /* new Myanmar script */ | [#x1023-#x1027] | [#x1029-#x102A] | [#x1050-#x1055] | #x1101 /* Hangul jamo that are no longer compatibility characters */ | #x1104 | #x1108 | #x110A | #x110D | [#x1113-#x113B] | #x113D | #x113F | [#x1141-#x114B] | #x114D | #x114F | [#x1151-#x1153] | [#x1156-#x1158] | #x1162 | #x1164 | #x1166 | #x1168 | [#x116A-#x116C] | [#x116F-#x1171] | #x1174 | [#x1176-#x119D] | [#x119F-#x11A2] | [#x11A9-#x11AA] | [#x11AC-#x11AD] | [#x11B0-#x11B6] | #x11B9 | #x11BB | [#x11C3-#x11EA] | [#x11EC-#x11EF] | [#x11F1-#x11F8] | [#x1200-#x1206] /* new Ethiopic script */ | [#x1208-#x1246] | #x1248 | [#x124A-#x124D] | [#x1250-#x1256] | #x1258 | [#x125A-#x125D] | [#x1260-#x1286] | #x1288 | [#x128A-#x128D] | [#x1290-#x12AE] | #x12B0 | [#x12B2-#x12B5] | [#x12B8-#x12BE] | #x12C0 | [#x12C2-#x12C5] | [#x12C8-#x12CE] | [#x12D0-#x12D6] | [#x12D8-#x12EE] | [#x12F0-#x130E] | #x1310 | [#x1312-#x1315] | [#x1318-#x131E] | [#x1320-#x1346] | [#x1348-#x135A] | [#x13A0-#x13F4] /* new Cherokee script */ | [#x1401-#x166C] /* new Canadian Syllabics script */ | [#x166F-#x1676] | [#x1681-#x169A] /* new Ogham script */ | [#x16A0-#x16EA] /* new Runic script */ | [#x1780-#x17B3] /* new Khmer script */ | [#x1820-#x1842] /* new Mongolian script */ | [#x1844-#x1877] | [#x1880-#x18A8] | #x3006 /* Ideographic closing mark */ | [#x31A0-#x31B7] /* new Bopomofo letters */ | [#xA000-#xA48C] /* new Yi script */ IMHO none of these are controversial except perhaps the Hangul jamo. Formerly, some Hangul jamo had compatibility decompositions into sequences of other Hangul jamo. These decompositions have been removed from the Unicode Standard (actually in 2.1), so the jamo should now be allowed in XML names in accordance with the rules in Appendix B. New Ideographics (BNF rule 86): [#x3400-#x4DB5] /* CJK Ideograph Extension A */ New CombiningChars (BNF rule 87): [#x0346-#x034E] /* new IPA combining characters */ | #x0362 | [#x0488-#x0489] /* new Cyrillic combining characters */ | [#x0653-#x0655] /* new Arabic combining characters */ | #x0711 /* combining characters for new Syriac script */ | [#x0730-#x074A] | [#x07A6-#x07B0] /* combining characters for new Thaana script */ | [#x0D82-#x0D83] /* combining characters for new Sinhala script */ | #x0DCA | [#x0DCF-#x0DD4] | #x0DD6 | [#x0DD8-#x0DDF] | [#x0DF2-#x0DF3] | #x0F96 /* new Tibetan subjoined letters */ | [#x0FAE-#x0FB0] | #x0FB8 | [#x0FBA-#x0FBC] | #x0FC6 /* new Tibetan combining character */ | [#x102C-#x1032] /* combining characters for new Myanmar script */ | [#x1036-#x1039] | [#x1056-#x1059] | [#x17B4-#x17D3] /* combining characters for new Khmer script */ | #x18A9 /* combining character for new Mongolian script */ | [#x20E2-#x20E3] /* new general combining characters */ IMHO none of these are controversial except perhaps the #x20E2 and #x20E3, which are primarily intended for use with symbol characters, and therefore should perhaps be excluded as #x20DD-#x20E0 are. New Digits (BNF rule 88): [#x1040-#x1049] /* digits for new Myanmar script */ | [#x1369-#x1371] /* digits for new Ethiopic script */ | [#x17E0-#x17E9] /* digits for new Khmer script */ | [#x1810-#x1819] /* digits for new Mongolian script */ IMHO none of these will be controversial. New Extenders (BNF rule 89): #x02EE /* Modifier letter double apostrophe */ | #x1843 /* Modifier letter for new Mongolian script */ IMHO none of these will be controversial. In addition, the following characters no longer pass the tests given in Appendix B for valid name or name-start characters, but should remain legal in XML names for backward compatibility, and therefore should be explicitly enumerated in the corrigendum: 03D0;GREEK BETA SYMBOL 03D1;GREEK THETA SYMBOL 03D2;GREEK UPSILON WITH HOOK SYMBOL 03D5;GREEK PHI SYMBOL 03D6;GREEK PI SYMBOL 03F0;GREEK KAPPA SYMBOL 03F1;GREEK RHO SYMBOL 03F2;GREEK LUNATE SIGMA SYMBOL 0675;ARABIC LETTER HIGH HAMZA ALEF 0676;ARABIC LETTER HIGH HAMZA WAW 0677;ARABIC LETTER U WITH HAMZA ABOVE 0678;ARABIC LETTER HIGH HAMZA YEH 0E33;THAI CHARACTER SARA AM 0EB3;LAO VOWEL SIGN AM 0F77;TIBETAN VOWEL SIGN VOCALIC RR 0F79;TIBETAN VOWEL SIGN VOCALIC LL 1E9A;LATIN SMALL LETTER A WITH RIGHT HALF RING 212E;ESTIMATED SYMBOL ### -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Tue Sep 7 23:35:55 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:14:44 2004 Subject: NAMESPACES: expressing commonality or distinction Message-ID: <872567E5.0076DF35.00@d53mta03h.boulder.ibm.com> >and allow applications to match > >http://www.w3.org/HTML > >or > >http://www.w3.org/HTML/Strict > >or > >http://www.w3.org/HTML/Strict/1.0 > >depending on what they care about > >PRO: uses existing namespace mechanism >CON: would require modification to XPath, etc. > It would definitely have performance implications. It would no longer be possible to put elements/attrs into pools and identify them by a pool id that can be very efficiently checked and validated. I would be very concerned about it from that perspective. If an element is no longer uniquely identified by URI:Name, then it cannot be internally uniquely identified either. And I wonder if saying "its an application thing" is going to float either. Many apps will rely on tools to do a lot of work for them (otherwise XML will have missed a big part of the boat), so all those tools would have to understand this scheme or the apps that need this kind of functionality wouldn't be able to use them very effectively perhaps. But how would you efficiently implement this kind of thing in general purpose tools? For example, how would a DOM tree diff tool handle such a thing so that only meaningful diffs to the application at hand would show up? I'm sure it could be done, but the question is it worth going down this road or just forcing all apps that need to do this to have effectively their own validation mechanisms, attribute uniqueness checks, and so on? ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Tue Sep 7 23:47:21 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:14:44 2004 Subject: ATTN: Please comment on XHTML (before it's too late) Message-ID: <872567E5.0077E475.00@d53mta03h.boulder.ibm.com> >Adding three lines of code introduces the opportunity for three times >the bugs in a real application? I don't buy it. Looking for "HTML 4.0 >strict" OR "HTML 4.0 frameset" is no harder than looking for "UL" OR >"OL", if the software is set up right. > >And it is *just as necessary in the general case*. There will be tons of >code that needs to work the same across "similar" element types across >namespaces. > I said this elsewhere, so this is a little redundant but... I think its more complex than that. Its more than adding 3 lines of code. What if you want to validate the XHTML? That requires that the validation mechanism in all parsers now does partial URL matching? On which URLs does it do this? How will parsers, which use decl pools in which uniquely identified elements are given unique ids, deal with this? Otherwise, you push off validation, attribute uniqueness checks, attribute normalization, etc... off out of the parser which is what the parser was kind of designed for in the first place, right? If you think that those apps that need this functionality are happy to do it all themselves, then I have no problem with that. But I think that it deserves consideration that such documents could not meaningfully be dealt with by parsers that exist now, other than as non-validated, non-namespace aware documents pretty much. Is that really useful? And would we want to add all that complexity to parsers in order to deal with this issue, if its not sufficient to have the apps that need it handle all the issues? ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 8 00:20:59 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:44 2004 Subject: fixing (just) namespaces and validation Message-ID: <199909072223.SAA30088@hesketh.net> I brought this up earlier on a list of things that could be done to improve XML, and it keeps ringing in my ears. Namespaces and validation are incompatible in cases where the namespace prefix changes for whatever reason, because XML 1.0 will validate based only on the prefix. The Namespaces in XML Recommendation doesn't even provide a mechanism for telling DTDs what URI might be associated with a given prefix. James Clark provides an explanation of this at http://www.jclark.com/xml/xmlns.htm: >It would of course be very useful to have namespace-aware validation: >to be able to associate each URI used in a universal name with some >sort of schema (similar to a DTD) and be able to validate a document >using multiple such URIs with respect to the schemas for all of the URIs. >The XML Namespaces Recommendation does not provide this. The reason is >is that DTDs have many other problems and missing features in addition >to lack of namespace-awareness. So the plan is to come up with a new >schema mechanism that fixes the problems with DTDs and, as part of this, >provides namespace-awareness. This work is being done by the XML Schema WG. At the same time, Namespaces REC says: (end of Section 6, conformance) >Thus, unless the use of a validating processor has been specified, >there can be no assurance that the contents of attribute values >have been checked for conformance to this specification. Most people seem to have disregarded this notice, and use non-validating processors when they use namespaces, if indeed they do use namespaces. Those who validate simply pray that in these early days of XML processing no one will have gotten around to changing a prefix for whatever reason. It seems like DTDs will be here for a while, and it doesn't seem like fixing this problem is difficult. The PI from the 5/18 draft, which was meant for documents, would serve just as well in DTDs. It could provide a simple mapping for prefixes as used in the DTD to the namespace URI, allowing processors to validate against both the namespace URI and the local part, rather than simply the element or attribute name. For example: (Yes, I changed the colon to a dash.) <?xml-namespace ns="http://www.simonstl.com/ns/1999/xpdl" prefix="xpdl"?> When it appeared in the DTD, this would tell a validating processor that the prefix xpdl maps to http://www.simonstl.com/ns/1999/xpdl. If the processor then encountered elements with a namespace URI of http://www.simonstl.com/ns/1999/xpdl, it could validate them on the basis of that URI and the local part even if the xpdl prefix had disappeared. It seems very simple, even potentially worthwhile. I don't think that it would give parser builders enormous headaches, and it would take away a lot of the technical ammunition of the anti-namespaces crowd. Then we could discuss the more painful issues of 'what does it mean?' without extra noise about how weakly it's been implemented, and we wouldn't have to wait as impatiently for the Schema WG to finish their labors. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 roddey at us.ibm.com Wed Sep 8 00:40:22 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:14:44 2004 Subject: why distinctions within XHTML? Message-ID: <872567E5.007CCC3D.00@d53mta03h.boulder.ibm.com> >Somebody did the basic math in a comment: three variants of XHTML will >very quickly add an order of magnitude to the complexity of the systems >built with it. That's a deterrent to the use of XHTML, and discards the >simplification that's long been at the core of the XML movement. > Does not the 'X' in XHTML pretty much mean that technically there should be no 'non-strict' version? I mean if its HTML, its HTML. But, if its XML, then it needs to be well formed XML. I think that its going a little too far in the direction of backwards compatability to do anything else. All parsers out there now would reject non-strict HTML as not well formed anyway, right? I'm assuming that non-strict (or traditional, or classic or whatever it is :-) means you don't need a </p> for every <p> and so on, right? So just making it really have to be well formed XML (which would avoid changing all the parsers in the world just to deal with this) would get rid of one of the DTDs right off the back, wouldn't it? Maybe this was a totally ignorant statement (I've been off writing real code and haven't been following this debate) or maybe its been said 20 times already and sorry if so, but it makes perfect sense to me that there should be no XHTML which is not really XML. That still leaves the issues of how to progress standards, but it would remove one big hair ball from our respective gullets :-) ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Wed Sep 8 00:53:06 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:14:44 2004 Subject: How much extra code for multiple Namespaces? Message-ID: <872567E5.007DF412.00@d53mta03h.boulder.ibm.com> >From: <schen@falconwing.com> >If you have such a mechanism then it should be fairly trivial to map all >three XHTML namespaces into one, if as you say 99% of applications will >treat them all the same anyway. Then it is nowhere near the extra amount >of code that you claim? If you could, pls give an example! > The problem is that this is just one instance of this situation. If you allow it here, will you make this the one and only special dispensation for it? If so, then maybe all apps that deal with HTML can deal with this one case specially and perhaps its no big deal (to me anyway, since I just write parsers :-) But, if its not, how do you generalize it? Do you fill your XML processor with lists of equivalent URLs, and tell it when and where they are really equivalent? Otherwise, there is no way for a parser to validate such documents or even confirm that it meets XML 1.0 rules (such as no reuse of the same attribute in an element.) And, even if you do this, you've put a big new burden on all processors to support this kind of functionality. It will mean a performance hit because there is no longer a unique string (uri-name, probably put into a pool and turned into a single unique number) which represents an element or attribute. It would be a significant change required in processors to handle this kind of thing. ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Wed Sep 8 01:03:15 1999 From: roddey at us.ibm.com (roddey@us.ibm.com) Date: Mon Jun 7 17:14:44 2004 Subject: why distinctions within XHTML? Message-ID: <872567E5.007EE110.00@d53mta03h.boulder.ibm.com> >I agree with Dave. The more I look, the more I am convinced that >the W3C is not the right standards body to deal with XML, which is being >employed in many arenas that have absolutely nothing to do with the web. In >fact, if/when the true potential of XML is realized, the web will be a minor >player in that. SGML is/was not the native language of the web. HTML was >derived for that purpose. XML is/has the potential to be used for much more >then internet publishing of information. The web has benefited from many >technological contributions, many of which predate the web by a couple of >decades, and most of the technology that goes into it is not at all web >specific (connection oriented stream TCP communications, MIME, >request/response, etc.). To think that XML is a web-only or even a >web-mostly language is to miss the boat so far as to not even notice the >ripples. > An obvious question to ask though is that, once XML has been stretched to deal with all these other issues, will it be a reasonable mechanism to use on the web, which will still need such a mechanism. Part of the problem with XML, IMHO, is that too many people want it to do too many things and the simplicity that made it attractive is going fast. If it were explicitly turned into a 'its not just for breakfast anymore' kind of standard, I think that its usefulness in the web and its simplicity would just get smothered that much faster. I think its fine for anyone to use it who needs to. But, there has to be some focus as to what its intended applications are and things shouldn't be done to it that make it difficult to use in those intended applications. Just my opinion of course... ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Wed Sep 8 01:02:19 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:44 2004 Subject: why distinctions within XHTML? In-Reply-To: <872567E5.007CCC3D.00@d53mta03h.boulder.ibm.com> Message-ID: <199909072304.TAA08656@earth.isni.net> At 04:43 PM 9/7/99 -0600, roddey@us.ibm.com wrote: > > > >>Somebody did the basic math in a comment: three variants of XHTML will >>very quickly add an order of magnitude to the complexity of the systems >>built with it. That's a deterrent to the use of XHTML, and discards the >>simplification that's long been at the core of the XML movement. >> > >Does not the 'X' in XHTML pretty much mean that technically there should be no >'non-strict' version? I mean if its HTML, its HTML. But, if its XML, then it >needs to be well formed XML. Nothing in the transitional and frameset flavors of XHTML 1.0 equate to not being well formed. If I correctly understand that to be your concern, it appears to not be an issue. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Sep 8 06:47:39 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:44 2004 Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial) In-Reply-To: <37D59BFC.4B37BFFC@pacbell.net> from "David Brownell" at Sep 7, 99 04:13:00 pm Message-ID: <199909080525.BAA26575@locke.ccil.org> David Brownell scripsit: > Are you saying the proposal is that this should be an erratum > to the "XML 1.0" specification? Or instead that this should > be "XML 1.1" ? This is a process question that I am not equipped to answer, though someday I may be so equipped. :-) The overall result is that certain documents which were not WF before become WF; no WF documents become not WF. It is an upward compatible extension of XML 1.0:1998. I emphasize that this document has, at present, nothing to do with the W3C, though I would be pleased if it did someday. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 8 06:44:49 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:45 2004 Subject: why distinctions within XHTML? In-Reply-To: <872567E5.007CCC3D.00@d53mta03h.boulder.ibm.com> from "roddey@us.ibm.com" at Sep 7, 99 04:43:05 pm Message-ID: <199909080522.BAA26525@locke.ccil.org> roddey@us.ibm.com scripsit: > Does not the 'X' in XHTML pretty much mean that technically there should be no > 'non-strict' version? I mean if its HTML, its HTML. But, if its XML, then it > needs to be well formed XML. I think that its going a little too far in the > direction of backwards compatability to do anything else. All parsers out there > now would reject non-strict HTML as not well formed anyway, right? I'm assuming > that non-strict (or traditional, or classic or whatever it is :-) means you > don't need a </p> for every <p> and so on, right? No. "Strict" means "guaranteed not to have deprecated element types and attributes" in the HTML context; it has nothing to do with SGML vs. XML. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Wed Sep 8 10:46:47 1999 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:14:45 2004 Subject: [XT] XSL output question Message-ID: <199909080849.KAA08564@chimay.loria.fr> <Hi/> I have an XML file that is encoding both with ISO-8859-1 and ISO-8859-2 characters using external entities declaration (ISOlat1.pen and ISOlat2.pen). 1/ What is the value of the 'encoding' attribute within the XML declaration ? ISO-8859-1 ? ISO-8859-2 ? None ? 2/ How could we generate an HTML file encoding in UTF-8 using an XSL stylesheet from this XML file ? We are currently using XT 19990822. Here is the declaration of the XML file : <?xml version="1.0" standalone="yes"?> <!DOCTYPE TEI.2 [ <!ENTITY % ISOlat1 SYSTEM "/local/led/share/dtd/pen/ISOlat1.pen"> %ISOlat1; <!ENTITY % ISOlat2 SYSTEM "/local/led/share/dtd/pen/ISOlat2.pen"> %ISOlat2; ]> A sample of our data : <hi rend="IT" TEIform="hi">Slavnost athénských Thráků</hi> The result with a very simple XSL stylesheet : Slavnost athénských Thrák? I am also looking for an XSL/XSLT tutorial compatible with the last XSLT WD. Thanks for any help, Pat. -- ============================================================== bonhomme@loria.fr Tel : 03 83 59 30 52 / 06 11 34 03 85 http://www.loria.fr/~bonhomme Office : B.228 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide ============================================================== -- ============================================================== bonhomme@loria.fr Tel : 03 83 59 30 52 / 06 11 34 03 85 http://www.loria.fr/~bonhomme Office : B.228 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Sep 8 11:42:40 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:14:45 2004 Subject: fixing (just) namespaces and validation References: <199909072223.SAA30088@hesketh.net> Message-ID: <37D6301C.17055AB7@mecomnet.de> Simon St.Laurent wrote: > > Namespaces and validation are incompatible in cases where the namespace > prefix changes for whatever reason, this claim is not universaly true. while there are dtd's for which it holds (those with ambiguous prefixes are those with declarations with identical prefixed names and no directly specified namespace binding.), this does not hold for all dtd's ... > > For example: (Yes, I changed the colon to a dash.) > <?xml-namespace ns="http://www.simonstl.com/ns/1999/xpdl" prefix="xpdl"?> > > When it appeared in the DTD, this would tell a validating processor that > the prefix xpdl maps to http://www.simonstl.com/ns/1999/xpdl. If the > processor then encountered elements with a namespace URI of > http://www.simonstl.com/ns/1999/xpdl, it could validate them on the basis > of that URI and the local part even if the xpdl prefix had disappeared. i suspect that this instruction is not necessary. it does work (to wit the parser which is available with the cl-http server supports an instruction of this form), but it is not necessary in those cases where it is possible to include it in order to resolve otherwise ambiguous names, it would also be possible to modify the prefixes so that they are not ambiguous. in cases where the bindings are not ambiguous (see above), it is possible to infer the necessary bindings and resolve apparent ambiguities. the above mentioned parser does this for directly specified namespace bindings. it would also be possible to infer indirectly specified bindings through the respective content models ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From davidc at nag.co.uk Wed Sep 8 12:37:58 1999 From: davidc at nag.co.uk (David Carlisle) Date: Mon Jun 7 17:14:45 2004 Subject: fixing (just) namespaces and validation Message-ID: <199909081037.LAA21158@nag.co.uk> James anderson wrote > Simon St.Laurent wrote: > > > > Namespaces and validation are incompatible in cases where the namespace > > prefix changes for whatever reason, > > this claim is not universaly true. while there are dtd's for which it holds > (those with ambiguous prefixes are those with declarations with identical > prefixed names and no directly specified namespace binding.), this does not > hold for all dtd's Surely _all_ DTDs do have this problem with the namespace REC. The documents <foo:x xmlns:foo="http://here"> </foo:x> and <bar:x xmlns:bar="http://here"> </bar:x> are fully equivalent according to XML Namespace REC, but it is not possible to write a DTD such that you can add <!DOCTYPE foo:x SYSTEM "x.dtd"> <foo:x xmlns:foo="http://here"> </foo:x> and <!DOCTYPE bar:x SYSTEM "x.dtd"> <bar:x xmlns:bar="http://here"> </bar:x> Well, you could write a DTD that worked for any finite set of prefixes, just by duplicating all the declarations, but you can not write one that works in general. So, to validate with namespaces, you either have to pre-process the document instance to normalise the prefixes to the prefix used in the DTD, or you have to invent a new declaration in the DTD that says `this DTD uses prefix foo: but a documenent instance may use any prefix, so long as is bound to the namespace "http://here"' This is (I assume) the intention of the PI in Simon's posting. David xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 8 13:04:31 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:45 2004 Subject: fixing (just) namespaces and validation In-Reply-To: <199909081037.LAA21158@nag.co.uk> References: <199909081037.LAA21158@nag.co.uk> Message-ID: <14294.16724.994022.557375@localhost.localdomain> David Carlisle writes: > Surely _all_ DTDs do have this problem with the namespace REC. > > The documents > > <foo:x xmlns:foo="http://here"> > </foo:x> > > > and > > <bar:x xmlns:bar="http://here"> > </bar:x> > > are fully equivalent according to XML Namespace REC. That's because they're different layers. Think of RDF; assuming appropriate Namespace declarations, these are both equivalent in the RDF layer, but not in the XML 1.0 layer: <rdf:Description about="http://www.foo.com/123"> <rdf:type resource="http://www.foo.com/classes/Thing"/> <dc:title>The Foo thing</dc:title> </rdf:Description> and <foo:Thing about="http://www.foo.com/123" dc:title="The Foo thing"/> DTD validation is applied to a very low-level layer of XML processing (essentially, the DOM/SAX layer); Namespaces is concerned with a higher layer, and RDF, with a higher layer still. There is usually a many-to-one relationship as you go up to more abstract layers: many different sequences of characters can be interpreted as the same XML document, many different XML documents can provide the same Namespaces (or Architectural Forms) view, many different Namespaces views can provide the same RDF view, etc. The point is that a single sequence of characters cannot represent two different XML documents, nor can a single XML document represent two different Namespace views, nor can a single Namepsace view represent two different RDF views. 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 davidc at nag.co.uk Wed Sep 8 14:08:56 1999 From: davidc at nag.co.uk (David Carlisle) Date: Mon Jun 7 17:14:45 2004 Subject: fixing (just) namespaces and validation In-Reply-To: message from David Carlisle on 8 Sep 1999 11:37:34 +0100 Message-ID: <199909081208.NAA17410@nag.co.uk> Me> Surely _all_ DTDs do have this problem with the namespace REC. David Megginson> That's because they're different layers. Yes, agreed, it wasn't really a criticism. The fact remains that at the current time the `problem' is that there is no standard way of getting from one layer to the other. That is, if I have a namespace aware application that really doesn't mind what prefix is used in a document instance, there is no convenient standard way of supplying a DTD against which a set of documents to be used with that application may be validated. Of course it's easy enough to _do_ the validation, you just need to specify (for example) an XSL transform that normalises the prefix to match the DTD or just build this knowledge in to an extended XML parser but there is nothing like the following that works in a cross platform way <!DOCTYPE this instance uses document element foo:x but validate against this dtd which declares element x SYSTEM "x.dtd"> <foo:x xmlns:foo=...> ... David xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 8 14:29:57 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:45 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <199909081208.NAA17410@nag.co.uk> References: <199909081208.NAA17410@nag.co.uk> Message-ID: <14294.21817.614899.758420@localhost.localdomain> David Carlisle writes: > Yes, agreed, it wasn't really a criticism. The fact remains that at > the current time the `problem' is that there is no standard way of > getting from one layer to the other. Sure there is -- at least, the Namespaces REC defines pretty clearly what Namespace declarations and prefixes do. > That is, if I have a namespace aware application that really > doesn't mind what prefix is used in a document instance, there is > no convenient standard way of supplying a DTD against which a set > of documents to be used with that application may be validated. But that's not a problem of getting from one layer to another; it's simply a problem of applying an operation to a layer. Here's one layered view: Layer 1: octets Validate with: (custom code) Layer 2: Unicode characters Validate with: (regular expression) Layer 3: XML Validate with: DTD Layer 4: Namespaces Validate with: (XML Schemas, eventually) Layer 5: RDF Validate with: RDF schema Layer 6: Application Validate with: (local business rules) Here's another layered view: Layer 1: octets Validate with: (custom code) Layer 2: Unicode characters Validate with: (regular expression) Layer 3: XML Validate with: DTD Layer 4: Namespaces Validate with: (XML Schemas, eventually) Layer 5: XHTML Validate with: (built-in XHTML processing rules) Layer 6: Application Validate with: (local business rules) My applications have no problem at all getting from layer 3 to layer 4 in either example, because the path is fairly well defined; it just happens that there is also a convenient schema formats for applying structural validation or guided authoring to layer 3, but that's a separate operation applied to the layer, not part of the layer itself. Many layers do not have a standard validation technique yet. 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 smohr at voicenet.com Wed Sep 8 15:00:11 1999 From: smohr at voicenet.com (Stephen T. Mohr) Date: Mon Jun 7 17:14:45 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) References: <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> Message-ID: <009c01bef9fa$7ad0d840$e9d9f2cc@omicron.com> A key sticking point is layer 4. Until XML Schemas are a recommendation, we have no standard way to validate XML containing namespace references. Several proprietary or early implementation ways, yes, but none standard. It is a shame the namespaces rec went out without going back and revising the core XML Rec, or going forward and adding Schemas. ----- Original Message ----- From: David Megginson <david@megginson.com> To: <xml-dev@ic.ac.uk> Sent: Wednesday, 8 September 1999 08:31 AM Subject: Layers, again (was Re: fixing (just) namespaces and validation) > David Carlisle writes: > > > Yes, agreed, it wasn't really a criticism. The fact remains that at > > the current time the `problem' is that there is no standard way of > > getting from one layer to the other. > > Sure there is -- at least, the Namespaces REC defines pretty clearly > what Namespace declarations and prefixes do. > > > That is, if I have a namespace aware application that really > > doesn't mind what prefix is used in a document instance, there is > > no convenient standard way of supplying a DTD against which a set > > of documents to be used with that application may be validated. > > But that's not a problem of getting from one layer to another; it's > simply a problem of applying an operation to a layer. Here's one > layered view: > > > Layer 1: octets > Validate with: (custom code) > > Layer 2: Unicode characters > Validate with: (regular expression) > > Layer 3: XML > Validate with: DTD > > Layer 4: Namespaces > Validate with: (XML Schemas, eventually) > > Layer 5: RDF > Validate with: RDF schema > > Layer 6: Application > Validate with: (local business rules) > > > Here's another layered view: > > > Layer 1: octets > Validate with: (custom code) > > Layer 2: Unicode characters > Validate with: (regular expression) > > Layer 3: XML > Validate with: DTD > > Layer 4: Namespaces > Validate with: (XML Schemas, eventually) > > Layer 5: XHTML > Validate with: (built-in XHTML processing rules) > > Layer 6: Application > Validate with: (local business rules) > > > My applications have no problem at all getting from layer 3 to layer 4 > in either example, because the path is fairly well defined; it just > happens that there is also a convenient schema formats for applying > structural validation or guided authoring to layer 3, but that's a > separate operation applied to the layer, not part of the layer > itself. Many layers do not have a standard validation technique yet. > > > All the best, > > > David > > -- > David Megginson david@megginson.com > http://www.megginson.com/ > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 8 15:42:47 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:45 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <009c01bef9fa$7ad0d840$e9d9f2cc@omicron.com> References: <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <009c01bef9fa$7ad0d840$e9d9f2cc@omicron.com> Message-ID: <14294.26532.335111.817603@localhost.localdomain> Stephen T. Mohr writes: > A key sticking point is layer 4. Until XML Schemas are a recommendation, we > have no standard way to validate XML containing namespace references. > Several proprietary or early implementation ways, yes, but none standard. > It is a shame the namespaces rec went out without going back and revising > the core XML Rec, or going forward and adding Schemas. That is true -- several of the layers are missing standard validation mechanisms. That has nothing to do with movement between the layers, and won't inhibit most kinds of processing, but it is still a useful thing to have. Note that several of layers in my original chart are missing standard validation mechanisms. If you're exchanging mainly serialized objects, you might want to consider RDF schemas, which are admirably simple. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Sep 8 17:04:20 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:45 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <14294.21817.614899.758420@localhost.localdomain> References: <199909081208.NAA17410@nag.co.uk> <199909081208.NAA17410@nag.co.uk> Message-ID: <4.0.1.19990908091744.01115340@216.27.10.33> Amazing what proposing to fix namespaces on this list can bring out. David's presented an astounding set of assumptions that I've never heard voiced so explicitly before. In many ways, however, I think these assumptions underlie many of the _problems_ in XML, not the promise of XML. This set of assumptions also contradicts the quote I began my proposal with from James Clark's XML Namespaces document (http://www.jclark.com/xml/xmlns.htm), which complains about missing parts in DTDs rather than any layering problems. It also doesn't match the Note Web Architecture: Extensible Languages (http://www.w3.org/TR/NOTE-webarch-extlang), and only sort of fits the picture (not so much the text) in the Note RDF Architecture (http://www.w3.org/TR/NOTE-rdfarch). At 08:31 AM 9/8/99 -0400, David Megginson wrote: >David Carlisle writes: > > > Yes, agreed, it wasn't really a criticism. The fact remains that at > > the current time the `problem' is that there is no standard way of > > getting from one layer to the other. > >Sure there is -- at least, the Namespaces REC defines pretty clearly >what Namespace declarations and prefixes do. I think you've read considerably more into the Namespaces REC than I as far as _when_ that 'namespace doing' takes place. While it does discuss the appearance of qualified names in DTDs and makes certain comments regarding the non-reliability of attribute defaulting in non-validating parsers, it doesn't go further. It doesn't specify explicitly that Namespace processing is performed as a layer between the application and the parser, or that all parser operation must be completed before namespace processing begins. More on this below, as we get into the details of this 'layering'. > > That is, if I have a namespace aware application that really > > doesn't mind what prefix is used in a document instance, there is > > no convenient standard way of supplying a DTD against which a set > > of documents to be used with that application may be validated. > >But that's not a problem of getting from one layer to another; it's >simply a problem of applying an operation to a layer. Here's one >layered view: > > >Layer 1: octets >Validate with: (custom code) > >Layer 2: Unicode characters >Validate with: (regular expression) > >Layer 3: XML >Validate with: DTD > >Layer 4: Namespaces >Validate with: (XML Schemas, eventually) > >Layer 5: RDF >Validate with: RDF schema > >Layer 6: Application >Validate with: (local business rules) > > >Here's another layered view: > > >Layer 1: octets >Validate with: (custom code) > >Layer 2: Unicode characters >Validate with: (regular expression) > >Layer 3: XML >Validate with: DTD > >Layer 4: Namespaces >Validate with: (XML Schemas, eventually) > >Layer 5: XHTML >Validate with: (built-in XHTML processing rules) > >Layer 6: Application >Validate with: (local business rules) > > >My applications have no problem at all getting from layer 3 to layer 4 >in either example, because the path is fairly well defined; it just >happens that there is also a convenient schema formats for applying >structural validation or guided authoring to layer 3, but that's a >separate operation applied to the layer, not part of the layer >itself. Many layers do not have a standard validation technique yet. The problem in both of these examples is that you treat XML itself as monolithic, and DTD validation as a tool that can only be used at the time of parsing. As a result, we have multiple levels of checking that have to be redundant if they're done at all. Check against schemas, DTDs, _and_ RDF? And then throw application rules on top of that? Forget it. These 'layers' are pretty much a guarantee that developers either need to make an investment in large quantities of aspirin - or pick one tool and stick to it. If I thought that schemas would be here soon, or that RDF really was the answer to all of these, I wouldn't be pushing on DTD validation. DTDs do seem to be a good answer - in the short term for many projects, in the long term for a subset of projects - to the need for structural checking. It doesn't seem that ridiculous to want to 'validate' the results of a transformation (generated via XSL or the DOM) or to want to 'validate' a document against a DTD structure while taking into account namespaces. Because XML 1.0 was written so that everything from character checking to entity replacement to attribute defaulting to structural inspections (DTD and otherwise) are all performed by one monolithic 'parser', we haven't been able to describe XML processors with any level of granularity. When I talk about layers (for instance, in http://www.simonstl.com/articles/layering/layered.htm), it's layering for the sake of breaking things into the smallest usable components, not for the sake of piling on more and more mostly redundant processing. Your layer 3 is way too thick. If treat validation as a process with its own life, outside of the Rube Goldberg machine known as an XML processor, we might be able to solve a lot of problems that currently look very difficult much more simply. Namespaces included. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matthew at praxis.cz Wed Sep 8 17:02:55 1999 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:14:45 2004 Subject: What XML-dev can do (was Re: an unfilled need) References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> <37D3F74D.AA84B8FF@praxis.cz> <199909071317.JAA05607@hesketh.net> Message-ID: <37D67B08.2B269E86@praxis.cz> "Simon St.Laurent" wrote: <snip> > It doesn't seem sensible, however, to be afraid of the W3C. There are a > lot of projects they don't seem interested in working on, and there are > even more cases where people need standards (like the namespaces issues Len > noted above) that go beyond what the W3C is currently providing. <snip> I really like the idea of addressing some of these issues in this forum in a way complementary to the work done by the W3C, which of course is extremely valuable. In this context I have a question: how many Java developers are reading this mail and would be potentially interested in participating in an open-source project centered around Java/XML? Basically we are considering releasing some of our internal code as OSS and it would be great to get a feeling for how many qualified people would at least consider investing time in such a project. As someone pointed out when this list started discussing XSchema, the SAX project was successful because there were commitments from the very start from application developers to implement the interface when completed. A concrete implementation of a extensible architecture for XML processing (Im being intentionally vague) would presumably be a great help in testing new ideas and even creating usable code, be if for alternative schema approaches, namespace-aware validation or whatever. But we only want to do this if there is sufficient potential interest in the developer community. If anyone wants more details, please send me a private mail and I will send you a short summary of our current system and our future plans for it. Thanks in advance, Matthew PS: My new Czech keyboard does not appear to have an apostrophe. Sorry. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 8 17:19:40 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:45 2004 Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial) In-Reply-To: <37D5ECB2.9794EBD5@jclark.com> from "James Clark" at Sep 8, 99 11:57:23 am Message-ID: <199909081557.LAA02460@locke.ccil.org> James Clark scripsit: > > 0E33;THAI CHARACTER SARA AM > > That's very strange. SARA AM certainly needs to be allowed in names. It's a funny story. In earlier versions of Unicode, SARA AM was treated as canonically equivalent to NIKHAHIT followed by SARA AA; that is, Unicode-conformant processes were not supposed to distinguish between them. In the latest version, this equivalence has been downgraded to a mere compatibility equivalence. As a result, SARA AM has become a "compatibility character" and as such disallowed by the Appendix B rules. > > 0EB3;LAO VOWEL SIGN AM The same story applies here: the VOWEL SIGN AM is now a compatibility equivalent of NIGGAHITA followed by VOWEL SIGN AA. In any event, whatever XML worked before has to work now, so I am merely proposing a statement that THAI CHARACTER SARA AM and LAO VOWEL SIGN AM *are* legal in XML names, despite their status as Unicode compatibility characters. In any case their legality in XML *text* is of course not affected. If anyone thinks something is desperately broken here, please contact unicode@unicode.org right away. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 8 17:32:07 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:45 2004 Subject: ANN: XML and Databases article Message-ID: <01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de> Steven R. Newcomb wrote: > I learned some interesting things from this article, for which I'm > grateful. Recommended reading! Thanks! > I was disappointed that the grove paradigm > (http://www.prescod.net/groves/shorttut/) was never mentioned, nor was > GroveMinder (http://www.techno.com). The grove paradigm offers an > ISO-defined meta-DOM to all notations, including XML. I've read Paul's tutorial and the GroveMinder summary on the Web, so let's see if I've got this straight. A grove is basically a property set, broken down into classes, each of which has properties. There are probably relationships between those classes. For example, a grove for XML could have classes for elements, attributes, entities, and so on, where the element class points to the attribute class. A grove for a relational database would have classes for tables, columns, etc., where the table class points to the column class. (In this sense, the XML information set has much in common with groves, as it is a property set. Similarly, the DOM could be viewed as an API for a grove. The XML information set is not a grove because [why? The only reason I can think of is that it is not been expressed in grove notation]. The DOM is not an API for a grove because it's a bit wishy-washy in places -- for example, four characters of PCDATA could be one node or four, so it's not built on a rigid enough data model.) The nice thing about groves is that all groves, regardless of what they are built on, have certain commonalities, such as addressability, so you can perform certain common functions with them. GroveMinder is generic grove middleware. It has plug-ins, called Minders (I think of them as drivers), that can build groves over different property sets. For example, there is one Minder for SGML/XML documents and a different Minder for relational databases. (There can actually be different property sets for a "type" of data. For example, one property set for XML might include entities and another might not, specifying that each entity is replaced by its value. A different Minder is needed for each property set.) One thing GroveMinder can do is store a grove in its own database. (Note that this is separate from the database addressed by the relational database Minder -- it has a structure designed to store groves.) Thus, GroveMinder can store an XML document in a database as a grove and is what I, in my article, called a content management systems. That is, it can store and retrieve an XML document as a document. Some questions: 1) Is it possible to combine groves of different types? For example, can I take a grove representing a table in a relational database and stuff it into a grove for an XML document, for example as the content of an element? If so, does the table grove retain its table-ness, or is it converted to one or more XML elements? Both cases seem reasonable, although the latter would presumably require a special converter. If the latter case is true, then GroveMinder might also fit what I call data transfer middleware, depending on how the conversion is done. 2) Are groves themselves relevant at a high level in a discussion of XML and databases? It strikes me that, like SAX and the DOM, they are a useful tool in implementing software that stores/retrieves XML documents (or data from those documents) in a database but are not directly relevant to the discussion itself. Instead, they are most relevant to the user in that they are likely to weigh heavily in the feature set exposed by a content management system or (possibly) data transfer system. 3) This isn't directly related to XML/databases, but what other common functionality do all groves have? For example, can I write an application that navigates groves, regardless of their source (I think the answer is yes)? Can I combine groves of different types or convert painlessly -- that is, without writing any additional code -- from one type to another (I think the answer is no -- additional code is needed)? Can I hyperlink from one grove to another (I think the answer is yes)? And so on. -- Ron xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 8 19:01:01 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:45 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <4.0.1.19990908091744.01115340@216.27.10.33> References: <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <4.0.1.19990908091744.01115340@216.27.10.33> Message-ID: <14294.36560.725917.191918@localhost.localdomain> Simon St.Laurent writes: > At 08:31 AM 9/8/99 -0400, David Megginson wrote: > >David Carlisle writes: > > > > > Yes, agreed, it wasn't really a criticism. The fact remains > > > that at the current time the `problem' is that there is no > > > standard way of getting from one layer to the other. > > > >Sure there is -- at least, the Namespaces REC defines pretty clearly > >what Namespace declarations and prefixes do. > > I think you've read considerably more into the Namespaces REC than > I as far as _when_ that 'namespace doing' takes place. Oops! Note that I didn't say "what Namespaces do" -- that's application-specific. I referred only to the parts of XML 1.0 syntax that act as links to the Namespace layer (Namespace declarations and prefixes). So, for "what Namespace declarations and prefixes do" try reading "how expanded names are constructed from Namespace declarations and prefixes". In other words, given any XML 1.0 document, the XML Namespaces REC precisely and unambiguously specifies how to determine the expanded name of every element and attribute in the document. Thats *all* that you need to move from the XML 1.0 layer to the Namespaces layer during processing. > While it does discuss the appearance of qualified names in DTDs and > makes certain comments regarding the non-reliability of attribute > defaulting in non-validating parsers, it doesn't go further. It > doesn't specify explicitly that Namespace processing is performed > as a layer between the application and the parser, or that all > parser operation must be completed before namespace processing > begins. But there's no reason that the parser has to finish processing the XML 1.0 layer before it starts evaluating the Namespace layer -- that's a matter of physical implementation, and the layers belong to a logical model (jumping layers is always wrong in logical models, but it often makes sense in implementations: note how many routers know about HTTP, even though they're technically dealing with the IP layer). In the SAX Namespaces filter for DATAX, for example, the Namespace processing is done on the fly. More seriously, neither XML nor Namespaces currently has a standardized processing model of any sort, and I'm still trying to decide whether I think they should. The data models and APIs that we have specify only what should be available *after* processing; they don't say how we get there. > The problem in both of these examples is that you treat XML itself > as monolithic, and DTD validation as a tool that can only be used > at the time of parsing. As a result, we have multiple levels of > checking that have to be redundant if they're done at all. Check > against schemas, DTDs, _and_ RDF? And then throw application rules > on top of that? Forget it. No, you have the choice of applying validation only at the levels that are important to you: if you're producing XHTML for display in legacy browsers, then you might need to validate the character layer with regular expressions to ensure that empty-element tags always have a space before the closing delimiter (<hr />, not <hr/>). You can apply validation to *any* layer of processing, from the raw bytes to the final application. Choosing where to validate is an architectural decision, not a standards one. It just happens that some of the layers do have shared specs that make validation easier (regular expressions, DTDs, and RDF schemas), while others do not, yet. > These 'layers' are pretty much a guarantee that developers either > need to make an investment in large quantities of aspirin - or pick > one tool and stick to it. No, that's wrong -- layered approaches like these have proven themselves over and over (the Internet is only the most famous example). Do you consider it redundant that both TCP and HTTP perform different kinds of validity checks? > If I thought that schemas would be here soon, or that RDF really > was the answer to all of these, I wouldn't be pushing on DTD > validation. But you need all of these and more. Any higher-level layer will have its own constraints that cannot (and should not) be expressed in a generic XML structural schema language: read the TEI spec (for example) to see how complex these constraints can be. DTDs do two things very well -- they let you validate the surface structure of an XML 1.0 document, and they provide production rules to help with the creation of XML 1.0 documents. They could be extended to do lots of other kinds of things, but I hardly see the point (ISO 8859-1 could have been extended to include markup, for example, but it would have been a bad idea). > DTDs do seem to be a good answer - in the short term for many > projects, in the long term for a subset of projects - to the need > for structural checking. It doesn't seem that ridiculous to want > to 'validate' the results of a transformation (generated via XSL or > the DOM) or to want to 'validate' a document against a DTD > structure while taking into account namespaces. Not at all, but you need something other than DTDs to do that, at least for now. > Because XML 1.0 was written so that everything from character > checking to entity replacement to attribute defaulting to > structural inspections (DTD and otherwise) are all performed by one > monolithic 'parser', we haven't been able to describe XML > processors with any level of granularity. When I talk about layers > (for instance, in > http://www.simonstl.com/articles/layering/layered.htm), it's > layering for the sake of breaking things into the smallest usable > components, not for the sake of piling on more and more mostly > redundant processing. Your layer 3 is way too thick. All of the layers are way too thick -- that's the joy of a high-level logical model. I can break any one of them down into dozens of smaller layers; in fact, the application layer will often be much more complicated than the parser layer, simply because useful applications generally do complicated things. > If treat validation as a process with its own life, outside of the > Rube Goldberg machine known as an XML processor, we might be able > to solve a lot of problems that currently look very difficult much > more simply. Namespaces included. It's wonderful to see that we end up agreeing. Validation is a much bigger problem than DTDS -- it's best to think of DTDs as a small bonus (you can perform some types of structural validation on the XML layer right now basically for free) rather than a liability, and to think of the greater validation problem as still unsolved in the general case. That's not because the XML Schema committee members are stupid or obstructionist, but simply because validation in the general case is a *very* hard problem. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Dapeng.Wang at Dresdner-Bank.com Wed Sep 8 19:01:50 1999 From: Dapeng.Wang at Dresdner-Bank.com (Wang, Dapeng) Date: Mon Jun 7 17:14:45 2004 Subject: Is it possible to overwrite global variables? Message-ID: <F39260401A4FD311BB6700805FA7821B49D427@FFZ00ZAD> Hi, Sometimes I feel that I need to overwrite the value of a globally declared variable. Is that possible? I think it is very pratical to save some tipping. I just want to give the same variable different values depending on some condition, so that I can evaluate it later. e.g. <xsl:if test="Cond1"> <xsl:variable name="GlobaleVariable" select="1"> </xsl:if> <xsl:if test="Cond2"> <xsl:variable name="GlobaleVariable" select="2"> </xsl:if> It doesn't work with xt. Nor do I find anything in the spec. Any idea? Thanx. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Sep 8 19:04:14 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:14:45 2004 Subject: fixing (just) namespaces and validation References: <199909081037.LAA21158@nag.co.uk> Message-ID: <37D69791.652DF82A@mecomnet.de> David Carlisle wrote: > > I wrote > > Simon St.Laurent wrote: > > > > > > Namespaces and validation are incompatible in cases where the namespace > > > prefix changes for whatever reason, > > > > this claim is not universaly true. while there are dtd's for which it holds > > (those with ambiguous prefixes are those with declarations with identical > > prefixed names and no directly specified namespace binding.), this does not > > hold for all dtd's > > Surely _all_ DTDs do have this problem with the namespace REC. We disagree. It is not the dtd?s themselves which "have the problem". A dtd can actually encode sufficient information to identify intended universal names. It is the parsers which cause the problem by ignoring the information provided. > > The [illustrated equivalent documents] > can be validated against a dtd equivalent to <!ELEMENT zap:x EMPTY> <!ATTLIST zap:x xmlns:zap CDATA #FIXED "http://here"> iff the parser provides adequate support for name management. for example, where it maps the names "foo:x", "bar:x" and "zap:x" all to the same symbol before the validation process/application ever has access to them. The parser which i noted in my previous message recognizes PI's of the form <?xml:namespace xmlns="http://here" xmlns:bar="http://here" ?> as instructions to bind, within a given scope, the respective prefixes to packages which are in addition bound statically to the identifier provided as pseudo-attribute value. this works. no, it is not necessary. The bindings implicit in attribute declarations are also be sufficient to enable the same interning process - given the appropriate scoping rules. the name stem is then interned into the respective package. the application works with the interned symbols. > Well, you could write a DTD that worked for any finite set of prefixes, > just by duplicating all the declarations, but you can not write one that > works in general. Please see above. > > So, to validate with namespaces, you either have to pre-process the > document instance to normalise the prefixes to the prefix used in the > DTD, No, the processing happens in the course of parsing. There is no need for an additional pass. No, it is better to map them all to a symbol associated with the universal name. The prefixes are superfluous. The application (and the validation process) works with these symbols only. It never cares what the prefixes were. The "rewriting" happens on the fly as the document is parsed. It is similar to the approach outlined by Mr Bray endless months ago. > or you have to invent a new declaration in the DTD that says > `this DTD uses prefix foo: but a documenent instance may use any prefix, > so long as is bound to the namespace "http://here"' > This is (I assume) the intention of the PI in Simon's posting. > As i noted in the prior message, the pi is sufficient to support the process. it is, however, not always necessary. For some dtds, the attribute declarations suffice. I suspect that, with additional rules to specify their scope, the attribute declarations would be as expressive as the proposed pi. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 8 19:13:23 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:45 2004 Subject: ANN: XML and Databases article In-Reply-To: <01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de> References: <01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de> Message-ID: <14294.39104.190422.759370@localhost.localdomain> Ronald Bourret writes: > (In this sense, the XML information set has much in common with groves, as > it is a property set. Similarly, the DOM could be viewed as an API for a > grove. The XML information set is not a grove because [why? The only > reason I can think of is that it is not been expressed in grove > notation]. I'm not aware of anything that would prevent the Infoset from being described in Grove notation. There aren't many people alive who actually know Groves (we couldn't all fit in a Cessna, but we probably could squeeze into a Dash-8 with a few empty seats), so it had no real familiarity advantage. By the way, for a database-like XML thingy, see http://www.megginson.com/DATAX/ The DATAX interfaces can be used on top of an RDBM as easily as they can on top of the default in-memory data structures. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 8 19:21:24 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:45 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <14294.36560.725917.191918@localhost.localdomain> References: <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <4.0.1.19990908091744.01115340@216.27.10.33> <14294.36560.725917.191918@localhost.localdomain> Message-ID: <14294.39695.624934.80200@localhost.localdomain> David Megginson writes: > DTDs do two things very well -- they let you validate the surface > structure of an XML 1.0 document, and they provide production rules to > help with the creation of XML 1.0 documents. They could be extended > to do lots of other kinds of things, but I hardly see the point (ISO > 8859-1 could have been extended to include markup, for example, but it > would have been a bad idea). Note that they do two additional things rather more poorly: they specify the physical makeup of the document, and they provide default values for attributes. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Sep 8 20:08:38 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:45 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <14294.36560.725917.191918@localhost.localdomain> References: <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <4.0.1.19990908091744.01115340@216.27.10.33> Message-ID: <199909081810.OAA05438@hesketh.net> This continues to be interesting, but I'm afraid you're convincing me more and more that your layered approach is grotesque, inflexible, and liable to tilt, rather than a good way to spare developers aspirin. At 01:02 PM 9/8/99 -0400, David Megginson wrote: >Oops! Note that I didn't say "what Namespaces do" -- that's >application-specific. I referred only to the parts of XML 1.0 syntax >that act as links to the Namespace layer (Namespace declarations and >prefixes). So, for > > "what Namespace declarations and prefixes do" > >try reading > > "how expanded names are constructed from Namespace declarations and > prefixes". > >In other words, given any XML 1.0 document, the XML Namespaces REC >precisely and unambiguously specifies how to determine the expanded >name of every element and attribute in the document. Thats *all* that >you need to move from the XML 1.0 layer to the Namespaces layer during >processing. Again, you're assuming that everyone wants to treat Namespaces as a layer that happens _after_ XML parsing (incl validation) is complete. I don't want to move from XML 1.0 to Namespaces - I want to address Namespaces within the context of XML 1.0 validation. There is nothing in either spec that requires that they be treated as separate layers, by my reading. On the other hand, breaking XML 1.0 into intelligible layers and integrating Namespaces as a layer within that structure seems like a worthy project. >But there's no reason that the parser has to finish processing the XML >1.0 layer before it starts evaluating the Namespace layer -- that's a >matter of physical implementation, and the layers belong to a logical >model (jumping layers is always wrong in logical models, but it often >makes sense in implementations: note how many routers know about HTTP, >even though they're technically dealing with the IP layer). In the >SAX Namespaces filter for DATAX, for example, the Namespace processing >is done on the fly. See above. The question is not whether I have to finish processing the entire document with the parser before I begin namespace processing - it's whether I can integrate namespace processing with XML 1.0 processing. Where does the layer belong? I don't find Namespaces compelling as a 'logical layer' of their own - rather, I see their existence in a separate document as a historical accident. >More seriously, neither XML nor Namespaces currently has a >standardized processing model of any sort, and I'm still trying to >decide whether I think they should. The data models and APIs that we >have specify only what should be available *after* processing; they >don't say how we get there. Precisely. And they don't say what layer goes where, either. You read the current situation as opening one set of possibilities, and I see it opening a very different set of possibilities. > > The problem in both of these examples is that you treat XML itself > > as monolithic, and DTD validation as a tool that can only be used > > at the time of parsing. As a result, we have multiple levels of > > checking that have to be redundant if they're done at all. Check > > against schemas, DTDs, _and_ RDF? And then throw application rules > > on top of that? Forget it. > >No, you have the choice of applying validation only at the levels that >are important to you: if you're producing XHTML for display in legacy >browsers, then you might need to validate the character layer with >regular expressions to ensure that empty-element tags always have a >space before the closing delimiter (<hr />, not <hr/>). No, you don't have the choice of applying _validation_ at whatever level you like - currently, you have the choice of applying it or not applying it during the parser. You're applying the word validation in a much more general sense here, ignoring the fact that DTD-based validation, which is capable of addressing a significant range of problems _today_, is locked in a box with the rest of XML 1.0 processing. >You can apply validation to *any* layer of processing, from the raw >bytes to the final application. Choosing where to validate is an >architectural decision, not a standards one. It just happens that >some of the layers do have shared specs that make validation easier >(regular expressions, DTDs, and RDF schemas), while others do not, >yet. Again, you're using validation to mean anything you want here. Choosing where and when to validate is as much a decision about which tools are available as it is about the logical model you like and which I find so illogical. > > These 'layers' are pretty much a guarantee that developers either > > need to make an investment in large quantities of aspirin - or pick > > one tool and stick to it. > >No, that's wrong -- layered approaches like these have proven >themselves over and over (the Internet is only the most famous >example). Do you consider it redundant that both TCP and HTTP perform >different kinds of validity checks? TCP and HTTP do well with their different checks. (And UDP is available for those who like to cut down redundancy.) But DTDs perform a subset of the validity checks of schemas, while RDF schemas provide an overlapping set. That sort of redundancy I find merely redundant. Your layers aren't performing tasks which are different enough to justify calling them separate 'logical' tasks. > > If I thought that schemas would be here soon, or that RDF really > > was the answer to all of these, I wouldn't be pushing on DTD > > validation. > >But you need all of these and more. Any higher-level layer will have >its own constraints that cannot (and should not) be expressed in a >generic XML structural schema language: read the TEI spec (for >example) to see how complex these constraints can be. I may need all of these, someday, for certain types of projects. I do not believe that I will need to use DTDs, schemas, and RDF all on the same processing run of a document. I may need to be able to convert among them for different processors, but stacking all of them (DTDs and schemas in particular) seems foolish at best. James Clark's note on the problems of DTDs and their effective uselessness is much more believable to me than a claim that I'll need to use both forms in some kind of layered processing. (Given that the whole thing will fold at validation if I change a prefix anyway, I can't imagine why I'd bother.) >DTDs do two things very well -- they let you validate the surface >structure of an XML 1.0 document, and they provide production rules to >help with the creation of XML 1.0 documents. They could be extended >to do lots of other kinds of things, but I hardly see the point (ISO >8859-1 could have been extended to include markup, for example, but it >would have been a bad idea). I don't think we're talking about an enormous extension ala schemas - we're talking about integrating validation with qualified names. It's not an enormous leap. > > DTDs do seem to be a good answer - in the short term for many > > projects, in the long term for a subset of projects - to the need > > for structural checking. It doesn't seem that ridiculous to want > > to 'validate' the results of a transformation (generated via XSL or > > the DOM) or to want to 'validate' a document against a DTD > > structure while taking into account namespaces. > >Not at all, but you need something other than DTDs to do that, at >least for now. Why? Because XML 1.0 was written as a monolithic spec and the XML Namespaces rec didn't feel it was worth the time? This is not a difficult problem to address, solving real needs now. We don't have _anything_ to do that with now. > > Because XML 1.0 was written so that everything from character > > checking to entity replacement to attribute defaulting to > > structural inspections (DTD and otherwise) are all performed by one > > monolithic 'parser', we haven't been able to describe XML > > processors with any level of granularity. When I talk about layers > > (for instance, in > > http://www.simonstl.com/articles/layering/layered.htm), it's > > layering for the sake of breaking things into the smallest usable > > components, not for the sake of piling on more and more mostly > > redundant processing. Your layer 3 is way too thick. > >All of the layers are way too thick -- that's the joy of a high-level >logical model. I can break any one of them down into dozens of >smaller layers; in fact, the application layer will often be much more >complicated than the parser layer, simply because useful applications >generally do complicated things. Then maybe we'd better take a closer look at the layers you propose - piling many thick layers on top of each other doesn't sound like a very good recipe. > > If treat validation as a process with its own life, outside of the > > Rube Goldberg machine known as an XML processor, we might be able > > to solve a lot of problems that currently look very difficult much > > more simply. Namespaces included. > >It's wonderful to see that we end up agreeing. Validation is a much >bigger problem than DTDS -- it's best to think of DTDs as a small >bonus (you can perform some types of structural validation on the XML >layer right now basically for free) rather than a liability, and to >think of the greater validation problem as still unsolved in the >general case. That's not because the XML Schema committee members are >stupid or obstructionist, but simply because validation in the general >case is a *very* hard problem. Validation in general is a very large problem, and I'm not trying to solve it all at once. I'm proposing that we fix some tools we have today so that they work better with other tools we have today. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Sep 8 21:01:27 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:45 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) References: <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <4.0.1.19990908091744.01115340@216.27.10.33> <199909081810.OAA05438@hesketh.net> Message-ID: <37D6B308.AB465539@pacbell.net> "Simon St.Laurent" wrote: > > This continues to be interesting, but I'm afraid you're convincing me more > and more that your layered approach is grotesque, inflexible, and liable to > tilt, rather than a good way to spare developers aspirin. I find that puzzling. Layering is well known to be an essential tool for managing complex systems. Heck, the proof is right in front of me on my desk ... ;-) > Again, you're assuming that everyone wants to treat Namespaces as a layer > that happens _after_ XML parsing (incl validation) is complete. I don't > want to move from XML 1.0 to Namespaces - I want to address Namespaces > within the context of XML 1.0 validation. But XML 1.0 doesn't include namespaces, so this can't be done. It's a definitional thing. A revision of XML could do it, not that I'd encourage such a thing right now. But it wouldn't be "XML 1.0" at all. Some folk may be using validation in some other sense than the XML 1.0 specification defines it. If so, it'd help things to find some other words or phrases to describe those processs -- at least apply adjectives to disambiguate the various distinct notions. > I don't find Namespaces compelling as a 'logical layer" > lof their own - rather, I see their existence in a separate document > as a historical accident. Be that as it me, the _fact_ is that it's a separate and decoupled document. If you hard-wire namespace conformance, you're no longer conforming to the XML 1.0 spec, and vice versa. They're separate. The only way to have them work in the same system is to use layers. > > > Because XML 1.0 was written so that everything from character > > > checking to entity replacement to attribute defaulting to > > > structural inspections (DTD and otherwise) are all performed by one > > > monolithic 'parser', we haven't been able to describe XML > > > processors with any level of granularity. When I talk about layers > > > (for instance, in > > > http://www.simonstl.com/articles/layering/layered.htm), it's > > > layering for the sake of breaking things into the smallest usable > > > components, not for the sake of piling on more and more mostly > > > redundant processing. Your layer 3 is way too thick. Simon, what purpose is served by breaking things down that finely? The flip side of recognizing layering as a useful tool is to know that successful layers need to have a type of consistency that's hard to create without careful integration. Even if it's not the way I'd have integrated those components, XML 1.0 has that sort of integration. Dis-integrating it shows no clear benefit to me; it seems like reinventing the wheel or fire or something. > >All of the layers are way too thick -- that's the joy of a high-level > >logical model. I can break any one of them down into dozens of > >smaller layers; in fact, the application layer will often be much more > >complicated than the parser layer, simply because useful applications > >generally do complicated things. > > Then maybe we'd better take a closer look at the layers you propose - > piling many thick layers on top of each other doesn't sound like a very > good recipe. Hmm, that wasn't quite how I was taking it. While I'd admit that many of the technology layers W3C is talking about seem rather thick to me (== barriers to entry), what I heard David suggest was a way to view those layers such that they didn't clash. (A role W3C should be taking, but such architectural communication doesn't appear to be a strong point over there -- sadly.) - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Sep 8 21:01:58 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:46 2004 Subject: Test, please ignore Message-ID: <199909081939.PAA10907@locke.ccil.org> Test, please ignore. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 8 21:47:29 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:46 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <37D6B308.AB465539@pacbell.net> References: <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <4.0.1.19990908091744.01115340@216.27.10.33> <199909081810.OAA05438@hesketh.net> Message-ID: <199909081949.PAA09724@hesketh.net> At 12:03 PM 9/8/99 -0700, David Brownell wrote: >I find that puzzling. Layering is well known to be an essential >tool for managing complex systems. Heck, the proof is right in >front of me on my desk ... ;-) The problem isn't the use of layering itself - it's the choices about what kinds of layers are used and what 'logically' qualifies as a layer. >> Again, you're assuming that everyone wants to treat Namespaces as a layer >> that happens _after_ XML parsing (incl validation) is complete. I don't >> want to move from XML 1.0 to Namespaces - I want to address Namespaces >> within the context of XML 1.0 validation. > >But XML 1.0 doesn't include namespaces, so this can't be done. It's >a definitional thing. A revision of XML could do it, not that I'd >encourage such a thing right now. But it wouldn't be "XML 1.0" at all. I'm not especially concerned about it being "XML 1.0" at all. Yes, I'll happily acknowledge that integrating namespaces and XML 1.0 in a strong sense would require rewriting, probably resulting in XML 1.1 - which no one seems interested in doing. Proposing it in a weaker sense might encourage consistency among those who need and use it, however. It doesn't seem like decoupling DTD processing from XML 1.0 is especially difficult, and that integrating that with namespaces in a better way (in fact, any way) than exists now would be useful. >Some folk may be using validation in some other sense than the XML 1.0 >specification defines it. If so, it'd help things to find some other >words or phrases to describe those processs -- at least apply adjectives >to disambiguate the various distinct notions. Agreed. We need better vocabulary. After a few years in the language lawyering world of XML 1.0, 'validation' to me means something that happens in XML 1.0 with DTDs. If I need to describe schema or RDF applications, I tend to say 'schema validation' or 'validation against a schema', for instance. >> I don't find Namespaces compelling as a 'logical layer" >> lof their own - rather, I see their existence in a separate document >> as a historical accident. > >Be that as it me, the _fact_ is that it's a separate and decoupled >document. If you hard-wire namespace conformance, you're no longer >conforming to the XML 1.0 spec, and vice versa. They're separate. >The only way to have them work in the same system is to use layers. In other words, we're stuck, should wait for schemas, and should discontinue use of DTDs in systems where namespaces may be important? (And I mean namespaces, not namespace prefixes.) I suspect that there's a sizable number of developers who might like more options than that. >> > > Because XML 1.0 was written so that everything from character >> > > checking to entity replacement to attribute defaulting to >> > > structural inspections (DTD and otherwise) are all performed by one >> > > monolithic 'parser', we haven't been able to describe XML >> > > processors with any level of granularity. When I talk about layers >> > > (for instance, in >> > > http://www.simonstl.com/articles/layering/layered.htm), it's >> > > layering for the sake of breaking things into the smallest usable >> > > components, not for the sake of piling on more and more mostly >> > > redundant processing. Your layer 3 is way too thick. > >Simon, what purpose is served by breaking things down that finely? Lots of purposes. You can reuse modules easily, integrate new technologies (like namespaces) into existing structures, and take modules that were originally built for use in parsing and apply them to results from other XML operations (like XSL transforms, DOM work, etc.). >The flip side of recognizing layering as a useful tool is to know >that successful layers need to have a type of consistency that's >hard to create without careful integration. Even if it's not the >way I'd have integrated those components, XML 1.0 has that sort of >integration. Dis-integrating it shows no clear benefit to me; it >seems like reinventing the wheel or fire or something. If reinventing the wheel would let me reuse the wheels on other devices, I'd be happy to do it. Right now, XML 1.0 provides you with axles, wheels, and tires, all glued together so that you can't take the wheels off and put them on another car without yanking the axle off. Integration is critically important. A key part of integration, though, is clarifying the parts and how they fit together - and come apart. >> Then maybe we'd better take a closer look at the layers you propose - >> piling many thick layers on top of each other doesn't sound like a very >> good recipe. > >Hmm, that wasn't quite how I was taking it. While I'd admit that >many of the technology layers W3C is talking about seem rather thick >to me (== barriers to entry), what I heard David suggest was a way to >view those layers such that they didn't clash. I agree with David (Megginson) that the layers shouldn't clash. However, I don't think his model avoids clashes successfully (notably DTD validation and namespaces), and I consider the thickness issue important. If you're willing to break down some of those layers, I think you'll see lots of room for improvement. >(A role W3C should be >>taking, but such architectural communication doesn't appear to be a >>strong point over there -- sadly.) Agreed. There are a few documents out there that might be guideposts (like the Notes I mentioned earlier today), but they don't provide a clear picture of where any of this is going. There seem to a large number of very different perspectives. Hopefully those different perspectives will play off each other and give us some useful tools. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 BMurri at wavephore.net Wed Sep 8 21:46:58 1999 From: BMurri at wavephore.net (Blair Murri) Date: Mon Jun 7 17:14:46 2004 Subject: Namespace for HTML (Signup Here) Message-ID: <31AA4BE99284D211B47A006008172E20016EA6@MAILMAN> I vote 2 (or 4 if needed) Blair L. Murri Sr. Programmer/etc. WavePhore, Inc. > -----Original Message----- > From: Don Park [SMTP:donpark@docuverse.com] > Sent: Monday, September 06, 1999 4:02 PM > To: xml-dev@ic.ac.uk > Subject: Namespace for HTML (Signup Here) > > Both Tim Bray and David Megginson proposed we settle on the Namespace URI > for HTML. I think this is a clear enough and small enough task for us > (XML-DEV) to accomplish here and now. > > Here are some candidates: > > 1) "http://www.w3.org/Markup/" - by David Megginson > 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray > 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :) > > Lets just settle on one and start using it. If W3C balks, we can go with: > > 4) "http://www.xml.org/HTML/2000/Namespace" - (if Jon Bosak agrees) > > Signup by replying with one of the numbered options. > > If you are against this proposal, select this: > > 0) "hell://no.stinking.namespace/4/HTML" > > Best, > > Don Park - mailto:donpark@docuverse.com > Docuverse - http://www.docuverse.com > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990908/ba417c2b/attachment.htm From david at megginson.com Wed Sep 8 21:54:31 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:46 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <199909081810.OAA05438@hesketh.net> References: <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <14294.36560.725917.191918@localhost.localdomain> <199909081810.OAA05438@hesketh.net> Message-ID: <14294.47066.957120.565534@localhost.localdomain> Simon St.Laurent writes: > Again, you're assuming that everyone wants to treat Namespaces as a > layer that happens _after_ XML parsing (incl validation) is > complete. I don't want to move from XML 1.0 to Namespaces - I want > to address Namespaces within the context of XML 1.0 validation. In other words, you want to deal exclusively with the Namespaces layer: I think that's a good idea for most applications, and it's certainly necessary for XSL and RDF; it just happens that there's not a standard schema for validating that layer yet (because it's so new). Personally, I would not mind deprecating the XML 1.0 layer so that we can remove it in a few years. Some applications, however, *do* care about the XML 1.0 layer (i.e. they care about what specific prefix you use) -- again, XHTML for legacy browsers is a very good example -- and DTDs are well suited for that work. See further, below. My point is simply that it's not fair to complain that DTDs don't work with the Namespaces layer, any more than it's fair to complain that your screwdriver handle gets dented when you hit nails with it. > See above. The question is not whether I have to finish processing > the entire document with the parser before I begin namespace > processing - it's whether I can integrate namespace processing with > XML 1.0 processing. Where does the layer belong? I don't find > Namespaces compelling as a 'logical layer' of their own - rather, I > see their existence in a separate document as a historical > accident. It is an accident, partly, but that's the way that technology develops. We have to deal with the fact that there is much XML software that doesn't know about Namespaces, and it will likely be deployed for a long time. That means that some applications will care about the XML 1.0 level for the foreseeable future. As a result, there are de facto two separate layers. Ideally, the number of applications that care will diminish over time. [snip] > No, you don't have the choice of applying _validation_ at whatever > level you like - currently, you have the choice of applying it or > not applying it during the parser. You're applying the word > validation in a much more general sense here, ignoring the fact > that DTD-based validation, which is capable of addressing a > significant range of problems _today_, is locked in a box with the > rest of XML 1.0 processing. Validation is a big problem in software design, and even in the SGML world DTD validation covered at best a tiny subset of it. It might be useful to distinguish the following terms to avoid confusion: validation: the act of ensuring that data conform to a set of known rules. XML validation: validation where the data are all or part of an XML document. DTD validation: XML validation using a DTD, as defined in the XML 1.0 specification. The first term applies to any layer in any system that exchanges information; most programmers who deal with validation problems have never even heard of XML. An RDF schema (for example) provides validation of the RDF data model, not of the XML markup (as a proof, it can be applied after all of the original markup distinctions have been removed). A Java interface, to give another example, is a schema that the parser uses to validate a Java implementation. The second, more specialised term applies to any kind of validation performed on an XML document *as XML* -- it is broad enough to embrace both the XML 1.0 layer and the Namespaces layer. The XML schema effort is aimed at providing a general mechanism for XML validation, but not at providing DTD validation. The third term applies to the specific set of rules and constraints in the XML 1.0 recommendation, where the target is an XML document and the rules are expressed in a DTD. DTD validation applies only to the XML 1.0 layer. Most validation in software systems is done by custom code; in some cases, there are higher level constructs (like DTDs or BNF) that can help. > I may need all of these, someday, for certain types of projects. I do not > believe that I will need to use DTDs, schemas, and RDF all on the same > processing run of a document. I hope that you won't, but it's not hard to think of situations where you would. > Why? Because XML 1.0 was written as a monolithic spec and the XML > Namespaces rec didn't feel it was worth the time? This is not a difficult > problem to address, solving real needs now. We don't have _anything_ to do > that with now. It's not a question of being worth the time (God knows how many person-hours we put into debating and designing Namespaces REC, but it must be at least 10 person hours per word) -- it's a question of not breaking XML 1.0. We deliberately haven't fiddled with XML during the last year and a half -- it's been stable so that the companies investing hundreds of millions of R&D dollars into XML don't see their software become obsolete two weeks after (or before) release. This approach wins us a lot of confidence in the corporate world, and it's one of the biggest secrets of XML's success: every document containing Namespaces can still be processed by an XML 1.0 processor that knows nothing about Namespaces; processors that do know about Namespaces can do additional kinds of value-added processing. [snip] > >All of the layers are way too thick -- that's the joy of a > >high-level logical model. I can break any one of them down into > >dozens of smaller layers; in fact, the application layer will > >often be much more complicated than the parser layer, simply > >because useful applications generally do complicated things. > > Then maybe we'd better take a closer look at the layers you propose - > piling many thick layers on top of each other doesn't sound like a very > good recipe. I think that you've misunderstood. Each thick layer is an abstraction of many thinner layers -- that's the way that high-level models work (just as each folder in a file system may contain many other folders, etc.). Remember that a model is an abstracted explanation of a system design, not the system itself. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 8 22:06:45 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:46 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <199909081949.PAA09724@hesketh.net> References: <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <199909081810.OAA05438@hesketh.net> <37D6B308.AB465539@pacbell.net> <199909081949.PAA09724@hesketh.net> Message-ID: <14294.49584.847567.906696@localhost.localdomain> Simon St.Laurent writes: > In other words, we're stuck, should wait for schemas, and should > discontinue use of DTDs in systems where namespaces may be > important? (And I mean namespaces, not namespace prefixes.) No -- it shouldn't matter whether Namespaces are important or not. You should discontinue using DTDs where you don't care about the specific prefixes used, since you're not buying yourself anything by using them when you don't care about the XML 1.0 layer. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Sep 8 22:24:06 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:46 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <14294.47066.957120.565534@localhost.localdomain> References: <199909081810.OAA05438@hesketh.net> <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <14294.36560.725917.191918@localhost.localdomain> <199909081810.OAA05438@hesketh.net> Message-ID: <199909082026.QAA11768@hesketh.net> In many ways, I agree with David's posting, and he goes well into providing the more precise vocabulary that David Brownell and I both seem to agree that any discussion of 'validation' needs. I'm addressing only the points here where we disagree - few, but critical - in the hopes of keeping this post briefer than its predecessors have been. At 03:55 PM 9/8/99 -0400, David Megginson wrote: >Simon St.Laurent writes: > > I don't want to move from XML 1.0 to Namespaces - I want > > to address Namespaces within the context of XML 1.0 validation. > >In other words, you want to deal exclusively with the Namespaces >layer: No. I want to take a very well understood technology that's in the XML 1.0 layer and apply it to the results of the Namespaces layer. Adding qualified names processing to XML DTD validation is not very difficult (as james anderson has pointed out several times on another thread). This requires taking a layer out of XML 1.0 - though it was not described as a separate layer in that document - and applying it to the namespace layer. > I think that's a good idea for most applications, and it's >certainly necessary for XSL and RDF; it just happens that there's not >a standard schema for validating that layer yet (because it's so >new). Personally, I would not mind deprecating the XML 1.0 layer so >that we can remove it in a few years. Personally, I would not mind using the technology we have today so that we can validate those results - heck, any output that purports to be XML - today. >My point is simply that it's not fair to complain that DTDs don't work >with the Namespaces layer, any more than it's fair to complain that >your screwdriver handle gets dented when you hit nails with it. If there _were_ tools of any kind for processing the Namespaces layer, I would be more inclined to agree with this analogy. As it stands, I'd prefer a screwdriver with a blunt piece of metal on the end of the handle to nothing, thanks. > > I don't find > > Namespaces compelling as a 'logical layer' of their own - rather, I > > see their existence in a separate document as a historical > > accident. > >It is an accident, partly, but that's the way that technology >develops. We have to deal with the fact that there is much XML >software that doesn't know about Namespaces, and it will likely be >deployed for a long time. That means that some applications will care >about the XML 1.0 level for the foreseeable future. As a result, >there are de facto two separate layers. There were warnings in the XML 1.0 spec about the use of colons and their reserved nature. I don't think this situation qualifies for two 'separate layers' or that the lack of standardized processing for namespace validation of some sort is justified by the existence of XML 1.0. At worst, this is a situation that should be left up to parser and application developers - it certainly causes no more harm than optional retrieval of external resources. >I think that you've misunderstood. Each thick layer is an abstraction >of many thinner layers -- that's the way that high-level models work >(just as each folder in a file system may contain many other folders, >etc.). Remember that a model is an abstracted explanation of a system >design, not the system itself. I think you've forgotten the cost of encapsulating smaller parts into larger layers - the small parts are no longer mobile, and can't be redeployed to other parts of the model. And because models affect system design... And a few minutes later, David writes: >Simon St.Laurent writes: > >> In other words, we're stuck, should wait for schemas, and should >> discontinue use of DTDs in systems where namespaces may be >> important? (And I mean namespaces, not namespace prefixes.) > >No -- it shouldn't matter whether Namespaces are important or not. >You should discontinue using DTDs where you don't care about the >specific prefixes used, since you're not buying yourself anything by >using them when you don't care about the XML 1.0 layer. Except of course, that you might well buy yourself a screwdriver with a blunt piece of metal of the end that you could use to validate documents with namespaces _today_. I don't buy the lines you draw between the layers - I don't find them logical. If you don't like DTDs and don't want to see their use extended, fine. I find your refusal to consider them a useful tool outside of their original context extraordinarily puzzling. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Sep 8 22:28:05 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:46 2004 Subject: list administration (was: Re: Layers, again (was Re: fixing (just) namespaces andvalidation) References: <852567E6.006E8C38.00@Venus.GlobalServeCorp.com> Message-ID: <37D6C733.A089AEDB@pacbell.net> Mike_D_Hall/Cincinnati/GlobalServe@GlobalServeCorp.com wrote: > > Can someone please help me get removed from this mailing list. Every message you receive has a footer that says how to get off this particular mailing list. Follow those directions. There is not a snowball's chance in a hot place that ** I ** can do anything about this. The same is true for all but one or two members of this list. So please don't send such requests either individuals not identified in the message footer, or to the list as a whole. (You did both.) > Someone must have applied my email for them, cause I've tried to remove myself > from this email and my others and it's not working. > I'm sorry to bother, but I'd really appreciate any help (My boss is mad that I > get 100 emails daily!). Hmm, I suggest that you use filtering tools such as the one built into Netscape, or "procmail". They're essential tools on the internet; they have been for most of the decade. Only one hundered emails a day? What a pleasure that must be! - Dave > Thanks, > mikey xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 8 22:44:58 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:46 2004 Subject: Someone's or something is filtering my message! In-Reply-To: <14294.47066.957120.565534@localhost.localdomain> References: <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <14294.36560.725917.191918@localhost.localdomain> <199909081810.OAA05438@hesketh.net> <14294.47066.957120.565534@localhost.localdomain> Message-ID: <14294.51650.225619.594268@localhost.localdomain> RGF2aWQgTWVnZ2luc29uIHdyaXRlczoNCg0KID4gSXQncyBub3QgYSBxdWVzdGlvbiBvZiBi ZWluZyB3b3J0aCB0aGUgdGltZSAoR29kIGtub3dzIGhvdyBtYW55DQogPiBwZXJzb24taG91 cnMgd2UgcHV0IGludG8gZGViYXRpbmcgYW5kIGRlAAAAAGluZyBOYW1lc3BhY2VzIFJFQywg YnV0IGl0DQogPiBtdXN0IGJlIGF0IGxlYXN0IDEwIHBlcnNvbiBob3VycyBwZXIgd29yZCkg LS0gDQoNCkRlcGVuZGluZyBvbiB5b3VyIG1haWwgcmVhZGVyLCB5b3UgbWF5IG9yIG1heSBu b3Qgc2VlIGZvdXIgbnVscyAoXkApDQppbiB0aGUgYWJvdmUgZXhjZXJwdCBpbiB0aGUgd29y ZCBwcmVjZWRpbmcgIk5hbWVzcGFjZXMgUkVDIi4gIEhlcmUncw0Kd2hhdCBvcmlnaW5hbGx5 IHdlbnQgb3V0Og0KDQogIEl0J3Mgbm90IGEgcXVlc3Rpb24gb2YgYmVpbmcgd29ydGggdGhl IHRpbWUgKEdvZCBrbm93cyBob3cgbWFueQ0KICBwZXJzb24taG91cnMgd2UgcHV0IGludG8g ZGViYXRpbmcgYW5kIGRlc2lnbmluZyBOYW1lc3BhY2VzIFJFQywgYnV0IGl0DQogIG11c3Qg YmUgYXQgbGVhc3QgMTAgcGVyc29uIGhvdXJzIHBlciB3b3JkKSAtLQ0KDQpIZXJlJ3MgaG93 IGl0IGxvb2tzIG9uIG15IHNjcmVlbiBub3c6DQoNCiAgSXQncyBub3QgYSBxdWVzdGlvbiBv ZiBiZWluZyB3b3J0aCB0aGUgdGltZSAoR29kIGtub3dzIGhvdyBtYW55DQogIHBlcnNvbi1o b3VycyB3ZSBwdXQgaW50byBkZWJhdGluZyBhbmQgZGVeQF5AXkBeQGluZyBOYW1lc3BhY2Vz IFJFQywgYnV0IGl0DQogIG11c3QgYmUgYXQgbGVhc3QgMTAgcGVyc29uIGhvdXJzIHBlciB3 b3JkKSAtLQ0KDQpJIGxlZnQgb3V0IHRoZSAndGhlJyBteXNlbGYsIGJ1dCBzb21laG93IGJl dHdlZW4gd2hlbiB0aGUgbWVzc2FnZSBsZWZ0IA0KbXkgY29tcHV0ZXIgYW5kIGl0IGFycml2 ZWQgYmFjayBmcm9tIHRoZSBzZXJ2ZXIsIHRoZSBzdHJpbmcgJ3NpZ24nIHdhcyANCnJlcGxh Y2VkIHdpdGggZm91ciBudWxzIGluICJkZXNpZ25pbmciLiAgSSBoYWQgdGhlIHNhbWUgcHJv YmxlbSB3aXRoIGEgDQpkaWZmZXJlbnQgc3RyaW5nIGluIGFub3RoZXIgcG9zdGluZywgYW5k IEkgbm90aWNlZCB0aGUgcHJvYmxlbSBpbiBhDQpwb3N0aW5nIGZyb20gU3RldmUgTmV3Y29t YiBhcyB3ZWxsLg0KDQpJdCB3b3VsZCBiZSB1c2VmdWwgdG8ga25vdyBpZiBhbnlvbmUgZWxz ZSBpcyBzZWVpbmcgdGhpcywgc28gdGhhdCBJDQpjYW4gc3RhcnQgZmlndXJpbmcgb3V0IHdo ZXJlIHRoaXMgaXMgaGFwcGVuaW5nIChpcyBpdCBoYXBwZW5pbmcgb24gdGhlDQp3YXkgb3V0 IG9yIHRoZSB3YXkgYmFjaz8pLiAgSSBkb24ndCBrbm93IGhvdyBhbnkgZmFtaWx5IGZpbHRl ciBjb3VsZA0KbWlzdGFrZSAnc2lnbicgZm9yIGEgbmF1Z2h0eSB3b3JkLCBidXQgdGhleSBh cmUgcHJldHR5IHN0dXBpZCBwaWVjZXMNCm9mIHNvZnR3YXJlLg0KDQoNCkFsbCB0aGUgYmVz dCwNCg0KDQpEYXZpZA0KDQotLSANCkRhdmlkIE1lZ2dpbnNvbiAgICAgICAgICAgICAgICAg ZGF2aWRAbWVnZ2luc29uLmNvbQ0KICAgICAgICAgICBodHRwOi8vd3d3Lm1lZ2dpbnNvbi5j b20v xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 8 22:54:00 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:46 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <199909082026.QAA11768@hesketh.net> References: <199909081810.OAA05438@hesketh.net> <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <14294.36560.725917.191918@localhost.localdomain> <14294.47066.957120.565534@localhost.localdomain> <199909082026.QAA11768@hesketh.net> Message-ID: <14294.52037.477683.565382@localhost.localdomain> Simon St.Laurent writes: > No. I want to take a very well understood technology that's in the > XML 1.0 layer and apply it to the results of the Namespaces layer. > Adding qualified names processing to XML DTD validation is not very > difficult (as james anderson has pointed out several times on > another thread). It's fairly simple to add it to the spec, but very hard to retrofit deployed software to use it. It is not a good idea (or good publicity) to have two different XML dialects floating around the Web at the same time (see further, below). > If there _were_ tools of any kind for processing the Namespaces > layer, I would be more inclined to agree with this analogy. As it > stands, I'd prefer a screwdriver with a blunt piece of metal on the > end of the handle to nothing, thanks. Does DDML handle Namespaces? If so, then there's your spec. There's no law that says you have to wait for the W3C to bless something, and DDML has the (good) characteristic of not breaking existing XML tools, a characteristic missing from any modification of DTD syntax. > There were warnings in the XML 1.0 spec about the use of colons and > their reserved nature. [snip] There was no warning, however, that DTD syntax might change. > I don't buy the lines you draw between the layers - I don't find them > logical. If you don't like DTDs and don't want to see their use extended, > fine. I find your refusal to consider them a useful tool outside of their > original context extraordinarily puzzling. See above. We talked about pre-release pragmatism during the XHTML discussion -- keep everything small, simple, and modular -- but we also have to consider post-release pragmatism -- don't screw around with released specs until you have a very good, world-is-about-to-blow-up reason. This is more of a my-car-radio-is-stuck-on-AM reason. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Sep 8 23:13:54 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:46 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <14294.52037.477683.565382@localhost.localdomain> References: <199909082026.QAA11768@hesketh.net> <199909081810.OAA05438@hesketh.net> <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <14294.36560.725917.191918@localhost.localdomain> <14294.47066.957120.565534@localhost.localdomain> <199909082026.QAA11768@hesketh.net> Message-ID: <199909082116.RAA14362@hesketh.net> At 04:55 PM 9/8/99 -0400, David Megginson wrote: >Does DDML handle Namespaces? If so, then there's your spec. There's >no law that says you have to wait for the W3C to bless something, and >DDML has the (good) characteristic of not breaking existing XML tools, >a characteristic missing from any modification of DTD syntax. Sure. But does DDML have any implementations? No. Perhaps that's my own fault, but it seems a lot easier to add a PI to DTDs, which doesn't break anything, than to write a DDML implementation from scratch. >There was no warning, however, that DTD syntax might change. I think you're overestimating the syntax changes being described. A PI would be ignored by parsers that didn't understand it, and james anderson's suggestion of interpreting attribute declarations makes even less impact. (I don't think that one will necessarily work, however.) >See above. We talked about pre-release pragmatism during the XHTML >discussion -- keep everything small, simple, and modular -- but we >also have to consider post-release pragmatism -- don't screw around >with released specs until you have a very good, >world-is-about-to-blow-up reason. This is more of a >my-car-radio-is-stuck-on-AM reason. Have you listened to AM radio in Central New York? Never mind that question. I don't think what I'm proposing is inconsistent with the values you are espousing. If I felt it was going to take a drastic reconfiguration of DTD syntax, with implications for all those corporations in search of stability, I wouldn't be bothering. Instead, it seems like I'm applying the small, simple, and modular approach to a problem that has irritated a lot of folks for a long time. It's taking something useful from one situation and applying it to another - reuse in a different context, with a little added information. And, as always, nothing I post has any official standing anyway, right? Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Sep 8 23:28:24 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:46 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <199909082116.RAA14362@hesketh.net> References: <199909082026.QAA11768@hesketh.net> <199909081810.OAA05438@hesketh.net> <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <14294.36560.725917.191918@localhost.localdomain> <14294.47066.957120.565534@localhost.localdomain> <14294.52037.477683.565382@localhost.localdomain> <199909082116.RAA14362@hesketh.net> Message-ID: <14294.54422.707751.653558@localhost.localdomain> Simon St.Laurent writes: > >There was no warning, however, that DTD syntax might change. > > I think you're overestimating the syntax changes being described. > A PI would be ignored by parsers that didn't understand it, and > james anderson's suggestion of interpreting attribute declarations > makes even less impact. (I don't think that one will necessarily > work, however.) My fault: I didn't realise that your proposed changes used only PIs. I'm not sure that I see how the documents could still be valid from the XML 1.0 perspective, though, and if not, the new documents would still be backwards incompatible with some (many?) existing XML 1.0 implementations. 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 srn at techno.com Thu Sep 9 01:40:12 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:14:46 2004 Subject: ANN: XML and Databases article In-Reply-To: <01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de> (message from Ronald Bourret on Wed, 8 Sep 1999 17:35:58 +0200) References: <01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de> Message-ID: <199909082341.SAA02016@bruno.techno.com> [Ron Bourret:] > I've read Paul's tutorial and the GroveMinder summary on the Web, so > let's see if I've got this straight. A grove is basically a > property set, broken down into classes, each of which has > properties. There are probably relationships between those > classes. For example, a grove for XML could have classes for > elements, attributes, entities, and so on, where the element class > points to the attribute class. A grove for a relational database > would have classes for tables, columns, etc., where the table class > points to the column class. Pretty close, but not quite on the money. First of all, a terminological problem: A grove is the set of objects that results from understanding (parsing and processing) some particular logical resource. No grove is made from more than one logical resource (I say "logical" resource because some single resources are distributed in multiple physical containers). However, more than one grove can be made from a single resource. This is because resources have multiple layers. For example, in the case of XML documents, there is always the XML syntax layer of "understanding". The property set (schema) for this layer is probably strongly reminiscent of the DOM. However, there are one or more vocabularies used in every XML document (there's always at least one because the element types have names, even if there's no DTD). The semantics of these vocabularies may imply "emergent properties" of the information contained in the resource, and there can be a property set for each vocabulary's emergent properties. So preparing a single resource for application-internal exploitation may involve creating groves for each vocabulary. By giving names to the emergent properties of vocabularies, such property sets can be, in effect, APIs to the semantics of each vocabulary, thus opening the way for vocabulary-specific software engines, and for far more reliable cross-application information interchange than the Web has ever seen. So, instead of saying, > A grove for XML could have classes for elements, attributes, > entities, and so on, where the element class points to the attribute > class. ... you might better have said any one of the following (this has to be said with extreme precision, so look closely): | A property set for the XML language could have classes for elements, | attributes, entity references, and so on, where the element class | has, as one of its nodal properties an "attribute specification | list" property, whose value is a list of "attribute value | specification" nodes. or: | The primary grove form of an XML resource could have nodes | conforming to the "element", "attribute specification", and "entity" | classes, and so on, where the "element" class has, as one of its | properties, an "attribute specification list" property, whose value | consists of a list of nodes that all must be of the class "attribute | value specification". or, in view of the fact that the DTD of an XML resource is part of its grove (when it appears or is referenced by the DOCTYPE declaration in an XML resource): | The primary grove from of an XML resource could have element type | definitions, attribute list definitions, entity declarations, and so | on, where the element type definition class has, as one of its nodal | properties, an "attribute definition list" property, whose value | consists of a list of nodes that all must be of the class "attribute | definition". The second problem with your summary statement is that "points to" is actually an implementation detail. The standard only says that nodes (objects) in groves have properties, and the some properties can be "nodal" -- that is, the values of such properties can be other nodes (in the same grove and/or in other groves). The manner in which a node is represented to be a property value in any given implementation is almost certainly going to be via pointing (at least in a von Neumann architecture machine), but it's important to realize that that is an implementation decision, and it's inaccurate to say that "pointing" has anything to do with the grove paradigm. A property set can only say that the value of a property is nodal, and implementations of the grove paradigm must make it appear that the value of such a property is indeed one or more nodes, but how that is made to happen is not part of the standard (nor should it be). So, instead of saying: > "where the table class points to the column class" ... it would be much more accurate to say: | where the "table" class has a property named "columns" whose value | is a list of "column"-class nodes. > In this sense, the XML information set has much in common with > groves, as it is a property set. Yes, except that it's not yet clear that the XML info set will be expressed using the ISO Property Set DTD -- but this is merely a syntax issue. I agree with David Megginson: I expect it to be readily convertible. > Similarly, the DOM could be viewed as an API for a grove. Yes, to a single kind of grove, specifically an XML syntactic grove. (A grove governed by the properties of XML's syntax.) (Aside: I hope we're not facing a future in which the semantics of certain chosen vocabularies will be directly supported by future versions of the DOM. Such support should "plug into" (and be unpluggable from) the DOM. No vocabulary-specific support should become a required feature of all DOM implementations. For example, making XLink a vocabulary is fine; making the DOM able to support XLink but no other linking vocabularies would be the start of a long nightmare with a bad ending. To do that would significantly reduce the freedom of industries to design their own information architectures, and to evolve them according to their own perceived needs. It would also destroy the DOM, which must stay simple in order to survive. No API can do everything for everybody, and once you start putting support for DTD-specific (or namespace-specific) semantics into the DOM, where do you stop? I've watched a couple of systems bloat uncontrollably and meet their demise in similar ways, and the stage is perfectly set for the same thing to happen to the DOM.) > The XML information set is not a grove because ... it is not > ... expressed in grove notation. If you replace the word "grove" with "property set" (twice) in the above sentence, you are exactly correct. (There is no such thing as "grove notation". "Grove" is an abstract concept that, when sensibly implemented, makes a grove exactly as human readable as a hex dump of RAM in which there are C structs in no particular order.) > The DOM is not an API for a grove because it's a bit wishy-washy in > places -- for example, four characters of PCDATA could be one node > or four, so it's not built on a rigid enough data model.) Close enough. I would put the same thought differently: The DOM doesn't have a formalized underlying data model, so the DOM doesn't answer the need for a solid basis on which to express the addresses of the components of XML resources. I'm hoping and believing that after the XML infoset is done we'll have a basis for implementing a powerful version of XPath (or XPointers or whatever the idea of generalized addressing of components of XML resources is being called at that time). > The nice thing about groves is that all groves, regardless of what > they are built on, have certain commonalities, such as > addressability, so you can perform certain common functions with > them. Right. All nodes in groves have the same "object model" (I'm using this term in a more formal, scientific sense than the term is used in the phrase "Document Object Model (DOM)".) The grove object model is: Groves have nodes, nodes conform to classes, and classes have named properties with value constraints. Nodes have named properties, and values for those properties. That's about it; the rest is detail. (It's pretty interesting detail.) > GroveMinder is generic grove middleware. It has plug-ins, called > Minders (I think of them as drivers), Hooray, thank you! I have sometimes called them "notation drivers" only to get the blankest stares imaginable. (I then have asked something lame, like, "Do you know what a device driver is, and why we have them?") But you obviously get the point of Minders: Minders represent plug and play support for individual notations, in a system that makes all content look alike (i.e., conform to the grove object model). > that can build groves over different property sets. For example, > there is one Minder for SGML/XML documents and a different Minder > for relational databases. Well, actually, there's probably a one-to-one correspondence between property sets and database schemas. In order to address information in terms of its structure, you have to know the structure. In grove-land, the structure is defined by a property set. Different databases have different structures, normally expressed as database schemas. Making a database look like a grove is very straightforward. The bulk of the work is translating the schema into a property set (which is, after all, a kind of schema). There's a bit of coding involved, too, but the GroveMinder developer kit has tools that make this amazingly easy. (At least the Lockheed-Martin people were amazed, and they said so publicly at XML '98.) The grove paradigm breaks down the distinction between documents (resources) and databases. Everything, in its addressable form, is a grove, and a grove is a database. But a grove is convertible into an interchangeable resource (that is, if the property set is a comprehensive expression of the syntactic features of the notation of an interchangeable resource). Obviously, a resource is also convertible into a grove, given a property set for its notation. Property sets are the bridge between the world of information interchange, and the world in which interchanged information is immediately useful (i.e., the world in which information exists after parsing and common semantic processing of interchangeable resources has been done). If the resource is *already* a database, there's probably no parsing or processing involved. All that needs to be done is to put a translating layer over it that makes the database look like a grove. Then, the database and all its contents are fully able to participate in the wider world of interchangeable information resources: they can be linked, re-used by reference, have any kind of metadata associated with them, etc. etc. > (There can actually be different property sets for a "type" of > data. For example, one property set for XML might include entities > and another might not, specifying that each entity is replaced by > its value. A different Minder is needed for each property set.) Strictly speaking, you're correct: people can disagree about the properties of, say, PostScript as a notation, or they might agree about the properties but not about what the names of the properties should be. Nothing prevents people from writing their own property sets. In fact, however, the situation is not as chaotic as your example might lead one to believe, because of "grove plans". A "grove plan" is a way of selectively deleting properties from classes, and of deleting classes altogether, as a way of avoiding the overhead of storing and/or processing those properties and classes. For example, the property set for SGML is comprehensive, but an application may not need, for example, to store nonsignificant white spaces found in the start tags of SGML elements. The application may therefore use a "grove plan" to delete the properties whose values would be those white space characters. The addresses of nodes in groves are always expressed with respect to a property set and a grove plan. If it were not so, you wouldn't know whether to count a certain node type or not, when counting nodes to get to a particular node. And it's true that, for example, some people want to count the text that was inserted via an entity reference as a distinct node, while other people don't; this kind of flexibility is needed in order to keep peace in the family, and allow people to do addressing in the way they want to do it. Property sets are modularizable, so that it's relatively easy to express commonplace grove plans, to establish conformance levels for processing systems, and to understand the rules for interpreting address expressions. A Minder that implements a property set comprehensively can optionally view groves less comprehensively, so as to be able to resolve addresses that were expressed according to lesser grove plans. There doesn't have to be a different Minder for each different grove plan. (And that's where your example might be misleading.) > One thing GroveMinder can do is store a grove in its own > database. (Note that this is separate from the database addressed by > the relational database Minder -- it has a structure designed to > store groves.) Thus, GroveMinder can store an XML document in a > database as a grove and is what I, in my article, called a content > management systems. That is, it can store and retrieve an XML > document as a document. Sounds right to me. ("...its own database" sounds a bit odd because GroveMinder can use any ODBMS for grove storage.) > Some questions: > 1) Is it possible to combine groves of different types? For example, > can I take a grove representing a table in a relational database and > stuff it into a grove for an XML document, for example as the > content of an element? I'm afraid I don't grasp the intent of this question. When such an XML document is exported from its grove as an XML document, what should the document look like? There's no need (and no way) to stuff something into something else. It is only necessary that the "content" property of the element have, as its value, the node in the database grove that represents the table. The ISO standard SGML Property Set does not allow this; only certain classes of nodes within the same grove are allowed as the value of the "content" property of "element" nodes. However, if you want to change your operative SGML Property Set so that this will be permitted, nothing (other than good sense) prevents you from doing it; the grove paradigm will readily support you in your madness. I don't know why it would be sensible to regard an RDBMS table as the content of an SGML or XML element. The normal meaning of "content" is elements, character data, and/or other SGML constructs, right there, inside the element. There is no way to write a general purpose grove-to-SGML converter unless the classes of the nodes that can appear in element content are limited and known. (We certainly don't want to dump arbitrary data into the content of an element; this would invite a situation in which the document that is ultimately exported is unparsable.) > If so, does the table grove retain its table-ness, or is it > converted to one or more XML elements? Both cases seem reasonable, > although the latter would presumably require a special converter. If > the latter case is true, then GroveMinder might also fit what I call > data transfer middleware, depending on how the conversion is done. I would suggest that an efficient way to handle this would be to convert the table into node classes that *are* permitted to appear in element content, and then make *those* nodes the value of the content property. If you do it this way, you're necessarily making the decisions that must be made about how the XML document, when exported, will reflect the table data. You're right that one application of GroveMinder is data transfer middleware. The conversion program is comparatively easy to write, since everything already conforms to the same object model. > 2) Are groves themselves relevant at a high level in a discussion of > XML and databases? It strikes me that, like SAX and the DOM, they > are a useful tool in implementing software that stores/retrieves XML > documents (or data from those documents) in a database but are not > directly relevant to the discussion itself. Instead, they are most > relevant to the user in that they are likely to weigh heavily in the > feature set exposed by a content management system or (possibly) > data transfer system. Good question. I guess that's for the person who's doing the discussing to decide. Since groves can be persistent (e.g., stored in databases), and since XML resources can become groves, it seems to me that groves are relevant. You're right, the real reason they're interesting is their impact on feature sets. But aren't feature sets (and especially tradeoffs between feature sets) what technical discussions are all about? > 3) This isn't directly related to XML/databases, but what other > common functionality do all groves have? For example, can I write an > application that navigates groves, regardless of their source (I > think the answer is yes)? Yes. We have a demonstration of that. > Can I combine groves of different types or convert painlessly -- > that is, without writing any additional code -- from one type to > another (I think the answer is no -- additional code is needed)? Probably no, but it really depends on what you mean by "code." You have to decide how instances of nodes of particular classes and in particular contexts will be mapped onto instances of nodes of particular classes in the new context, and you have to express your decisions in a formal, machine processable fashion. Right now, using GroveMinder, you can do that with a Python script, which seems about as quick, intuitive, and flexible a way to do it as any. I don't know of any transformation specification language with which a similar feat (transforming one kind of grove into another kind of grove) can be done, except possibly DSSSL (which relies on (and was written in terms of) the grove paradigm, by the way). We haven't implemented DSSSL, but it shouldn't be too hard to do that on top of GroveMinder. Would you call a DSSSL transformation specification "code"? (I guess I would.) > Can I hyperlink from one grove to another (I think the answer is > yes)? Yes. The interesting thing here is that traversal can be initiated from any node in any grove, on account of a link in any grove, and traversal can be made to any node in any grove. Neither the traversal initiation point, nor the traversal target, has to be a linking construct. Neither has to "know" anything about the fact that they are actually anchors. > And so on. I'll provide you with a copy of the GroveMinder demo, if you like. There are lots of playful possibilities. Some people have even written their own HyTime documents to use with the demo software. It's a challenge for puzzle lovers, because the demo does not report errors in documents. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 fax +1 972 994 0087 pager (150 characters max): srn-page@techno.com 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Thu Sep 9 01:39:25 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:14:46 2004 Subject: ANN: XML and Databases article In-Reply-To: <14294.39104.190422.759370@localhost.localdomain> (message from David Megginson on Wed, 8 Sep 1999 13:14:35 -0400 (EDT)) References: <01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de> <14294.39104.190422.759370@localhost.localdomain> Message-ID: <199909082020.PAA02004@bruno.techno.com> [David Megginson:] > There aren't many people alive who actually know Groves (we couldn't > all fit in a Cessna, but we probably could squeeze into a Dash-8 > with a few empty seats), so it had no real familiarity advantage. <rant type=grove-paradigm-promoting> Groves are going to turn out to be like Linux, which began with a very few people who had a vision that turned out to work. As was the case with Linux in those early days, there is nobody doing big media advertising about it, and even the trade press, whose income is derived from such advertising, hasn't heard of groves very much. That will change. Linux has risen on the strength of the idea that people can and should be in direct control of their operating system, and that the result of such control will be increased human productivity. Similarly, groves will rise on the strength of the idea that people should be in direct control of their information. The product-differentiation barriers that vendors have set up around their customers' data must come down. There is no information that civilization can afford to leave out of the mainstream of information processing. XML is a step toward this goal, but it requires that the data be converted into XML; it will never happen that all data will be stored (or even interchanged) as XML. The grove paradigm brings the barriers down without necessitating data conversion. The grove paradigm lets the markup be elsewhere than inside the data. Even though groves are the technical foundation of the SGML, DSSSL, and HyTime international standards (respectively the proud, heavier-duty forerunners of XML, XSL, and XLink, among other W3C Recommendations), there is no money for groves precisely because system vendors have *less than no reason* to popularize this dangerous idea. As with Linux, however, that is the very reason why the grove paradigm will become commonplace: it will wring massive inefficiencies out of the software systems marketplace, and out of software systems. As everybody who attended Metastructures in Montreal last month knows, people who are into solving tough real-world information management problems, like DataChannel / ISOGEN, are selling and developing the grove paradigm as a core strategy, because they know that there is nothing else out there that compares to the power it brings to solving tough business problems, both technically and politically. Other system vendors cannot ignore this situation forever. It won't be too long before groves are a mass-market phenomenon (even if they're not called "groves" by then). The opportunities are almost unbelievably large. </rant> But don't worry, David: if you don't provide a property set for XML as part of the work of the XML infoset group, we'll take what you do produce and turn it into a property set. That way, it'll be machine processable as just another notation, by engine software that is just another plug-in to the wider world that includes all other notations, and all other database schemas. That will be a good thing, and we can't let a little matter of syntax stand in the way of progress. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 fax +1 972 994 0087 pager (150 characters max): srn-page@techno.com 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 simonstl at simonstl.com Thu Sep 9 01:59:45 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:46 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) In-Reply-To: <14294.54422.707751.653558@localhost.localdomain> References: <199909082116.RAA14362@hesketh.net> <199909082026.QAA11768@hesketh.net> <199909081810.OAA05438@hesketh.net> <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <14294.36560.725917.191918@localhost.localdomain> <14294.47066.957120.565534@localhost.localdomain> <14294.52037.477683.565382@localhost.localdomain> <199909082116.RAA14362@hesketh.net> Message-ID: <199909090002.UAA20519@hesketh.net> At 05:30 PM 9/8/99 -0400, David Megginson wrote: >> >There was no warning, however, that DTD syntax might change. >> >> I think you're overestimating the syntax changes being described. >>[...PIs, not syntax changes] > >My fault: I didn't realise that your proposed changes used only PIs. >I'm not sure that I see how the documents could still be valid from >the XML 1.0 perspective, though, and if not, the new documents would >still be backwards incompatible with some (many?) existing XML 1.0 >implementations. I'm not sure I'm quite off the hook yet. While the PI approach is nice because it doesn't have many side effects (it's easily ignored), I'm still trying to figure out if the processing shift might produce odd results in some situations. I think that most of the time, it'll be okay, but I'm still hunting for lurking weirdness. My _hope_ is that it'll be 100% backwards compatible with XML 1.0 DTD validation if the prefixes don't change, and that it'll let through the cases where the prefix changed but nothing else did. In that sense, it'd be incompatible - documents with good namespace matches would still spit out from validating XML 1.0 processors. That doesn't seem any worse than the current situation, but it's worth more thought. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 cbullard at hiwaay.net Thu Sep 9 02:21:47 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:47 2004 Subject: Why focus on HTML? References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca><37D3F74D.AA84B8FF@praxis.cz> <199909071317.JAA05607@hesketh.net> <014101bef937$73ad3040$1618ccce@pebbles> Message-ID: <37D6FD32.59EB@hiwaay.net> Dave Winer wrote: > > So, if you believe that, as I do, why not channel your energies into spaces > where there is no installed base? XML opens all kinds of possibilities. Why > not spread out and focus on implementations that use the net in new ways? Or > try out some new ideas. Why channel all the energy into a place where not > much can be done? > > My opinion only.. A good one. Consider the results if XML applications don't do what some tried with SGML applications: one size fits all consumers. Well, you get the reemergence of helper applications (or.. applets) as dominant species. Works for real audio. May be the best way to do 3D. Altogether, page integration is only meaningful to a given kind of page. On the other hand, using operating system services is easy to decouple when the protocols are commodities. For my money, the best idea of the Web was and is HTTP. The other good idea is MIME. Register types and interoperate through commodity interfaces. COM is the best CS invention of the 90s. HTML is GenCoding with Windows. Cool, because it works, but not much of a conceptual leap. We already know what happens if HTML is endlessly extended: MIL-D-28001. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Sep 9 02:21:44 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:47 2004 Subject: an unfilled need [ tie XML to Java ] References: <3.0.32.19990906085410.00b6d4e0@pop.intergate.bc.ca> <37D3F74D.AA84B8FF@praxis.cz> <37D4247B.4FD2@hiwaay.net> <00c001bef8ab$d1ab19a0$0a0a0a0a@deltabiz> Message-ID: <37D6F89C.5100@hiwaay.net> Steven Livingstone wrote: > > >Yes, tie XML to Java > > [ I have come into this discussion a bit late - where does this comment > originate? ] > > This statement seems to defeat the one of the purposes of XML. I am not (not > would want to) learn and use Java - for Web Applications there is no need > for having to use Java. I have done plenty of exciting XML-based work using > COM and scripting. Tie XML to Java in an application. That means one knows what is XML and what is application. If that works for the designer, it provides both portable data and an interoperable application within the virtual machine. If you have used COM to do that, you have tied your data to a COM-aware application. Works for me. Now, after one does that, what is still interoperable? len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Sep 9 02:58:59 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:47 2004 Subject: confidentiality in W3C WGs References: <199909071900.PAA25558@gw.sqwest.bc.ca> Message-ID: <37D70003.E62@hiwaay.net> Lauren Wood wrote: > I agree that technical reasons for why the spec is the way it is, and > reasons for change, should be made public. Particularly when the > issue is controversial, as this one is. Right. Do it the OldeFashionedWay: Document by paragraph number the text, the suggested edit to the text, the rationale for the technical change, the submittor. the reason for accepting or rejecting the change. There are some sage standards editors on this list (Dr. Goldfarb? Dr. Newcomb?) who can provide a precise format for this kind of document. It really is that easy. We can't fix the W3C. We can't fix the press. We can go our own way.... or we can state in earnest to whatever authority can provide support that the need for clearly documented public rationale for public utilities outweighs the need for confidentiality. Editing such documents before publishing them is good practice. Publishing blow by blow summaries of meeting debates is bad practice. There is plenty of experience in this community to explain those practices. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Thu Sep 9 04:07:04 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:14:47 2004 Subject: ANN: XML and Databases article In-Reply-To: <199909082341.SAA02016@bruno.techno.com> Message-ID: <NBBBJPGDLPIHJGEHAKBAKEHOEBAA.martind@netfolder.com> Hi Steven, Steven said: -------------------------------------------------- Probably no, but it really depends on what you mean by "code." You have to decide how instances of nodes of particular classes and in particular contexts will be mapped onto instances of nodes of particular classes in the new context, and you have to express your decisions in a formal, machine processable fashion. Right now, using GroveMinder, you can do that with a Python script, which seems about as quick, intuitive, and flexible a way to do it as any. I don't know of any transformation specification language with which a similar feat (transforming one kind of grove into another kind of grove) can be done, except possibly DSSSL (which relies on (and was written in terms of) the grove paradigm, by the way). We haven't implemented DSSSL, but it shouldn't be too hard to do that on top of GroveMinder. Would you call a DSSSL transformation specification "code"? (I guess I would.) Didier says: -------------------------------------------------- You're absolutely right Steven, yes DSSSL could be made inter-operable with grove engines quite easily. In fact, we are working on an interface for grove engines in the OpenJade project. Actually, OpenJade includes a SGML property set based grove and this grove "in memory" only (i.e. resident on the heap). This limitation could be removed by allowing other grove engines to be processed by DSSSL. I would also call DSSSL a transformation specification code either from a grove to a modified grove of from a grove into a flow object tree. How can we bridge the vision to the reality simply by sitting around the table and define the API between gove engines and transformation engines. The DOM only reflects a particular interface to a particular property set (If I can express myself that way). Obviously a grove is more than that (anyway you know that). So, why not work on a grove API, publish it, and then submit it to our collegues like those present in this list. Call to action: -------------- If anyone is interested by the task to define an API between grove engines and transformation engines (XSL or DSSSL for instance), please send me an email and we'll set a discussion group with the OpenJade team and you so that we all together define the Linux of markup technologies ;-). Then we will submit the document to other collegues for further discussion and feedback. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From davidc at nag.co.uk Thu Sep 9 10:15:14 1999 From: davidc at nag.co.uk (David Carlisle) Date: Mon Jun 7 17:14:47 2004 Subject: Is it possible to overwrite global variables? Message-ID: <199909090815.JAA21092@nag.co.uk> You'd probably be better asking xsl questions on xsl-list rather than xml-dev: XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list but anyway... The answer to your question is no, but don't despair:-) <xsl:if test="Cond1"> <!-- this sets GlobaleVariable in the current scope --> <xsl:variable name="GlobaleVariable" select="1"> <!-- the current scope ends here --> </xsl:if> <xsl:if test="Cond2"> <!-- this sets GlobaleVariable in the current scope --> <xsl:variable name="GlobaleVariable" select="2"> <!-- the current scope ends here --> </xsl:if> You don't want a condition to control whether or not to set a variable, you want to set a variable to an expression who's value depends on a condition: <xsl:variable name="GlobaleVariable"> <xsl:choose> <xsl:when test="Cond1"> <xsl:value-of select="...1"/> </xsl:when> <xsl:when test="Cond2"> <xsl:value-of select="...2"/> </xsl:when> </xsl:choose> </xsl:variable> David xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Veillard at w3.org Thu Sep 9 10:31:35 1999 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:14:47 2004 Subject: ANN: XML and Databases article In-Reply-To: <199909082020.PAA02004@bruno.techno.com> References: <01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de> <14294.39104.190422.759370@localhost.localdomain> <199909082020.PAA02004@bruno.techno.com> Message-ID: <19990909043413.A9400@w3.org> > Groves are going to turn out to be like Linux, which began with a very > few people who had a vision that turned out to work. As was the case > with Linux in those early days, there is nobody doing big media > advertising about it, and even the trade press, whose income is > derived from such advertising, hasn't heard of groves very much. That Hum, don't mix an match things at a different level. Linux got success because of two things: - it was pretty well defined, i.e. a reimplementation of the UNIX without any attemps to get into "research" or new semantic fields. So basically it was a implementation challenge not a research one. - The code source is available, moreover with a 'contaminating' licence at the kernel level, allowing it to grow it's community When faced with "groves" I still have a serious problem with both points: - Show me a definition so that I can understand the term and underlying concept clearly enough that an implementation time is spend not collecting and reading papers but implemening something well defined. Even reading http://www.prescod.net/groves/shorttut/ I still can't get a clear definition of "what is a grove precisely". Not at the concept level, but a implementable definition say on top of the XML infoset (for XML documents). - Show me the code. Not that there is none, I just don't know. Is there a program available in source code, that I can run on say a laptop in front of a novice (but programmer kind) audience (say a Gnome developper's group) allowing me in 3 mn to show a "grove" in action and what it does for them. Get both, and if you're lucky you will experience the same success as linux. In the meantime me and others are still wondering what's really behind that 5 letters word ! Daniel P.S.: Don't get me wrong, I not negative, mostly interrogative, and honnestly a bit puzzled by the comparison. Give me both (or even a set of clearly understandable graphics for the second point) and I can try to propagate that notion once i have understood it. -- 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, XML, http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From heiko.grussbach at crpht.lu Thu Sep 9 11:09:40 1999 From: heiko.grussbach at crpht.lu (heiko.grussbach@crpht.lu) Date: Mon Jun 7 17:14:47 2004 Subject: XML-Editors with pluggable validation Message-ID: <C12567E7.0031A4F5.00@mmfileserver.crpht.lu> Hi, XML-Editors usually let you edit an XML file, so that its valid against its corresponding DTD. How about application specific validation. Just an example, I want to make sure that an element "DATE" in the XML-Document contains a valid date, but I don't want to express what a "valid date" is in the DTD. So, whenever a user finishes editing a DATE element, my application code would have to be executed to see, if the text entered by the user is valid. Has anyone seen such an editor? Regards Heiko Heiko.Grussbach@crpht.lu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 11:36:06 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:47 2004 Subject: ANN: XML and Databases article Message-ID: <01BEFAB8.224F6E70@grappa.ito.tu-darmstadt.de> Steven R. Newcomb wrote: > > The nice thing about groves is that all groves, regardless of what > > they are built on, have certain commonalities, such as > > addressability, so you can perform certain common functions with > > them. > > Right. All nodes in groves have the same "object model" (I'm using > this term in a more formal, scientific sense than the term is used in > the phrase "Document Object Model (DOM)".) The grove object model is: > Groves have nodes, nodes conform to classes, and classes have named > properties with value constraints. Nodes have named properties, and > values for those properties. That's about it; the rest is detail. > (It's pretty interesting detail.) What other common functions can you perform besides addressing / hyperlinking? > > GroveMinder is generic grove middleware. It has plug-ins, called > > Minders (I think of them as drivers), > > Hooray, thank you! I have sometimes called them "notation drivers" > only to get the blankest stares imaginable. (I then have asked > something lame, like, "Do you know what a device driver is, and why we > have them?") But you obviously get the point of Minders: Minders > represent plug and play support for individual notations, in a system > that makes all content look alike (i.e., conform to the grove object > model). Actually, if you had said "notation driver" to me, I would have given you the same blank stare. The problem for me is not "driver", but "notation" -- it might mean something to SGML gurus, but is unlikely to mean much to the average programmer, who at least has a chance with "driver". I can't think of a simple generic term right off, but the following would do pretty handily -- "Just like you need a different ODBC driver for each brand of database, you need a different Minder for each type of data -- SGML document, database, email, Word documents, and so on." It's probably not quite technically correct, but it will get the point across. > > > that can build groves over different property sets. For example, > > there is one Minder for SGML/XML documents and a different Minder > > for relational databases. > > Well, actually, there's probably a one-to-one correspondence between > property sets and database schemas. In order to address information > in terms of its structure, you have to know the structure. In > grove-land, the structure is defined by a property set. Different > databases have different structures, normally expressed as database > schemas. Making a database look like a grove is very straightforward. > The bulk of the work is translating the schema into a property set > (which is, after all, a kind of schema). There's a bit of coding > involved, too, but the GroveMinder developer kit has tools that make > this amazingly easy. (At least the Lockheed-Martin people were > amazed, and they said so publicly at XML '98.) What do you mean by "different databases" here? If you mean relational databases v. hierarchical databases v. object-oriented databases, then there's no problem -- I would expect each to have a different property set. On the other hand, if you mean DB2 v. Oracle v. Informix v. SQL Server, then it seems there is something broken -- I would very much expect all relational databases to have the same property set. > The grove paradigm breaks down the distinction between documents > (resources) and databases. Everything, in its addressable form, is a > grove, and a grove is a database. Saying that a grove is a database strikes me as a bit misleading, at least in the database world. A grove is a database, in the sense that it contains data and you can extract that data, but in this sense, a spreadsheet is a database, a Word document is a database, a file system is a database, and so on. I think it would be more accurate to say that a database (in the traditional sense of the term) can be used to persist a grove, especially as you go on to say: > ... If the resource is *already* a database, there's > probably no parsing or processing involved. All that needs to be done > is to put a translating layer over it that makes the database look > like a grove. Then, the database and all its contents are fully able > to participate in the wider world of interchangeable information > resources: they can be linked, re-used by reference, have any kind of > metadata associated with them, etc. etc. > > > One thing GroveMinder can do is store a grove in its own > > database. (Note that this is separate from the database addressed by > > the relational database Minder -- it has a structure designed to > > store groves.) Thus, GroveMinder can store an XML document in a > > database as a grove and is what I, in my article, called a content > > management systems. That is, it can store and retrieve an XML > > document as a document. > > Sounds right to me. ("...its own database" sounds a bit odd because > GroveMinder can use any ODBMS for grove storage.) What I meant to do here was distinguish between the database that GroveMinder uses to store groves and other databases that might be external resources, such as that Informix database run by Billy Bob over in Engineering. (Granted, GroveMinder's database can undoubtedly be treated in a fashion similar to Billy Bob's database, but that's getting a bit self-referential and misses the point that GroveMinder runs just fine without Billy Bob's database but can't run without its own.) I'm also assuming that the database used by GroveMinder is configured for grove storage, although this might not be such an earth-shaking amount of work -- I'll take a guess that the class definitions are fed pretty much directly into the database as schema. > > > Some questions: > > > 1) Is it possible to combine groves of different types? For example, > > can I take a grove representing a table in a relational database and > > stuff it into a grove for an XML document, for example as the > > content of an element? > > I'm afraid I don't grasp the intent of this question. When such an > XML document is exported from its grove as an XML document, what > should the document look like? > > There's no need (and no way) to stuff something into something else. > It is only necessary that the "content" property of the element have, > as its value, the node in the database grove that represents the > table. The ISO standard SGML Property Set does not allow this; only > certain classes of nodes within the same grove are allowed as the > value of the "content" property of "element" nodes. However, if you > want to change your operative SGML Property Set so that this will be > permitted, nothing (other than good sense) prevents you from doing it; > the grove paradigm will readily support you in your madness. > > I don't know why it would be sensible to regard an RDBMS table as the > content of an SGML or XML element. The normal meaning of "content" is > elements, character data, and/or other SGML constructs, right there, > inside the element. There is no way to write a general purpose > grove-to-SGML converter unless the classes of the nodes that can > appear in element content are limited and known. (We certainly don't > want to dump arbitrary data into the content of an element; this would > invite a situation in which the document that is ultimately exported > is unparsable.) What I meant here was whether you could perform an operation similar to embedding an Excel spreadsheet in a Word document -- that is, can I (easily, generically, and without modification of property sets) combine information from different groves into a single grove. This would be extremely useful because it would be a step on the way towards being able to query the entire enterprise with requests such as, "Get me the names, addresses, and company prospectuses of all customers that I've sent email to in the last three days". The names and addresses come from the corporate database, the email information comes from my email, and the prospectuses come from a document database somewhere or perhaps the Web. The result could be navigable by a generic grove navigation tool. My guess is that groves right now give me this functionality by hyperlinking one grove to the next. This is fine in some cases (a grove-based query tool), not in others (wanting to expose tabular database data as XML). Actually, I would have been absolutely amazed if groves could do this without any sort of conversion software. (Note that when the Word document is persisted, the result isn't really a "Word" document, it's (if I've got my terminology right), an OLE Compound Document. When you get to the point where the spreadsheet is, Word no longer has a clue how to process it. Instead, there's a flag that says, "Yo! Go start Excel" and processing is handed over to Excel. A similar situation would be reasonable in a "compound" grove. It could easily be persisted to a grove database, which understands groves, but couldn't readily be persisted as XML or a database without conversion software. This is the fundamental difference between what I classify as data transfer middleware and content management systems. Data transfer middleware views the XML document as something it understand -- data -- and "converts" it to a database format; this is similar to Word storing a spreadsheet as a table. Content management systems view XML documents as documents and simply store them in a database rather than a text file.) > > If so, does the table grove retain its table-ness, or is it > > converted to one or more XML elements? Both cases seem reasonable, > > although the latter would presumably require a special converter. If > > the latter case is true, then GroveMinder might also fit what I call > > data transfer middleware, depending on how the conversion is done. > > I would suggest that an efficient way to handle this would be to > convert the table into node classes that *are* permitted to appear in > element content, and then make *those* nodes the value of the content > property. If you do it this way, you're necessarily making the > decisions that must be made about how the XML document, when exported, > will reflect the table data. Exactly. > You're right that one application of GroveMinder is data transfer > middleware. The conversion program is comparatively easy to write, > since everything already conforms to the same object model. I'm not quite sure I understand this. Above, you've just said you need to make decisions about how database node classes are converted to XML node classes, which makes sense to me. What do you mean by "everything already conforms to the same object model"? As far as I can tell, groves allow everything to be expressed as objects (which have a few common properties), but these objects are no more the "same object model" than a model for a person is the same as a model for a book. Groves may have gotten me from some other format (notation) into an object model, but whether converting one object to another is easy depends on the objects themselves. > > 2) Are groves themselves relevant at a high level in a discussion of > > XML and databases? It strikes me that, like SAX and the DOM, they > > are a useful tool in implementing software that stores/retrieves XML > > documents (or data from those documents) in a database but are not > > directly relevant to the discussion itself. Instead, they are most > > relevant to the user in that they are likely to weigh heavily in the > > feature set exposed by a content management system or (possibly) > > data transfer system. > > Good question. I guess that's for the person who's doing the > discussing to decide. Since groves can be persistent (e.g., stored in > databases), and since XML resources can become groves, it seems to me > that groves are relevant. You're right, the real reason they're > interesting is their impact on feature sets. But aren't feature sets > (and especially tradeoffs between feature sets) what technical > discussions are all about? In this case (since I'm the discusser ;) I'd say they're worth discussing in individual product descriptions, but not in the meat of the article, any more than a discussion of the DOM is relevant to the discussion. -- Ron xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From abcoates at TheOffice.net Thu Sep 9 11:49:36 1999 From: abcoates at TheOffice.net (Anthony B. Coates) Date: Mon Jun 7 17:14:47 2004 Subject: RFP: Namespace URI for HTML Message-ID: <199909090953.TAA20982@mail.internetezy.com.au> ** Reply to message from "Don Park" <donpark@docuverse.com> on Mon, 6 Sep 1999 22:50:56 -0700 Late proposal (sorry, not all of us get to read xml-dev in real time ...) > Current candidates: > > 0) "hell://no.stinking.namespace/4/HTML" > 1) "http://www.w3.org/Markup/" - by David Megginson > 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray > 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :) > 4) "http://www.xml.org/HTML/2000/Namespace" - (if Jon Bosak agrees) > 5) "http://www.w3.org/Namespace/HTML/" - by Don Park (2nd try) 6) Like 2/3/4, but change 1999 or 2000 to 19991225 (or as appropriate). How very hopeful indeed, to assume that there will never be the need for more than one version in a year. As it is, I can't be sure that the time of day shouldn't be included as well - who knows what "Web time" will mean to developers in 5 or 10 years time ... Actually, I really prefer the 3-namespaces idea: Strict, Transitional, etc. Cheers, Tony. ** Anthony B. Coates ** Software Engineer (Java). This is a 100% Pure Java e-mail. ** <mailto:abcoates@TheOffice.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 davidc at nag.co.uk Thu Sep 9 12:12:05 1999 From: davidc at nag.co.uk (David Carlisle) Date: Mon Jun 7 17:14:47 2004 Subject: fixing (just) namespaces and validation Message-ID: <199909091012.LAA18444@nag.co.uk> > We disagree. Not by much. > It is the parsers which cause the problem by ignoring the information > provided. > <!ATTLIST zap:x xmlns:zap CDATA #FIXED "http://here"> Ah interesting. But then the `problem' is that there is no REC or NOTE or hint or suggestion from anyone in authority that namespace aware validating parsers are _supposed_ to interpret xmlns: attribute declarations in this way. So when I said that `all dtds have the problem' You argue (and I would probably agree) that the problem is in the specification (or lack of) in how DTDs are used in the presence of namespaces. David Megginson argues that we shouldn't be using XML DTD if we are interested in namespaces, which is an argument, but I think I would still be in favour of an interpretation such as you suggest which allows a notion of validation with DTDs that does not break existing systems (they just say that the document doesn't validate) but would allow a class of documents to be DTD-validated by namespace aware systems without fixing prefixes. David xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From marko.zerdin at ixtlan-team.si Thu Sep 9 12:28:33 1999 From: marko.zerdin at ixtlan-team.si (Marko Zerdin) Date: Mon Jun 7 17:14:47 2004 Subject: MSXML for Java Questions Message-ID: <C96331EC2CDDD21191DC080009F1823B15995D@netstar.ixtlan.si> Hi everybody. 1) Does anybody know if Microsoft is going to support public (free) MSXML packages for Java? The signals from Microsoft have been far from unanimous. 2) I also have an interesting problem. I'm using Visual J++ for development environment, and com.ms.xml.om package for parsing XML (Document.load(InputStream) method, didn't try the other versions because I need just this one). The problem is with the following code (I've made it the shortest XML that produces this problem): <?xml version="1.0" encoding="ISO-8859-2"?> <Document> <Structures> <BankAccountInfo> <BankNumberCode>value</BankNumberCode> <BankAccountTypeID>value</BankAccountTypeID> <BankAccountPart1>value</BankAccountPart1> <BankAccountPart2>value</BankAccountPart2> <BankAccountPart3>value</BankAccountPart3> </BankAccountInfo> </Structures> <Messages> <Transactions> <t_Transaction> <CashAccount> <BankAccountInfo> <BankNumberCode>value</BankNumberCode> <BankAccountTypeID>value</BankAccountTypeID> <BankAccountPart1>value</BankAccountPart1> <BankAccountPart2>value</BankAccountPart2> <BankAccountPart3>value</BankAccountPart3> </BankAccountInfo> </CashAccount> </t_Transaction> </Transactions> </Messages> </Document> When I call the method Document.load(InputStream), I get the following error: Line 19, Column 44: Close tag BankAccountPart1 does not match start tag BankAccountPart1. I've also found out, that I don't have this error if I remove one letter from the tag (for example, if I replace BankAccountPart in the tags by BankAccountPar). If anybody knows the problem and is able to explain to me, what's the rule for this error to occur, I would really appreciate it. Regards, Marko. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Thu Sep 9 12:43:16 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:14:47 2004 Subject: ANN: XML and Databases article In-Reply-To: <19990909043413.A9400@w3.org> Message-ID: <NBBBJPGDLPIHJGEHAKBAEEIFEBAA.martind@netfolder.com> Hi Daniel, Daniel said: ------------------------------------------------ When faced with "groves" I still have a serious problem with both points: - Show me a definition so that I can understand the term and underlying concept clearly enough that an implementation time is spend not collecting and reading papers but implemening something well defined. Even reading http://www.prescod.net/groves/shorttut/ I still can't get a clear definition of "what is a grove precisely". Not at the concept level, but a implementable definition say on top of the XML infoset (for XML documents). Didier says: ------------------------------------------------ I agree with you on that point. Actually groves are defined as abstract entities and there is no common API to groves (each implementer ca define its own interface). Daniel says: ----------------------------------------------- - Show me the code. Not that there is none, I just don't know. Is there a program available in source code, that I can run on say a laptop in front of a novice (but programmer kind) audience (say a Gnome developper's group) allowing me in 3 mn to show a "grove" in action and what it does for them. Didier says: ----------------------------------------------- Easy, just use the "Linux of the markup technologies" aka OpenJade. The code is freely available, several developers around the globe are already improving it each day. The source code is stored on a CVS server and like I said, is freely available. OpenJade includes the SGML grove plan but the grove is transient (i.e. resident on the heap). This is a stand alone module that could be reused in other code. The grove is available as a DCOM object or a C++ object. You may make your own implementation if you want or change the interface. For more information: http://www.netfolder.com/DSSSL So, the first requirement is not yet fulfilled because actual documentation about groves (I mean public one) is not targeted toward concrete implementations and interface issues. Within the OpenJade project we are correcting this situation by documentation a concrete freely available component. But this is work in progress like it is for all open source projects. The second requirement is already fulfilled, you just have to get the code and play with it. Its free, the source is available and maintained by an international team. So, the best way to know what's behind these 5 letters is to simply take a look at the OpenJade project. I suggest also that you take a look at the PERL open source project because they too have included a grove manager in the PERL package. Did you noticed that PERL already implemented a Grove module? Regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Veillard at w3.org Thu Sep 9 14:28:09 1999 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:14:47 2004 Subject: ANN: XML and Databases article In-Reply-To: <NBBBJPGDLPIHJGEHAKBAEEIFEBAA.martind@netfolder.com> References: <19990909043413.A9400@w3.org> <NBBBJPGDLPIHJGEHAKBAEEIFEBAA.martind@netfolder.com> Message-ID: <19990909083042.E9400@w3.org> > Daniel said: > ------------------------------------------------ > When faced with "groves" I still have a serious problem with both > points: > - Show me a definition so that I can understand the term and > underlying concept clearly enough that an implementation > time is spend not collecting and reading papers but implemening > something well defined. > Even reading http://www.prescod.net/groves/shorttut/ I still can't > get a clear definition of "what is a grove precisely". > Not at the concept level, but a implementable definition say > on top of the XML infoset (for XML documents). > > Didier says: > ------------------------------------------------ > I agree with you on that point. Actually groves are defined as abstract > entities and there is no common API to groves (each implementer ca define > its own interface). Ok, having followed the http://www.netfolder.com/DSSSL/ link and looking at http://www.oasis-open.org/cover/topics.html#groves The following seems at least a clear and concise definition: In HyTime ISO/IEC 10744:1997 "3. Definitions (3.35)": graph representation of property values is 'An abstract data structure consisting of a directed graph of nodes in which each node may be connected to other nodes by labeled arcs. Ahhh ... and GROVE - "Graph Representation of Property Values." Ok, this becomes clearer. And the picture clarify it even more ! http://www.cogsci.ed.ac.uk/~ht/grove.html > Daniel says: > ----------------------------------------------- > - Show me the code. Not that there is none, I just don't know. > Is there a program available in source code, that I can run > on say a laptop in front of a novice (but programmer kind) > audience (say a Gnome developper's group) allowing me in 3 mn > to show a "grove" in action and what it does for them. > > Didier says: > ----------------------------------------------- > Easy, just use the "Linux of the markup technologies" aka OpenJade. The code > is freely available, several developers around the globe are already > improving it each day. The source code is stored on a CVS server and like I > said, is freely available. OpenJade includes the SGML grove plan but the > grove is transient (i.e. resident on the heap). This is a stand alone module > that could be reused in other code. The grove is available as a DCOM object > or a C++ object. You may make your own implementation if you want or change > the interface. For more information: > http://www.netfolder.com/DSSSL Ok, coincidentally i'm doing something similar it seems on top of my XML parser except that I based my node structure on a DOM point of view: http://rpmfind.net/veillard/XML/ Is there a clear distinction between the model exposed by a DOM API and a grove, I can't even find a single DOM reference in http://www.oasis-open.org/cover/topics.html#groves Looking at Henry graphic, it's nearly 100% equivalent to what I build so I'm wondering, but I remember people pointing out that those are different. thanks for the pointers, Daniel -- 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, XML, http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From philipnye at freenet.co.uk Thu Sep 9 15:07:30 1999 From: philipnye at freenet.co.uk (Philip Nye) Date: Mon Jun 7 17:14:47 2004 Subject: fixing (just) namespaces and validation References: <199909081037.LAA21158@nag.co.uk> <37D69791.652DF82A@mecomnet.de> Message-ID: <37D7B21B.5CF634E@freenet.co.uk> james anderson wrote: ... > > So, to validate with namespaces, you either have to pre-process the > > document instance to normalise the prefixes to the prefix used in the > > DTD, > > No, the processing happens in the course of parsing. There is no need for an > additional pass. No, it is better to map them all to a symbol associated with > the universal name. The prefixes are superfluous. Conceptually this is still pre-processing, even if the two are integrated in a single pass. If you are going to use the DTD at all, there is pre-processing to be done - transforming namespace references into a normalised prefix - and then there is post-processing - using the namespace to apply semantics of some sort to the document. This means that in David Megginson's layered model, the document bounces up and down between layers in an inelegant and to my mind very wasteful way, during the course of its processing. This is a result of the inflexibility of the DTD or perhaps of the incompatibility of namespaces. Either way Simon St.Laurent's original point will not go away. There is an incompatibility between DTDs and namespaces. To my mind these are orthogonal concepts and should not interfere with each other. Either DTDs change, or namespaces change, or you don't use them both or you put up with this sort of inelegant processing. Philip Nye Engineering Arts xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mnutter at fore.com Thu Sep 9 15:32:26 1999 From: mnutter at fore.com (Mark Nutter) Date: Mon Jun 7 17:14:47 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) In-Reply-To: <199909082020.PAA02004@bruno.techno.com> References: <14294.39104.190422.759370@localhost.localdomain> <01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de> <14294.39104.190422.759370@localhost.localdomain> Message-ID: <4.2.0.58.19990909093108.00b88c00@pophost1.fore.com> At 03:20 PM 09/08/99 -0500, you wrote: >Groves are going to turn out to be like Linux, which began with a very >few people who had a vision that turned out to work. Ok, you've got me all excited about groves. Where do I go to learn more about them? I have kind of a vague idea that a grove is basically a collection of trees. Is there a web site somewhere that will give me a broader understanding of the "grove paradigm"? -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Mark Nutter, <mnutter@fore.com> Internet Applications Developer FORE Systems Q: How many surrealists does it take to change a light bulb? A: A rubber pickle, because fish do *not* wear bow-ties. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 15:33:20 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:47 2004 Subject: fixing (just) namespaces and validation In-Reply-To: <37D7B21B.5CF634E@freenet.co.uk> References: <199909081037.LAA21158@nag.co.uk> <37D69791.652DF82A@mecomnet.de> <37D7B21B.5CF634E@freenet.co.uk> Message-ID: <14295.46046.647795.571535@localhost.localdomain> Philip Nye writes: > This means that in David Megginson's layered model, the document > bounces up and down between layers in an inelegant and to my mind > very wasteful way, during the course of its processing. This is a > result of the inflexibility of the DTD or perhaps of the > incompatibility of namespaces. The only reason for bouncing back to the XML layer is to take advantage of the fact that it *does* have a widely-implemented schema language: that's not a design problem with DTDs or Namespaces; it's just a (very kludgy) workaround because of the fact that the W3C's schema standards are still under development for the Namespaces layer. Besides, even if the W3C XML Schema WG released a schema REC tomorrow (which won't happen), and we all agreed that it was suitable, we wouldn't necessarily be any better off. After all, XML-Dev developed the DDML spec (which would also solve this problem) but no-one has decided to implement it yet, even though the list's membership consists almost entirely of developers. Having a spec is no guarantee of having implementations. 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 Thu Sep 9 15:50:04 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:47 2004 Subject: an unfilled need References: <3.0.6.32.19990907100342.009fa980@gpo.iol.ie> Message-ID: <37D5725A.48908DC9@prescod.net> Sean Mc Grath wrote: > > <Package> > <program language="Python"> > Bank.Debit ( (bllrp.zata * rte.w )/ GoldenRatio ) > </program> > <data> > <bllrp zata="-1"> > <poiuk>112</poiuk> > <pppzzz>g</pppzzz> > <ttt>xxx<rte w="3"/></ttt> > </bllrp> > </data> > </Package> > > This approach will get you there a lot faster than > waiting for the "bank debit golden ratio rte interest group" > to finalize their declarative syntax for what the bllrp > element really means... All you've done is shifted the problem from document type design to API design. Now you need the "bank debit golden ration rte interest group" to standardize their Bank objects and Debit methods. And anyhow, why bother with XML then? You might as well have said: <program language="Python"> data = bllrp( zata=-1, poiuk=112, pppzzz="g", ttt="xxx" ) Bank.Debit ( (bllrp.zata * rte.w )/ GoldenRatio ) </program> Which is exactly what Javascript programmers do today... Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From macherius at darmstadt.gmd.de Thu Sep 9 15:51:40 1999 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:14:47 2004 Subject: fixing (just) namespaces and validation In-Reply-To: <14295.46046.647795.571535@localhost.localdomain> References: <37D7B21B.5CF634E@freenet.co.uk> Message-ID: <199909091354.PAA06806@sonne.darmstadt.gmd.de> David Megginson <david@megginson.com> wrote at 9 Sep 99, 9:34: > After all, XML-Dev developed > the DDML spec (which would also solve this problem) but no-one has > decided to implement it yet, even though the list's membership > consists almost entirely of developers. Someone has implemented DDML, see www.extensibility.com. However, it's not open source. ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@gmd.de http://www.darmstadt.gmd.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Zappa) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at isogen.com Thu Sep 9 16:01:00 1999 From: robin at isogen.com (Robin Cover) Date: Mon Jun 7 17:14:47 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) In-Reply-To: <4.2.0.58.19990909093108.00b88c00@pophost1.fore.com> Message-ID: <Pine.GSO.3.96.990909090122.5315A-100000@grind> Re: > Is there a web site somewhere that will give me a > broader understanding of the "grove paradigm"? I try to maintain a collection of references on groves in the "Topics" section of the SGML/XML Web Page, viz., http://www.oasis-open.org/cover/topics.html#groves - Robin Cover ------------------------------------------------------ On Thu, 9 Sep 1999, Mark Nutter wrote: > At 03:20 PM 09/08/99 -0500, you wrote: > >Groves are going to turn out to be like Linux, which began with a very > >few people who had a vision that turned out to work. > > Ok, you've got me all excited about groves. Where do I go to learn more > about them? I have kind of a vague idea that a grove is basically a > collection of trees. Is there a web site somewhere that will give me a > broader understanding of the "grove paradigm"? > > -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- > > Mark Nutter, <mnutter@fore.com> > Internet Applications Developer > FORE Systems > > Q: How many surrealists does it take to change a light bulb? > A: A rubber pickle, because fish do *not* wear bow-ties. > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 Sep 9 16:02:49 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:48 2004 Subject: DDML (was Re: fixing (just) namespaces and validation) In-Reply-To: <199909091354.PAA06806@sonne.darmstadt.gmd.de> References: <14295.46046.647795.571535@localhost.localdomain> <37D7B21B.5CF634E@freenet.co.uk> Message-ID: <199909091405.KAA12334@hesketh.net> At 04:07 PM 9/9/99 +0200, Ingo Macherius wrote: >Someone has implemented DDML, see www.extensibility.com. However, >it's not open source. Extensibility's XML Authority - a schema editor for those who haven't seen it - will let you save DTDs to DDML format. It doesn't provide a DDML validation tool for use in processing. It's nice to see, especially for me, but it doesn't let you do anything with DDML in an application context. And no, it isn't open source, but it is at least cheap. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 digitome at iol.ie Thu Sep 9 16:24:56 1999 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:14:48 2004 Subject: an unfilled need In-Reply-To: <37D5725A.48908DC9@prescod.net> References: <3.0.6.32.19990907100342.009fa980@gpo.iol.ie> Message-ID: <3.0.6.32.19990909151750.009b6690@gpo.iol.ie> >Sean Mc Grath wrote: >> >> <Package> >> <program language="Python"> >> Bank.Debit ( (bllrp.zata * rte.w )/ GoldenRatio ) >> </program> >> <data> >> <bllrp zata="-1"> >> <poiuk>112</poiuk> >> <pppzzz>g</pppzzz> >> <ttt>xxx<rte w="3"/></ttt> >> </bllrp> >> </data> >> </Package> >> >> This approach will get you there a lot faster than >> waiting for the "bank debit golden ratio rte interest group" >> to finalize their declarative syntax for what the bllrp >> element really means... > [Paul Prescod] >All you've done is shifted the problem from document type design to API >design. Now you need the "bank debit golden ration rte interest group" >to standardize their Bank objects and Debit methods. But this only becomes an issue whenever there is a need to interface between disparate systems. Of course you need standards at that point -- be they APIs or Data Notations. Here is the point I was trying to make. If the algorithm to manipulate the data is downloaded *with* the data, then the browser meeds no apriori knowledge about the semantics of the data other than "Oh, here comes a package of stuff that has an algorithm part and a data structure part. Execute the algorithm part and hand it the data part to work with". Moreover, as an application developer I can do what I like with the package of data. I can attach any semantics I like to it. JavaScript is a case in point. Leaving aside any dislike for the language or the data model exposed to the language, it illustrates the "arbitrary semantics" point well. Case in point: There is no industry standard markup language for creating a collapsible table of contents in a Web page. There is a very nice one running on the Isogen site (http://www.isogen.com/papers.htm) written in JavaScript. Isogen did not have to wait for the W3C or Microsoft on Netscape or some committee to quabble endlessly over the markup language necessary to encode the semantics of a collapsible toc. >And anyhow, why bother with XML then? XML gives me a beautifully simply, open systems, way of expressing a hierarchical data structure. Why would I throw that away? <Sean URI="http://www.digitome.com/sean.html"> Developers Day Co-Chair, 9th International World Wide Web Conference 16-19, May, 2000, Amsterdam, The Netherlands http://www9.org </Sean> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken at bitsko.slc.ut.us Thu Sep 9 17:02:45 1999 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Mon Jun 7 17:14:48 2004 Subject: ANN: XML and Databases article In-Reply-To: "Didier PH Martin"'s message of "Thu, 9 Sep 1999 06:45:55 -0400" References: <NBBBJPGDLPIHJGEHAKBAEEIFEBAA.martind@netfolder.com> Message-ID: <m3vh9krurw.fsf@biff.bitsko.slc.ut.us> "Didier PH Martin" <martind@netfolder.com> writes: > Hi Daniel, > > Daniel said: > ------------------------------------------------ > When faced with "groves" I still have a serious problem with both > points: > - Show me a definition so that I can understand the term and > underlying concept clearly enough that an implementation > time is spend not collecting and reading papers but implemening > something well defined. > Even reading http://www.prescod.net/groves/shorttut/ I still can't > get a clear definition of "what is a grove precisely". > Not at the concept level, but a implementable definition say > on top of the XML infoset (for XML documents). > > Didier says: > ------------------------------------------------ > I agree with you on that point. Actually groves are defined as abstract > entities and there is no common API to groves (each implementer ca define > its own interface). > I suggest also that you take a look at the PERL open source project > because they too have included a grove manager in the PERL > package. Did you noticed that PERL already implemented a Grove > module? That would be the Data::Grove (in libxml-perl) module and it's only current set of node classes, the XML::Grove module. If you'd like to look at a very simple implementation of groves, those would be the ones. In Data::Grove, ``nodes'' are Perl objects (named, or ``blessed'', hashes), node-lists are Perl arrays, and named-node-lists are un-named, or ``anonymous'', hashes. Even though nodes are ``objects'' they are still accessed directly using Perl hash syntax (i.e. there are no accessor methods). (The same could be done as easily in any language, of course.) In the current implementation of Data::Grove the grove is ``passive'' -- the view, or ``grove plan'', of the grove is fixed at the time the grove is built, there's no support for enforcing constraints, and character data does not appear normalized. This differs from other grove implementations which I would call ``active'' -- the view of the grove can be changed dynamically, constraints are checked and/or enforced, and groves always appear normalized. Grove plans were described in another message, but an example is where you could choose to see entity reference nodes in the grove or just the characters that replace the entity reference. Groves are often compared to DOM. In grove terms, DOM Level 1 presents two very specific grove plans, Core and HTML. DOM defines these grove plans in terms of accessor methods for specific properties and a fixed set of constraints. In contrast, groves act more like generic containers. The API for accessing the generic containers is left to the implementation, property and value constraints are defined seperately, and the user is allowed to choose which set of property and value constraints to use at any particular time. Simply put, the idea behind groves is to seperate the definition of properties from the API used to access those properties. -- Ken MacLeod ken@bitsko.slc.ut.us xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schnitz at overflow.de Thu Sep 9 17:06:30 1999 From: schnitz at overflow.de (Sebastian Schnitzenbaumer) Date: Mon Jun 7 17:14:48 2004 Subject: RFP: Namespace URI for HTML Message-ID: <199909091609.SAA02326@server.overflow.de> Hi, > > 0) "hell://no.stinking.namespace/4/HTML" > > 1) "http://www.w3.org/Markup/" - by David Megginson > > 2) "http://www.w3.org/HTML/1999/namespace" - by Tim Bray > > 3) "http://www.w3.org/HTML/2000/Namespace" - by Don Park (I like zeros :) > > 4) "http://www.xml.org/HTML/2000/Namespace" - (if Jon Bosak agrees) > > 5) "http://www.w3.org/Namespace/HTML/" - by Don Park (2nd try) > > 6) Like 2/3/4, but change 1999 or 2000 to 19991225 (or as appropriate). How > very hopeful indeed, to assume that there will never be the need for more than > one version in a year. As it is, I can't be sure that the time of day shouldn't > be included as well - who knows what "Web time" will mean to developers in 5 or > 10 years time ... > > Actually, I really prefer the 3-namespaces idea: Strict, Transitional, etc. I'm very surprised that the list does not include the current approach taken by the HTML WG. This poll seems to suggest that one namespace for every flavor of XHTML is the only right choice. I agree with Tony and others who consider 3 namespaces as a possible solution. XHTML 1.0 strict: http://www.w3.org/TR/xhtml1/strict XHTML 1.0 transitional: http://www.w3.org/TR/xhtml1/transitional XHTML 1.0 frameset: http://www.w3.org/TR/xhtml1/frameset Regards, Sebastian Schnitzenbaumer --- Stack Overflow AG Phone: +49-89-767363-70 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mike.champion at sagus.com Thu Sep 9 17:19:30 1999 From: mike.champion at sagus.com (Michael Champion) Date: Mon Jun 7 17:14:48 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) References: <14294.39104.190422.759370@localhost.localdomain><01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de><14294.39104.190422.759370@localhost.localdomain> <4.2.0.58.19990909093108.00b88c00@pophost1.fore.com> Message-ID: <016401befad7$19d49f30$091d12d1@mccdell> >Groves are going to turn out to be like Linux, which began with a very >few people who had a vision that turned out to work. I'll start by making it clear that I've been on the W3C DOM working group for more than two years, so you know where my biases lie ... Nevertheless, I speak as someone who has spent a fair amount of time wrestling with defining abstract data models and APIs for XML documents and considering what the grove paradigm offers. There are three basic reasons why the DOM is not more groves-like. First, as someone pointed on earlier in the "XML and Databases" thread, not enough people outside the hard-core SGML/XML community understand the groves paradigm, so there was no general familiarity that we felt we should leverage. Second, the available documentation for groves (at least a couple of years ago) was mainly the DSSSL spec, which is very difficult for non-specialists to make sense out of. Third, there was a widespread perception that the groves model implies, in DOM terms, that "every character is a node", and people concerned about implementing the DOM API felt strongly that this would lead to unacceptable footprint and run-time overhead. Groves may or may not become the next Linux; if this is going to happen, two obstacles must be overcome. Most importantly, someone is going to have to write a *clear* statement of the paradigm, its power, why it's "the next big thing, etc. Sortof "Groves for Dummies", or the "Grove Manifesto". I can't stress enough the importance of writing this for a fairly general audience. I recall conversations a couple of years ago with very smart technical marketing people at large companies who are now big players in the XML world; the level of fustration they expressed at trying to make sense out of things like the DSSSL spec was quite memorable! I have not read the recent attempts by groves adovocates to offer tutorials, etc., so forgive me if this has already been done. I frankly doubt it, because if a clear and compelling case for the groves paradigm has been made, it hasn't come to the world's attention. Also, even if the "grove paradigm" is a fundamentally more powerful way of looking at XML and other types of data than what is in wide use today, it's unlikely to be adopted unless there is a clean migration path from familiar APIs like ODBC/SQL, the W3C DOM, the (forthcoming?) JCP XML data binding spec, etc. One of the most eye-opening aspects of my experience on the DOM WG has been to understand that most users of Web scripting languages, Visual Basic, etc. know very little about computer science. I began my DOM "career" assuming that everyone who would be using such APIs understood tree and graph data structures and would understand how nicely they represented the types of things we were talking about. I was quickly set straight by my colleagues from companies with larger customer bases: ARRAYS are about as sophisticated a data structure as the typical Web scripter or VB programmer can handle. [I *know* that someone reading this wants flame me, but rest assured that I don't like this notion any more than you do, and just about every conceivable counter-argument has been raised, and very reluctantly dismissed, by the DOM WG already.] So, I would *love* to see someone define a grove API that extends the DOM, and/or to see the grove paradigm cleanly incorporated into the Java Community Process XML data binding, and/or to see a repository-friendly API that builds from ADO or JDO and incorporates groves concepts. But don't expect the typical consumer of XML APIs to be impressed by a groves API that offers a "new paradigm" that assumes that the reader understands graph theory and data structures and builds up from there with little reference to existing efforts. Mike Champion xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 17:35:37 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:48 2004 Subject: ATTN: Please comment on XHTML (before it's too late) References: <872567E5.0077E475.00@d53mta03h.boulder.ibm.com> Message-ID: <37FF5306.ADB5D501@prescod.net> roddey@us.ibm.com wrote: > > >Adding three lines of code introduces the opportunity for three times > >the bugs in a real application? I don't buy it. Looking for "HTML 4.0 > >strict" OR "HTML 4.0 frameset" is no harder than looking for "UL" OR > >"OL", if the software is set up right. > I think its more complex than that. Its more than adding 3 lines of code. What > if you want to validate the XHTML? I can validate all three variants of XHTML using parsers that are three years old already!!!! Download the DTD, download nsgmls or IE5 and try it yourself! Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ejfreed at infocanvas.com Thu Sep 9 17:46:25 1999 From: ejfreed at infocanvas.com (Erik James Freed) Date: Mon Jun 7 17:14:48 2004 Subject: MSXML for Java Questions In-Reply-To: <C96331EC2CDDD21191DC080009F1823B15995D@netstar.ixtlan.si> Message-ID: <NCBBICOBAHLCGGGGCEIECEFAELAB.ejfreed@infocanvas.com> I am not sure I understand question #1, but if it helps, I know is that microsoft has in some way backed the company datachannel who supply a java version of its IE5 xml/xsl com components. This product came out earlier this year. (see www.datachannel.com) . Though their documentation does not at all suggest this, datachannel is *not* providing commercial support for this product unless you pay $5K per year. (!) The other problem is that there are those who believe that this product is far from production worthy, and it is definitely far behind other XML/XSL products in keeping up with current releases of standards. To make matters even worse, both companies refuse to make a public statement in regards to any of these issues and their intentions. Thus one pretty much has to either cough up $5K on the off chance that this makes any difference (I have my doubts), or do what we ended up doing, porting off of their product to IBM (or whatever) Interestingly, i think that this is going to really hurt XML/XSL because most serious app developers would like to use a decent java package for server development, but the most prevalent client environment is IE5 which is turning out to be significantly different. This means that server XML/XSL and client XML/XSL de facto standards are now divergent. It remains to be seen what MS and or datachannel have up their sleeve, but right now it is kind of bleak for those like our company that would benefit a lot from identical server and client standards for XML and XSL (T) I personally am waiting to see how commercial licenses work with the major vendors. The best seems to be IBM who give away source and pretty open licenses for no charge (I am no lawyer, so YMMV) good luck, erik -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Marko Zerdin Sent: Thursday, September 09, 1999 3:32 AM To: 'xml-dev@ic.ac.uk' Subject: MSXML for Java Questions Hi everybody. 1) Does anybody know if Microsoft is going to support public (free) MSXML packages for Java? The signals from Microsoft have been far from unanimous. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 17:50:26 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:48 2004 Subject: DOM and Grove References: <19990909043413.A9400@w3.org> <NBBBJPGDLPIHJGEHAKBAEEIFEBAA.martind@netfolder.com> <19990909083042.E9400@w3.org> Message-ID: <37FF5D1E.77AEECB6@prescod.net> Imagine that you had been trained for several years on the ODBC API. Now you go to university and a professor starts talking about the "relational database model." You might ask: "how is that different than ODBC." The answer is that ODBC is a particular representation of the relational model for programming languages. The DOM can be considered a particular representation of the grove model for programming languages. But the ODBC versus relational model is not quite sufficient to capture the difference. ODBC was built on top of the relational model. The DOM people used the grove model "for ideas" but the DOM is not based on any well-defined abstract model at all -- not the grove, not the information set, not the relational model, not anything. This is reflected in its odd mix of methods, properties and names "getElementsByTagName" "TagName", "NodeValue" etc. It's notion of iteration and state is famous for being rather odd. The DOM is more like a pre-relational API in this regard. The major difference between the DOM and an API that could be built on top of groves (such as that created by James Clark or by GroveMinder) is that the DOM model is to add support for different data types one by one through a central committee. But the important thing to recognize is that the grove is not an API. It can get lost in Steve's understandable focus on GroveMinder but the use of the grove as an API is an implementation optimization (in the sense of optimizing programmer time). The real reason groves were invented was to answer the question: * what is the result of hyperlinking into an arbitrary media type? What are the properties of the abstract object returned? The grove answers that question: the object has properties such as "parent", (possibly null), "children" (possibly null), "containing entity" and so forth. You cannot build a sophisticated hypertext system without answering that question. This will become apparent after XLink, XPointer and RDF are implemented. We'll start to see many divergences of behavior when links are made into (e.g.) PDF, MPEGs, JPEGs and so forth. Over time we will need to develop a framework for describing the correct results of links in a generic way. Then we will reinvent groves. Or not... we could keep doing things in an ad hoc manner for ever I suppose. It would be expensive and inefficient but it is possible. Paul Prescod Daniel Veillard wrote: > > > Daniel said: > > ------------------------------------------------ > > When faced with "groves" I still have a serious problem with both > > points: > > - Show me a definition so that I can understand the term and > > underlying concept clearly enough that an implementation > > time is spend not collecting and reading papers but implemening > > something well defined. > > Even reading http://www.prescod.net/groves/shorttut/ I still can't > > get a clear definition of "what is a grove precisely". > > Not at the concept level, but a implementable definition say > > on top of the XML infoset (for XML documents). > > > > Didier says: > > ------------------------------------------------ > > I agree with you on that point. Actually groves are defined as abstract > > entities and there is no common API to groves (each implementer ca define > > its own interface). > > Ok, having followed the http://www.netfolder.com/DSSSL/ link and > looking at http://www.oasis-open.org/cover/topics.html#groves > The following seems at least a clear and concise definition: > In HyTime ISO/IEC 10744:1997 "3. Definitions (3.35)": graph > representation of property values is 'An abstract data structure > consisting of a directed graph of nodes in which each node may be > connected to other nodes by labeled arcs. > > Ahhh ... and > > GROVE - "Graph Representation of Property Values." > > Ok, this becomes clearer. > And the picture clarify it even more ! > > http://www.cogsci.ed.ac.uk/~ht/grove.html > > > Daniel says: > > ----------------------------------------------- > > - Show me the code. Not that there is none, I just don't know. > > Is there a program available in source code, that I can run > > on say a laptop in front of a novice (but programmer kind) > > audience (say a Gnome developper's group) allowing me in 3 mn > > to show a "grove" in action and what it does for them. > > > > Didier says: > > ----------------------------------------------- > > Easy, just use the "Linux of the markup technologies" aka OpenJade. The code > > is freely available, several developers around the globe are already > > improving it each day. The source code is stored on a CVS server and like I > > said, is freely available. OpenJade includes the SGML grove plan but the > > grove is transient (i.e. resident on the heap). This is a stand alone module > > that could be reused in other code. The grove is available as a DCOM object > > or a C++ object. You may make your own implementation if you want or change > > the interface. For more information: > > http://www.netfolder.com/DSSSL > > Ok, coincidentally i'm doing something similar it seems on top of my XML > parser except that I based my node structure on a DOM point of view: > > http://rpmfind.net/veillard/XML/ > > Is there a clear distinction between the model exposed by a DOM API > and a grove, I can't even find a single DOM reference in > http://www.oasis-open.org/cover/topics.html#groves > > Looking at Henry graphic, it's nearly 100% equivalent to what I build > so I'm wondering, but I remember people pointing out that those are > different. > > thanks for the pointers, > > Daniel > > -- > 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, XML, > http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe. > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > FFrom zope-admin@zope.org Thu Sep 9 07:46:39 1999 > Received: from lambe.pair.com (lambe.pair.com [209.68.1.135]) > by amati.techno.com (8.8.8/8.8.8) with ESMTP id HAA02271 > for <prescod@amati.techno.com>; Thu, 9 Sep 1999 07:46:33 -0500 > Received: from zope.codeit.com (www.zope.org [209.67.167.110]) by lambe.pair.com (8.9.1/8.6.12) with ESMTP id IAA18429 for <paul@prescod.net>; Thu, 9 Sep 1999 08:46:32 -0400 (EDT) > X-Envelope-To: <paul@prescod.net> > Received: from www2 (localhost [127.0.0.1]) > by zope.codeit.com (8.9.2/8.8.7) with ESMTP id FAA05917; > Thu, 9 Sep 1999 05:37:21 -0700 (PDT) > Received: from erwin.complete.org (erwin.complete.org [209.197.212.34]) > by zope.codeit.com (8.9.2/8.8.7) with ESMTP id FAA05895 > for <zope@zope.org>; Thu, 9 Sep 1999 05:37:15 -0700 (PDT) > Received: (from jgoerzen@localhost) > by erwin.complete.org (8.9.3/8.9.3/Debian/GNU) id HAA01185; > Thu, 9 Sep 1999 07:36:55 -0500 > Sender: jgoerzen@erwin.complete.org > To: "Phillip J. Eby" <pje@telecommunity.com> > Cc: zope@zope.org > Subject: Re: [Zope] <!--#local--> and <!--#set--> (was Re: Proper way to set variables) > References: <John Goerzen's message of "Sun, 5 Sep 1999 23:08:39 -0500"> <199909060408.XAA26630@erwin.complete.org> <3.0.5.32.19990908171639.0090f6e0@telecommunity.com> > Mime-Version: 1.0 (generated by tm-edit 7.108) > Content-Type: text/plain; charset=US-ASCII > From: John Goerzen <jgoerzen@complete.org> > Date: 09 Sep 1999 07:36:55 -0500 > In-Reply-To: "Phillip J. Eby"'s message of "Wed, 08 Sep 1999 17:16:39 -0500" > Message-ID: <87btbc5kig.fsf@erwin.complete.org> > Lines: 56 > X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" > Sender: zope-admin@zope.org > Errors-To: zope-admin@zope.org > X-Mailman-Version: 1.0b8 > Precedence: bulk > List-Id: Users of the Z Object Publishing Environment <zope.zope.org> > X-BeenThere: zope@zope.org > > Excellent, this sounds like exactly what I need to fix. Can you send > the patch along to me? > > "Phillip J. Eby" <pje@telecommunity.com> writes: > > > At 02:02 PM 9/8/99 -0500, John Goerzen wrote: > > >Heh, feels strange to reply to myself, but as I got no replies before, > > >maybe I need to elaborate a bit. The original question is below. > > > > > >My main confusion is just how do I set a variable that is dynamically > > >scoped without having to use dtml-with or dtml-let, both of which > > >require matching closing tags? > > > > > > > FYI, I have just written a patch for DT_Let.py that adds two new tags, > > 'local' and 'set'. They are used like this: > > > > <!--#local myvar1="0" myvar2=somevar--> > > > > > > <!--#set myvar1="myvar1+myvar2"--> > > ... > > <!--#set myvar2="myvar2+1"--> > > > > <!--#/local--> > > > > > > Both <!--#local--> blocks and <!--#set--> tags are dynamically scoped and > > <!--#set--> can be used anywhere as long as there is an enclosing > > <!--#local--> block defining the variable you want to set. You can only > > set variables which are defined by the innermost <!--#local--> block, but > > you can reset their value any number of times, even within the same > > <!--#set--> tag. > > > > I am currently testing this code in an alpha app, but will be submitting it > > some time in the near future to Digital Creations for consideration of > > inclusion in future Zope versions. > > > > > > _______________________________________________ > > Zope maillist - Zope@zope.org > > http://www.zope.org/mailman/listinfo/zope > > > > (To receive general Zope announcements, see: > > http://www.zope.org/mailman/listinfo/zope-announce > > > > For developer-specific issues, zope-dev@zope.org - > > http://www.zope.org/mailman/listinfo/zope-dev ) > > > > -- > John Goerzen Linux, Unix consulting & programming jgoerzen@complete.org | > Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org | > ----------------------------------------------------------------------------+ > The 176,239,285th prime number is 3,697,131,523. > > _______________________________________________ > Zope maillist - Zope@zope.org > http://www.zope.org/mailman/listinfo/zope > > (To receive general Zope announcements, see: > http://www.zope.org/mailman/listinfo/zope-announce > > For developer-specific issues, zope-dev@zope.org - > http://www.zope.org/mailman/listinfo/zope-dev ) > > rom python-list-request@cwi.nl Thu Sep 9 07:46:40 1999 > Received: from smv03.iname.net (lmtp06.iname.net [165.251.8.61]) > by amati.techno.com (8.8.8/8.8.8) with SMTP id HAA02274 > for <prescod@amati.techno.com>; Thu, 9 Sep 1999 07:46:33 -0500 > Received: from hera.cwi.nl (hera.cwi.nl [192.16.191.1]) > by smv03.iname.net (8.9.3/8.9.1SMV2) with ESMTP id IAA05852 > for <papresco@technologist.com> sent by <python-list-request@cwi.nl>; Thu, 9 Sep 1999 08:46:32 -0400 (EDT) > Received: from localhost by hera.cwi.nl with ESMTP > id OAA04566; Thu, 9 Sep 1999 14:31:17 +0200 (MET DST) > From: Guido van Rossum <guido@cnri.reston.va.us> > Newsgroups: comp.lang.python > Subject: Re: SocketServer on NT slow for large transactions > Date: 09 Sep 1999 08:11:28 -0400 > X-Organization: Corporation for National Research Initiatives > Message-ID: <5logfc474f.fsf@eric.cnri.reston.va.us> > References: <7r7ipf$lqj$1@news.duke.edu> > X-Trace: ffx2nh5.news.uu.net 936879095 16700 132.151.1.38 (9 Sep 1999 12:11:35 GMT) > X-Complaints-To: news@ffx2nh5.news.uu.net > X-Newsreader: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" > To: python-list@cwi.nl > Sender: python-list-request@cwi.nl > Errors-To: python-list-request@cwi.nl > > "eric jones" <ej@ee.duke.edu> writes: > > > I wrote a very simple program using based on the > > SocketServer.StreamRequestHandler, and found that it crawled along at a > > snails pace. I've traced the problem to the socket._fileobject. > > Yes. This has been fixed in the CVS version though -- see > python.org/download/cvs.html. > > --Guido van Rossum (home page: http://www.python.org/~guido/) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 17:55:54 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:48 2004 Subject: ATTN: Please comment on XHTML (before it's too late) In-Reply-To: <37FF5306.ADB5D501@prescod.net> References: <872567E5.0077E475.00@d53mta03h.boulder.ibm.com> Message-ID: <199909091558.LAA17320@hesketh.net> At 07:36 AM 10/9/99 -0700, Paul Prescod wrote: >roddey@us.ibm.com wrote: >> >> >Adding three lines of code introduces the opportunity for three times >> >the bugs in a real application? I don't buy it. Looking for "HTML 4.0 >> >strict" OR "HTML 4.0 frameset" is no harder than looking for "UL" OR >> >"OL", if the software is set up right. > >> I think its more complex than that. Its more than adding 3 lines of code. What >> if you want to validate the XHTML? > >I can validate all three variants of XHTML using parsers that are three >years old already!!!! Download the DTD, download nsgmls or IE5 and try >it yourself! If all you care about is the prefixes, of course you can. If you actually want the URIs, it's a lot more complicated, as we've been discussing for the last few days. (Unless, of course, nsgmls was built with the discussions we've had in the last week regarding namespaces and validation in mind, which would involve a remarkable amount of foresight.) Now returning to my usual program of Central New York AM radio, Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 ejfreed at infocanvas.com Thu Sep 9 18:04:28 1999 From: ejfreed at infocanvas.com (Erik James Freed) Date: Mon Jun 7 17:14:48 2004 Subject: MSXML for Java Questions In-Reply-To: <NCBBICOBAHLCGGGGCEIECEFAELAB.ejfreed@infocanvas.com> Message-ID: <NCBBICOBAHLCGGGGCEIECEFBELAB.ejfreed@infocanvas.com> oops! I should mention that the term 'commercial support' means that they actually fix simple trivially demonstrable showstopping bugs... Of course there were no guarantees expressed about when. erik -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Erik James Freed Sent: Thursday, September 09, 1999 8:50 AM To: Marko Zerdin; xml-dev@ic.ac.uk Subject: RE: MSXML for Java Questions I am not sure I understand question #1, but if it helps, I know is that microsoft has in some way backed the company datachannel who supply a java version of its IE5 xml/xsl com components. This product came out earlier this year. (see www.datachannel.com) . Though their documentation does not at all suggest this, datachannel is *not* providing commercial support for this product unless you pay $5K per year. (!) The other problem is that there are those who believe that this product is far from production worthy, and it is definitely far behind other XML/XSL products in keeping up with current releases of standards. To make matters even worse, both companies refuse to make a public statement in regards to any of these issues and their intentions. Thus one pretty much has to either cough up $5K on the off chance that this makes any difference (I have my doubts), or do what we ended up doing, porting off of their product to IBM (or whatever) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken_north at compuserve.com Thu Sep 9 18:05:15 1999 From: ken_north at compuserve.com (Ken North) Date: Mon Jun 7 17:14:48 2004 Subject: ANN: XML and Databases article References: <01BEFAB8.224F6E70@grappa.ito.tu-darmstadt.de> Message-ID: <002301befadd$917f2d60$0b00a8c0@grissom> Subject: RE: ANN: XML and Databases article > Ronald Bourret wrote > Steven R. Newcomb wrote: > What do you mean by "different databases" here? If you mean relational > databases v. hierarchical databases v. object-oriented databases, then > there's no problem -- I would expect each to have a different property set. > On the other hand, if you mean DB2 v. Oracle v. Informix v. SQL Server, > then it seems there is something broken -- I would very much expect all > relational databases to have the same property set. There are a few points that haven't been made in this discussion. It's a mistake to classify DB2, Oracle, Informix, and SQL Server as relational DBMSs having the same logical data model. DB2, Oracle, Informix, and Microsoft SQL Server are all SQL DBMSs, but the first three are object-relational products. They have extensible architectures so you can add user-defined types and user-defined methods to customize a database. You can add custom access methods and indexes by writing server extensions. You can install Java classes in a database to add types and methods (http://www.devx.com/upload/free/features/javapro/1999/03mar99/kn0399/kn0399 .asp) There is a distinction between an active database and a passive data store. You can embed logic in active databases, so they can act as event alerters and rule enforcers (e.g., reject data that isn't within a certain range of values). Finally, the days when SQL DBMSs stored only columns of number and characters are gone. Some still do, but that is not a defining characteristic. Most of the major SQL vendors moved to a universal server model that supports rich types as well as traditional tabular data. For storing an XML document, you have the option of decomposing it or storing it as a whole. query tool), not in others (wanting to expose tabular database xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 9 18:27:38 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:48 2004 Subject: MSXML for Java Questions References: <NCBBICOBAHLCGGGGCEIECEFAELAB.ejfreed@infocanvas.com> Message-ID: <37D7E05B.D4BD233F@pacbell.net> Erik James Freed wrote: > > The other problem is that there are those who believe that this product is > far from production worthy, and it is definitely far behind other > XML/XSL products in keeping up with current releases of standards. To make > matters even worse, both companies refuse to make a > public statement in regards to any of these issues and their intentions. Depends what you mean by "public statement". I count leaving major bugs as unfixed to be significant statements. Microsoft bundling the rather ancient MSXML into their latest version of a Java VM _without bugfixes_ is yet another sort of statement. (About standards and perhaps DataChannel.) > This means that server XML/XSL and client XML/XSL de facto standards are now > divergent. It remains to be seen what MS and or > datachannel have up their sleeve, but right now it is kind of bleak for > those like our company that would benefit a lot from identical > server and client standards for XML and XSL (T) I'd put it differently: the XML/XSL standards are pretty clear, but what's lacking is browser support, and there's no announced path whereby Microsoft's browsers will conform. There may yet be such a path -- but folk have been asking for conformance for some time, and not seeing it. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From macherius at darmstadt.gmd.de Thu Sep 9 18:40:07 1999 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:14:48 2004 Subject: ANN: XML and Databases article In-Reply-To: <002301befadd$917f2d60$0b00a8c0@grissom> Message-ID: <199909091642.SAA16413@sonne.darmstadt.gmd.de> Ken North <ken_north@compuserve.com> wrote at 9 Sep 99, 9:08: > Finally, the days when SQL DBMSs stored only columns of number and > characters are gone. Some still do, but that is not a defining > characteristic. Most of the major SQL vendors moved to a universal server > model that supports rich types as well as traditional tabular data. For > storing an XML document, you have the option of decomposing it or storing it > as a whole. Right, but the price is implementing stored procedures. I dunno how the good Oracle 8i interfaces are, but with Informix it's no fun. We did it, and abadoned it. The other problem is you can store XML, but have to explicitely model relations (parent, sibling, child, ... and all other axis you need) by foreign keys. The number of "metatables" with structural information quickly outnumbers the useful data. Again we tried, benched and canceled. Is there a paper, page or software that can store XML along with it's structural information in a RDBMS, be it classic or OO-relational, you are thinking of ? Currently we are investigating our PDOM, which just maps between a W3C-DOM and persistent streams of serialized Java objects (paper will be at OOPSLA99). Instead of modeling structure we try to scale by means of intelligent, specialized cache strategies. Results are promising. Guido Moerkotte and C-C Kanne from the Univerity of Mannheim are working on intelligent clustering strategies, which try to keep trees in clusters suited for typical XML access patterns. They also have means to cluster better when given semantic user constraints on granularity. While we currently work with the DOM, the results could be easily applied to Groves. However, giving up the DOM would mean to lose lots of handy middleware. Our XQL processor has to work on a well defined data structure, the DOM is sufficient for now. Paul Prescod in his Grove tutorial precisely points DOMs weaknesses, but there is nothing to replace it right now. We discussed to use the Infoset as a data model, but its hard to write an optimizing XQL processor against a model where half the features are either optional or not present (schema stuff). Especially the fact you can't tell how many children a node will have (e.g. when some are optional, or only present when validating) is not what I call a well defined model for queries. ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@gmd.de http://www.darmstadt.gmd.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Zappa) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ejfreed at infocanvas.com Thu Sep 9 18:58:40 1999 From: ejfreed at infocanvas.com (Erik James Freed) Date: Mon Jun 7 17:14:48 2004 Subject: MSXML for Java Questions In-Reply-To: <37D7E05B.D4BD233F@pacbell.net> Message-ID: <NCBBICOBAHLCGGGGCEIEOEFCELAB.ejfreed@infocanvas.com> Good points Dave. I used to be very happy with MS for being so aggressive with XML and XSL with their IE5 product. I was naive enough to not think through the rather obvious fact that once it was out, there was not a lot of pressure to keep up. The phrase 'de facto' is the operative one. Our company just ignores the capabilities of IE5 and since we use a downloaded activex java control, we just load in a stripped down version of xml and xsl. While this ends up making our plugin larger, we have the advantage of identical server and browser processing, as well as portability across browsers. I also kind of like the idea of just ignoring IE5 XML/XSL until they get their act together. erik -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of David Brownell Sent: Thursday, September 09, 1999 9:29 AM To: xml-dev@ic.ac.uk Subject: Re: MSXML for Java Questions Erik James Freed wrote: > > The other problem is that there are those who believe that this product is > far from production worthy, and it is definitely far behind other > XML/XSL products in keeping up with current releases of standards. To make > matters even worse, both companies refuse to make a > public statement in regards to any of these issues and their intentions. Depends what you mean by "public statement". I count leaving major bugs as unfixed to be significant statements. Microsoft bundling the rather ancient MSXML into their latest version of a Java VM _without bugfixes_ is yet another sort of statement. (About standards and perhaps DataChannel.) > This means that server XML/XSL and client XML/XSL de facto standards are now > divergent. It remains to be seen what MS and or > datachannel have up their sleeve, but right now it is kind of bleak for > those like our company that would benefit a lot from identical > server and client standards for XML and XSL (T) I'd put it differently: the XML/XSL standards are pretty clear, but what's lacking is browser support, and there's no announced path whereby Microsoft's browsers will conform. There may yet be such a path -- but folk have been asking for conformance for some time, and not seeing it. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schnitz at overflow.de Thu Sep 9 19:12:06 1999 From: schnitz at overflow.de (Sebastian Schnitzenbaumer) Date: Mon Jun 7 17:14:48 2004 Subject: RFP: Namespace URI for HTML In-Reply-To: <37D7D64C.148E9B7B@pacbell.net> Message-ID: <199909091814.UAA02554@server.overflow.de> > > I'm very surprised that the list does not include the current > > approach taken by the HTML WG. This poll seems to suggest that > > one namespace for every flavor of XHTML is the only right choice. I > > agree with Tony and others who consider 3 namespaces as a > > possible solution. > > I think a lot of folk are still waiting to hear a good reason > why more than one is needed ... given that the vocabulary (HTML) > is distinct from the rules (transitional/strict/frameset) that > may be used to assemble them, both now and in the future. Okay - here we go. The namespaces concept, at least in the view-point of some individuals, is a very abstract concept. The namespace is a collection of names, regardless of document type. Given that theory, we could think of the HTML vocabulary as a single namespace. Every flavor or variant of XHTML belongs to the single XHTML namespace. Namespaces are also used for identification, especially, the value of the xmlns attribute is to indicate to which namespace this document instance, fragment or element belongs. If there is no indication of the flavor of XHTML, we come out with the following scenario: Strict, Transitional and Frameset may all have the same <p> and the same <h1>, but that alone does not imply that it is all the same thing. In fact there are substantial differences between these three variants. An application processing a specific XHTML document instance has no indication to which kind of XHTML this document instance belongs. Why is this important? The major HTML browsers don't care, they can process any HTML regardless of type. This will change in the future. In fact, we have an array of specialized user agents coming up. If we talk about the future of HTML, keep in mind that we will see HTML in many different environments. XHTML is not designed to make life better for heavy user agents, moreover, XHTML is the key for the web to rapidly expand to other devices than the desktop PC. A heavy user agent might not care, but for a microbrowser in a cell phone, there is a huge difference between strict and frameset. Why not introduce a custom "variant indentification system" for XHTML? Possible solution: re-introduce the version attribute on the HTML root element specifying the XHTML variant. The problem here are fragments. I want to include a piece of XHTML in a document instance other than XHTML. Again, for many user agents, there is big difference between allowing a <frameset> to be included anywhere in an XML document instance or just basic, strict XHTML that is much cleaner and requires less resources and implementation costs. The version attribute on the HTML root element is not there when any xhtml element is included somewhere in another XML document instance, the only thing we have for identification is the value of the xmlns attribute. Unfortunately, I must stop here. There are more reasons why the HTML WG has chosen 3 namespaces. I'll be happy to continue this conversation later. Best regards, Sebastian Schnitzenbaumer --- Stack Overflow AG Phone: +49-89-767363-70 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 19:23:14 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:48 2004 Subject: RFP: Namespace URI for HTML In-Reply-To: <199909091814.UAA02554@server.overflow.de> References: <37D7D64C.148E9B7B@pacbell.net> <199909091814.UAA02554@server.overflow.de> Message-ID: <14295.60596.319911.71044@localhost.localdomain> Sebastian Schnitzenbaumer writes: > Why not introduce a custom "variant indentification system" for > XHTML? Possible solution: re-introduce the version attribute on the > HTML root element specifying the XHTML variant. The problem here > are fragments. I want to include a piece of XHTML in a document > instance other than XHTML. Then why not allow the html:version attribute on *any* HTML element? Then you can specify version information for subtrees as well as for an entire HTML document. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 19:25:57 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:14:48 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) References: <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <14294.36560.725917.191918@localhost.localdomain> <199909081810.OAA05438@hesketh.net> <14294.47066.957120.565534@localhost.localdomain> Message-ID: <37D7E308.EFE6D75D@mecomnet.de> David Megginson wrote: > > My point is simply that it's not fair to complain that DTDs don't work > with the Namespaces layer, any more than it's fair to complain that > your screwdriver handle gets dented when you hit nails with it. > These days, I don't work with "screwdrivers" much. I use these nifty ratchet devices where one can change the bit. Slotted screws, hex heads, phillips. It's a wonderful world. I suspect though, that there are some suppliers who might still try to convince you - despite the appearance of stanley's yankee spiral screwdrivers decades ago - that the only option for such flexibility would be to spring for an electric screwdriver. Don't let 'em fool you. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Sep 9 19:25:52 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:14:49 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) References: <199909082026.QAA11768@hesketh.net> <199909081810.OAA05438@hesketh.net> <4.0.1.19990908091744.01115340@216.27.10.33> <199909081208.NAA17410@nag.co.uk> <14294.21817.614899.758420@localhost.localdomain> <14294.36560.725917.191918@localhost.localdomain> <14294.47066.957120.565534@localhost.localdomain> <14294.52037.477683.565382@localhost.localdomain> <199909082116.RAA14362@hesketh.net> <14294.54422.707751.653558@localhost.localdomain> Message-ID: <37D7E4D1.D625168E@mecomnet.de> David Megginson wrote: > > My fault: I didn't realise that your proposed changes used only PIs. > I'm not sure that I see how the documents could still be valid from > the XML 1.0 perspective, though, and if not, the new documents would > still be backwards incompatible with some (many?) existing XML 1.0 > implementations. It is correct, that some documents which are not valid in terms of xml-1.0 would be valid in the terms discussed. Given that the purpose of namespaces was to express things for which xml-1.0, taken alone, was not sufficient, I count understand this as a benefit. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 19:25:39 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:14:49 2004 Subject: fixing (just) namespaces and validation References: <199909081037.LAA21158@nag.co.uk> <37D69791.652DF82A@mecomnet.de> <37D7B21B.5CF634E@freenet.co.uk> Message-ID: <37D7EDC0.3CB1CA84@mecomnet.de> Philip Nye wrote: > > i wrote: > ... > > > So, to validate with namespaces, you either have to pre-process the > > > document instance to normalise the prefixes to the prefix used in the > > > DTD, > > > > No, the processing happens in the course of parsing. There is no need for an > > additional pass. No, it is better to map them all to a symbol associated with > > the universal name. The prefixes are superfluous. > > Conceptually this is still pre-processing, even if the two are > integrated in a > single pass. In the same sense that the conversion from a bit string to characters is preprocessing. The distinction is, that the original proposals for "normalizing" such documents suggested that the process was something which would be done in addition to basic parsing. My argument, at the time, was that this is something the parsers should be doing anyway. > This means that in David Megginson's layered model, the document > bounces up and down between layers in an inelegant and to my mind > very wasteful way, during the course of its processing. This is a > result of the inflexibility of the DTD or perhaps of the > incompatibility of namespaces. This may be true in in terms of the Megginson model. There are other models. In one of them, there all names are universal names. Even in the XML layer. I simply don't buy a layered approach with respect to names. The recent concern about the number of namespaces in XHTML bears this out. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 19:25:45 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:14:49 2004 Subject: fixing (just) namespaces and validation References: <199909091012.LAA18444@nag.co.uk> Message-ID: <37D7E951.26B55128@mecomnet.de> David Carlisle wrote: > > [in response to my claim, that] > > > It is the parsers which cause the problem by ignoring the information > > provided. > > ... > > Ah interesting. But then the `problem' is that there is no REC or NOTE > or hint or suggestion from anyone in authority that namespace aware > validating parsers are _supposed_ to interpret xmlns: attribute > declarations in this way. As the recommendation does not say anything about this, it does not prohibit it. There was a discussion about this nine months ago (upon release of rec-xml-names-19990114), at which time the authoritative opinion was that such an interpretation was not intended by the specification, as it would invert the validity-status of some documents. I argued then, and remain convined, that that effect would be beneficial. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken at bitsko.slc.ut.us Thu Sep 9 19:36:49 1999 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Mon Jun 7 17:14:49 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) In-Reply-To: "Michael Champion"'s message of "Thu, 9 Sep 1999 11:22:15 -0400" References: <14294.39104.190422.759370@localhost.localdomain><01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de><14294.39104.190422.759370@localhost.localdomain> <4.2.0.58.19990909093108.00b88c00@pophost1.fore.com> <016401befad7$19d49f30$091d12d1@mccdell> Message-ID: <m3ogfcrnn9.fsf@biff.bitsko.slc.ut.us> "Michael Champion" <mike.champion@sagus.com> writes: > Also, even if the "grove paradigm" is a fundamentally more powerful > way of looking at XML and other types of data than what is in wide > use today, it's unlikely to be adopted unless there is a clean > migration path from familiar APIs like ODBC/SQL, the W3C DOM, the > (forthcoming?) JCP XML data binding spec, etc. [...] So, I would > *love* to see someone define a grove API that extends the DOM, > and/or to see the grove paradigm cleanly incorporated into the Java > Community Process XML data binding, and/or to see a > repository-friendly API that builds from ADO or JDO and incorporates > groves concepts. I commented in another message that the idea behind groves is to seperate the definition of properties and value constraints from the API to access those properties directly. The ECMA Script Language Binding for Level 1 DOM looks deceptively close to that. In effect, the ECMA Script binding says ``use ordinary ECMA Script syntax to access the [grove] properties, and here's the definition of those properties.'' The ECMA Script binding, of course, layers additional methods specific to XML/HTML (getElementsByTagName, for example). If you were to actually seperate out the definition of the properties from the accessors, modifiers, and XML/HTML specific methods, you would be very close to a grove paradigm. You would end up with three parts to the standard: the grove access (implementation specific, or language bindings), a property set, and property-set-specific extensions. It's the definition of property-sets that the grove paradigm intends to be more flexible and dynamic. Another example using the Java binding is if the property setter/getter methods were to be removed and replaced with a Mapping interface (or similar). In this way, the set of properties and constraints could be factored out into ``driver'' classes as described in another message. I'm not proposing this as the ``one true way'' to bridge groves and DOM, more as a bridge to _understanding_ the relationship of groves to DOM. What I'd like to see happen is a proposal or note for a concrete implementation of a grove directly comparible to the current bindings for DOM. -- Ken MacLeod ken@bitsko.slc.ut.us xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 9 19:45:05 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:49 2004 Subject: an unfilled need References: <3.0.6.32.19990907100342.009fa980@gpo.iol.ie> <3.0.6.32.19990909151750.009b6690@gpo.iol.ie> Message-ID: <37D7ECC1.60A3@hiwaay.net> Sean Mc Grath wrote: > > But this only becomes an issue whenever there is > a need to interface between disparate systems. Of course you > need standards at that point -- be they APIs or Data Notations. Good Sean. The standard is either: 1. Needed because a minimal contract must be in place to make an exchange (often a validatible one) 2. It is already done, so convenient. Skip the reinvention of the wheel. Most of the hard computer science research was done by 1969. :-) > Here is the point I was trying to make. If the algorithm to > manipulate the data is downloaded *with* the data, > then the browser meeds no apriori knowledge about > the semantics of the data other than "Oh, here comes a package > of stuff that has an algorithm part and a data structure part. > Execute the algorithm part and hand it the data part to work > with". Yes. Encapsulate where possible and USEFUL. > Moreover, as an application developer I can do what I like > with the package of data. I can attach any semantics I like > to it. JavaScript is a case in point. Leaving aside any > dislike for the language or the data model exposed to the > language, it illustrates the "arbitrary semantics" point > well. Yes. You have a means to define and post the semantics, so you did. Like or dislike scripting, it enables you to move the semantics. Declarative means aren't always sufficient. It becomes markup's blind spot because people adopt markup religiously. The originators never questioned the use of procedural means; they stayed silent because they did not consider these their's to prescribe. (OTOH, using a namespace or face it, a URI/URL to point out where the semantics and other definitional resources are is not a dumb idea, but apparently, not easy to achieve if one is committed to minimal victories.) > Isogen did not have to wait for the W3C or Microsoft > on Netscape or some committee to quabble endlessly over > the markup language necessary to encode the semantics > of a collapsible toc. Nor did Microsoft wait. Collapsible TOC code is everywhere. It recognizes the truth about dynamic presentation: it is procedural. So the question is only, will it run in this or that framework of objects? > >And anyhow, why bother with XML then? > > XML gives me a beautifully simply, open systems, way > of expressing a hierarchical data structure. Why would > I throw that away? It gives you syntax unification and all the support provided by frameworks that do that. The only question is, can your algorithms be supported by the local objects? For that reason, for many apps, helper apps make a lot of sense. When people ask me why XML hasn't been adopted faster, I tell them that most of the things people need to do right now can be done COTS. When they ask me why they should do XML, I tell them because anything taken off a shelf has a shelf life except information. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Sep 9 19:45:20 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:49 2004 Subject: ANN: XML and Databases article References: <199909091642.SAA16413@sonne.darmstadt.gmd.de> Message-ID: <37D7F194.947@hiwaay.net> Ingo Macherius wrote: > > The other problem is you can store XML, but > have to explicitely model relations (parent, sibling, child, ... and > all other axis you need) by foreign keys. The number of "metatables" > with structural information quickly outnumbers the useful data. Again > we tried, benched and canceled. Did you investigate OLAP techniques (cubes, coordinates) as a means to model the trees? I agree that flat table modeling via metatables does get difficult but I did not see it outnumbering the useful data. It is awkward. OTOH, it is one way to get the system running on cheap desktop systems. My guess is, it doesn't scale well and with the advent or rich datatypes and hyperlinks as data objects, it isn't all that useful except when the embedded renderer is the browser object. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Thu Sep 9 19:45:04 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:49 2004 Subject: DOM and Grove References: <19990909043413.A9400@w3.org> <NBBBJPGDLPIHJGEHAKBAEEIFEBAA.martind@netfolder.com> <19990909083042.E9400@w3.org> <37FF5D1E.77AEECB6@prescod.net> Message-ID: <37D7F01A.2B90@hiwaay.net> Correct. Not just possible; it's happening. This is precisely what the IETM community faced in the late eighties and early nineties. The answer was to convert everything to HTML to get the job done. Now they have to convert again. Every time that is done, the costs recur and the information gets a little more damaged. While it is hard on some to understand terms like "notation", it is vital to understand what Paul is saying. This is where everything stopped. This where CALS broke down. This is where the war was lost and the shaky structure known as the World Wide Web emerged a winner because no two ISO committee heads could agree. Study the history of CGM. Look at the relentless duplication of the effort of SGML for reasons I still cannot fathom. Note how SGML was blamed. Look at what is happening in other notations being invented today for graphics. Note the deliberate duplication of effort spent trying to keep separate syntaxes. Note how XML is blamed. Study groves. Write the simplified explanations if you need them. You do need them. len >Paul Prescod wrote: > > The real reason groves were invented was > to answer the question: > > * what is the result of hyperlinking into an arbitrary media type? > > What are the properties of the abstract object returned? The grove > answers that question: the object has properties such as "parent", > (possibly null), "children" (possibly null), "containing entity" and so > forth. > > You cannot build a sophisticated hypertext system without answering that > question. This will become apparent after XLink, XPointer and RDF are > implemented. We'll start to see many divergences of behavior when links > are made into (e.g.) PDF, MPEGs, JPEGs and so forth. Over time we will > need to develop a framework for describing the correct results of links > in a generic way. Then we will reinvent groves. > > Or not... we could keep doing things in an ad hoc manner for ever I > suppose. It would be expensive and inefficient but it is possible. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From niko at cmsplatform.com Thu Sep 9 21:02:41 1999 From: niko at cmsplatform.com (Nik O) Date: Mon Jun 7 17:14:49 2004 Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial) Message-ID: <01c501befaf5$885117e0$1a5e360a@tetondata.com> Even though the XML 1.0 Rec does specify the use of Unicode 2.0, i heartily agree that we should be moving to support Unicode 3.0, rather than remaining with the older version of Unicode. John Cowan wrote: > : >In addition, the following characters no longer pass the tests given >in Appendix B for valid name or name-start characters, but should >remain legal in XML names for backward compatibility, and therefore >should be explicitly enumerated in the corrigendum: > >03D0;GREEK BETA SYMBOL >03D1;GREEK THETA SYMBOL >03D2;GREEK UPSILON WITH HOOK SYMBOL >03D5;GREEK PHI SYMBOL >03D6;GREEK PI SYMBOL >03F0;GREEK KAPPA SYMBOL >03F1;GREEK RHO SYMBOL >03F2;GREEK LUNATE SIGMA SYMBOL > : I disagree the these characters should remain legal in XML names. 1) Were the above changes based upon the recognition that Unicode 2.1 erroneously classified these symbols as letters? 2) If these characters continue to be considered legal name-start characters, won't productions [4], [5], [84], and [85] now contradict the text (following the legal characters table in Appendix B) regarding legal name and name-start characters? 3) If question #2 is true, won't the text then need to be modified to read: "Name start characters must have one of the categories Ll, Lu, Lo, Lt, Nl [, except for these "special" ones..]"? This change of classification may well break some existing XML parsers and/or apps, no matter whether or not these characters remain legal in XML names. Consider that there are two ways that an XML parser might have implemented production [85]: 1) use a simple table of character ranges, copied directly from the XML 1.0 Rec; or 2) a truly Unicode-aware parser might have instead used a table of categories derived from the Unicode data file, and implemented the "Ll, Lu, Lo, Lt, Nl" rule, based upon that table. If i were the developer of serious Unicode-aware software, i'd probably have chosen the second approach, since it is _extensible_ (my parser changes in sync with the Unicode changes); whereas the first is based upon a _static_ table (that changes only when the W3C decrees, if ever). I do suppose we could argue that Unicode was expected to change more often than XML, and that the first approach would therefore require less frequent parser software updates. Either way -- if Unicode changes than those things built upon it (e.g. Java, XML) also have to change. I argue that keeping simple "legal name character" rules is more important than the rather slight possibility of breaking some existing XML documents. At the risk of being labeled Anglo-centric, how many docs are likely to have used these Greek, Arabic, Thai, Lao, or Tibetan symbols in XML names? (I do suppose that James Clark's choice of residence might have skewed the frequency of Thai in XML, though ;-). IMHO, "backward compatibility" does not justify a special rule for the treatment of these characters! If symbols, in general, are not legal name characters, then these symbols should not receive special treatment, just because there were erroneously classified in an earlier Unicode. If these characters indeed aren't letters, then they should be removed from production [85]. This way the corrigendum need only correct [85], a relatively simple change. Also, won't the entry in "A.1 Normative References" also need to be changed to reference the Unicode 3.0 spec, rather than the older version? I, too, have no insight into the W3C process in this matter. Presumably there will one day be an XML 1.1, if only after the XML 1.0 errata reach a critical mass., and/or the Namespaces issue is resolved... Regards, Nik O, Teton Data Systems, Jackson, Wyo. ======= Begin excerpt (from XML 1.0 Rec) ======= [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender [5] Name ::= (Letter | '_' | ':') (NameChar)* : [84] Letter ::= BaseChar | Ideographic [85] BaseChar ::= [#x0041-#x005A] | [#x0061-#x007A] | [#x00C0-#x00D6] | [#x00D8-#x00F6] | [#x00F8-#x00FF] | [#x0100-#x0131] | [#x0134-#x013E] | [#x0141-#x0148] | [#x014A-#x017E] | [#x0180-#x01C3] | [#x01CD-#x01F0] | [#x01F4-#x01F5] | [#x01FA-#x0217] | [#x0250-#x02A8] | [#x02BB-#x02C1] | #x0386 | [#x0388-#x038A] | #x038C | [#x038E-#x03A1] | [#x03A3-#x03CE] | [#x03D0-#x03D6] | #x03DA | #x03DC | #x03DE | #x03E0 | [#x03E2-#x03F3] : The character classes defined here can be derived from the Unicode character database as follows: * Name start characters must have one of the categories Ll, Lu, Lo, Lt, Nl. * Name characters other than Name-start characters must have one of the categories Mc, Me, Mn, Lm, or Nd. : ======= End excerpt ======= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 9 21:54:45 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:49 2004 Subject: MSXML for Java Questions References: <NCBBICOBAHLCGGGGCEIEOEFCELAB.ejfreed@infocanvas.com> Message-ID: <37D810E8.9DC57AD3@pacbell.net> Erik James Freed wrote: > > Good points Dave. I used to be very happy with MS for being so aggressive > with XML and XSL > with their IE5 product. I was naive enough to not think through the rather > obvious fact that once it was out, there was not a lot of pressure to > keep up. The phrase 'de facto' is the operative one. Our company just > ignores the capabilities of IE5 ... That is, you're working to prevent the IE5 "versions" of the specs from becoming the "de facto" standards ... Applause! :-) - 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 ken_north at compuserve.com Thu Sep 9 22:13:58 1999 From: ken_north at compuserve.com (Ken North) Date: Mon Jun 7 17:14:49 2004 Subject: ANN: XML and Databases article References: <199909091642.SAA16413@sonne.darmstadt.gmd.de> Message-ID: <000c01befb00$611cc600$0b00a8c0@grissom> Re: ANN: XML and Databases article Ingo Macherius wrote > The other problem is you can store XML, but > have to explicitely model relations (parent, sibling, child, ... and > all other axis you need) by foreign keys. The number of "metatables" > with structural information quickly outnumbers the useful data. Again > we tried, benched and canceled. This reads like you always decomposed or mapped XML documents to store them, as opposed to storing some XML documents as a single column. The choice of how to store documents in a database will vary on a case-by-case basis, depending on application needs. The critical factor is whether you simply need a document store, or you are dealing with data that needs to be used in queries, particularly "rich" queries: (find something in XML documents and search geospatial data to retrieve the nearest location). If your XML is in a separate document store, you are faced with using data integration middleware and marshaling data. From your comments about performance, my guess is that you weren't running this type of mixed query but were focusing on simply retrieving XML. > The number of "metatables" with structural information quickly outnumbers the useful data. That's an accepted behavior in the OLAP world -- even more so now that disk and memory are inexpensive. > Currently we are investigating our PDOM, which just maps between a > W3C-DOM and persistent streams of serialized Java objects (paper will > be at OOPSLA99). Instead of modeling structure we try to scale by > means of intelligent, specialized cache strategies. That sounds like a promising solution for Java development. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ejfreed at infocanvas.com Thu Sep 9 23:25:53 1999 From: ejfreed at infocanvas.com (Erik James Freed) Date: Mon Jun 7 17:14:49 2004 Subject: MSXML for Java Questions In-Reply-To: <007301befb00$ca04b330$0a0a0a0a@deltabiz> Message-ID: <NCBBICOBAHLCGGGGCEIEAEFIELAB.ejfreed@infocanvas.com> When you are attempting to create a product that has broad reach, the politics of standards become risks, roadblocks, slowdowns, and sometimes showstoppers for hard working innovative and vulnerable small companies like I represent. Hence, IMHO pushing hard on vendors to not play politics with standards and to be consistent in their support is fair. -----Original Message----- From: Steven Livingstone [mailto:ceo@citix.com] Sent: Thursday, September 09, 1999 1:21 PM To: David Brownell; Erik James Freed Cc: xml-dev@ic.ac.uk Subject: Re: MSXML for Java Questions I have recently found the best easiest way (i cost nothing) way to introduce the company I consult for to the capabilities of XML, is through a simple, but effective, part of their application using IE5. Reports are a successful area to show ROI using XML. I use as many capabilities of IE5 as no-one else is thereabouts with browser technology. I can never really understand why people who are trying to get technology to the masses are critisized. I'm sure there are many other XML type apps which have non-standard parts - at least from what I have heard on the list. MS maybe go a bit nuts pushing technology sometimes, but then I remember writing for the first Mosaic browser. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Marc.McDonald at Design-Intelligence.com Fri Sep 10 00:08:10 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:14:49 2004 Subject: RFP: Namespace URI for HTML Message-ID: <4454C011BDE5D211B6C800609776E54016CDF0@master.design-intelligence.com> But an HTML processor is supposed to accept a well-formed document and gracefully ignore unknown elements (actually treat them as text). So, what happens when your cellphone microbrowser gets a frameset document instead of a strict document? Does it just put up an error box and show nothing? How does a non-validating parser ensure a document is frameset or strict? Namespaces do not define the set of valid names, they only allow differentiation. Without validation there is no enforcement that a document is strict, frameset or transitional. Since the namespace declaration has no enforced meaning, why bother with it? The only reason I've seen presented is fragments. BUT, there is a fragments working group, why not let them find a general solution to the problem? Why are you usurping their authority? Marc B. McDonald Principal Software Scientist Design Intelligence, Inc. 1111 Third Avenue, Suite 1500 Seattle, WA 98101 marc.mcdonald@design-intelligence.com Ph: 206.343-7797 Fax: 206.343.7750 http://www.design-intelligence.com > ---------- > From: Sebastian Schnitzenbaumer[SMTP:schnitz@overflow.de] > Sent: Thursday, September 09, 1999 10:10 AM > To: xml-dev@ic.ac.uk > Cc: David Brownell; abcoates@TheOffice.net > Subject: Re: RFP: Namespace URI for HTML > > > > I'm very surprised that the list does not include the current > > > approach taken by the HTML WG. This poll seems to suggest that > > > one namespace for every flavor of XHTML is the only right choice. I > > > agree with Tony and others who consider 3 namespaces as a > > > possible solution. > > > > I think a lot of folk are still waiting to hear a good reason > > why more than one is needed ... given that the vocabulary (HTML) > > is distinct from the rules (transitional/strict/frameset) that > > may be used to assemble them, both now and in the future. > > Okay - here we go. > > The namespaces concept, at least in the view-point of some > individuals, is a very abstract concept. The namespace is a > collection of names, regardless of document type. > > Given that theory, we could think of the HTML vocabulary as a > single namespace. Every flavor or variant of XHTML belongs to the > single XHTML namespace. > > Namespaces are also used for identification, especially, the value > of the xmlns attribute is to indicate to which namespace this > document instance, fragment or element belongs. > > If there is no indication of the flavor of XHTML, we come out with > the following scenario: > > Strict, Transitional and Frameset may all have the same <p> and > the same <h1>, but that alone does not imply that it is all the > same thing. In fact there are substantial differences between these > three variants. > > An application processing a specific XHTML document instance > has no indication to which kind of XHTML this document instance > belongs. > > Why is this important? The major HTML browsers don't care, they > can process any HTML regardless of type. This will change in the > future. In fact, we have an array of specialized user agents coming > up. If we talk about the future of HTML, keep in mind that we will > see HTML in many different environments. XHTML is not designed > to make life better for heavy user agents, moreover, XHTML is the > key for the web to rapidly expand to other devices than the desktop > PC. > > A heavy user agent might not care, but for a microbrowser in a cell > phone, there is a huge difference between strict and frameset. > > Why not introduce a custom "variant indentification system" for > XHTML? Possible solution: re-introduce the version attribute on the > HTML root element specifying the XHTML variant. The problem here > are fragments. I want to include a piece of XHTML in a document > instance other than XHTML. Again, for many user agents, there is > big difference between allowing a <frameset> to be included > anywhere in an XML document instance or just basic, strict XHTML > that is much cleaner and requires less resources and > implementation costs. The version attribute on the HTML root > element is not there when any xhtml element is included > somewhere in another XML document instance, the only thing we > have for identification is the value of the xmlns attribute. > > Unfortunately, I must stop here. There are more reasons why the > HTML WG has chosen 3 namespaces. I'll be happy to continue > this conversation later. > > Best regards, > > Sebastian Schnitzenbaumer > > > > --- > Stack Overflow AG > Phone: +49-89-767363-70 > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 schnitz at overflow.de Fri Sep 10 00:12:44 1999 From: schnitz at overflow.de (Sebastian Schnitzenbaumer) Date: Mon Jun 7 17:14:49 2004 Subject: RFP: Namespace URI for HTML In-Reply-To: <14295.60596.319911.71044@localhost.localdomain> References: <199909091814.UAA02554@server.overflow.de> Message-ID: <199909092315.BAA02929@server.overflow.de> > > Why not introduce a custom "variant indentification system" for > > XHTML? Possible solution: re-introduce the version attribute on the > > HTML root element specifying the XHTML variant. The problem here > > are fragments. I want to include a piece of XHTML in a document > > instance other than XHTML. > > Then why not allow the html:version attribute on *any* HTML element? > Then you can specify version information for subtrees as well as for > an entire HTML document. This mechanism would then be similar to namespaces in design. You are suggesting that the namespace is the highest level of hierarchie, and every XML grammar that has multiple variants shall introduce its own mechanism to distinguish the variants as the second level below namespaces. XHTML is a language with quite some history. I a few years, it is likely that other XML grammars will have the same situation like HTML (SMIL, for instance). I feel unconfortable introducing such a mechanism now just for XHTML where it will be likely that a similar mechanism will be needed in different languages as well. In the end, the version attribute will be used in conjunction with the xmlns attribute for many popular languages. So then why have two mechanisms, where one is global and the other one is always language-specifc, but both are in the same space. Regards, Sebastian --- Stack Overflow AG Phone: +49-89-767363-70 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schnitz at overflow.de Fri Sep 10 01:26:51 1999 From: schnitz at overflow.de (Sebastian Schnitzenbaumer) Date: Mon Jun 7 17:14:49 2004 Subject: RFP: Namespace URI for HTML In-Reply-To: <4454C011BDE5D211B6C800609776E54016CDF0@master.design-intelligence.com> Message-ID: <199909100027.CAA02983@server.overflow.de> > But an HTML processor is supposed to accept a well-formed document and > gracefully ignore unknown elements (actually treat them as text). So, what > happens when your cellphone microbrowser gets a frameset document instead of > a strict document? Does it just put up an error box and show nothing? How > does a non-validating parser ensure a document is frameset or strict? In this specific scenario, there will be transformation on a proxy server, trying to make the best out of it. But the microbrowser itself might just render documents of a specific type. > Namespaces do not define the set of valid names, they only allow > differentiation. Without validation there is no enforcement that a document > is strict, frameset or transitional. Since the namespace declaration has no > enforced meaning, why bother with it? Differentiation is the point. Strict, frameset and transitional are only the base family members. It is likely that there will be a larger XHTML family, where family members will be even more different than just those three. As I said in my first mail, there is more to it and I'll continue here. HTML is a damn useful vocabulary after all. Designing a completely new XML language is often the only way. But sometimes, a new application is rather a mixture of the features that HTML (or a subset of HTML) already provides together with entirely new features. In this case, one would re-use a subset of HTML in a new XML language, forming a new XHTML family member. If my new language wants to allow the use of images, instead of inventing my own tags, why not take the image module from XHTML, authors will be happy since they don't have to learn something new. Lets go a bit further. You have written a new XML language for Forms. In the end you realize that the part dealing with form controls and forms logic is fine, but the visual representation of forms, ie. the definition of the page, the text formatting and layout is actually better done by HTML. You take a subset of XHTML for that part. Your language is bound together with a subset of XHTML, but is still a new, unique XML grammar. If all XHTML variants were one namespace, then that XHTML subset being used in this new XML grammar would also belong to the XHTML namespace. The new language would need the change the default namespace from XHTML to the rest of the language all the time or use colons. But logically, this is a different kind of animal, and should have its own, unique namespace so applications can identify it as such. > The only reason I've seen presented is fragments. BUT, there is a fragments > working group, why not let them find a general solution to the problem? Why > are you usurping their authority? I just wanted to point out that it is sometimes handy to exactly know what kind of XHTML this is, especially when we have many different XHTMLs. Fragments were just an example, I'm not usurping anyones authority. Regards, Sebastian --- Stack Overflow AG Phone: +49-89-767363-70 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 10 01:53:04 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:49 2004 Subject: RFP: Namespace URI for HTML Message-ID: <3.0.32.19990909165535.00ac0aa0@pop.intergate.bc.ca> At 01:24 AM 9/10/99 +0200, Sebastian Schnitzenbaumer wrote: >HTML is a damn useful vocabulary after all. Designing a completely >new XML language is often the only way. But sometimes, a new >application is rather a mixture of the features that HTML (or a >subset of HTML) already provides together with entirely new >features. In this case, one would re-use a subset of HTML in a new >XML language, forming a new XHTML family member. Exactly. I suspect that 100% of the readers of this list agree 100% with this contention. In fact, this is already happening - people are stealing chunks of HTML tags in other XML languages. Good design, IMHO. But, if I want, in my own XML language, to use an HTML table here and an HTML hyperlink there, it seems to me the most natural thing in the world to do this: <myRootElement xmlns:html="the-namespace-URI-for-HTML"> <myTag> ... <myOtherTag> ... <html:a href="adsafa;dfs">sfasafsdj</html:a> <yetAnotherTagOfMine> ... <html:table> <html:tr>...</html:tr></html:table> </myRootElement> why on earth would I want different namespaces for all these different HTML modules? There is no possibility of collisions since they're all from HTML. -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 Marc.McDonald at Design-Intelligence.com Fri Sep 10 02:41:37 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:14:50 2004 Subject: RFP: Namespace URI for HTML Message-ID: <4454C011BDE5D211B6C800609776E54016CDFB@master.design-intelligence.com> Sebastian Schnitzenbaumer wrote: > > But an HTML processor is supposed to accept a well-formed document and > > gracefully ignore unknown elements (actually treat them as text). So, > what > > happens when your cellphone microbrowser gets a frameset document > instead of > > a strict document? Does it just put up an error box and show nothing? > How > > does a non-validating parser ensure a document is frameset or strict? > > In this specific scenario, there will be transformation on a proxy > server, trying to make the best out of it. But the microbrowser itself > might just render documents of a specific type. > > > Namespaces do not define the set of valid names, they only allow > > differentiation. Without validation there is no enforcement that a > document > > is strict, frameset or transitional. Since the namespace declaration has > no > > enforced meaning, why bother with it? > > Differentiation is the point. Strict, frameset and transitional are only > the base family members. It is likely that there will be a larger > XHTML family, where family members will be even more different > than just those three. As I said in my first mail, there is more to it > and I'll continue here. > > HTML is a damn useful vocabulary after all. Designing a completely > new XML language is often the only way. But sometimes, a new > application is rather a mixture of the features that HTML (or a > subset of HTML) already provides together with entirely new > features. In this case, one would re-use a subset of HTML in a new > XML language, forming a new XHTML family member. > This is a general problem not specific to HTML. First, there is no way in XML to use part of another DTD except through the kludge of parameter entities. Re-use of parts of an XML language is a general problem, not specific to XHTML. Again, namespaces DO NOT define a vocabulary. > If my new language wants to allow the use of images, instead of > inventing my own tags, why not take the image module from > XHTML, authors will be happy since they don't have to learn > something new. > Because there is no such thing as 'the image module from XHTML' and putting 'html:' in front of it doesn't make it so. I could put 'externalImageReference:' in front and get the same effect. Both would have to be special cased in the application. If you want modules, wait for a modules spec that applies to any XML language instead of inventing something special for XHTML that doesn't work. > Lets go a bit further. You have written a new XML language for > Forms. In the end you realize that the part dealing with form > controls and forms logic is fine, but the visual representation of > forms, ie. the definition of the page, the text formatting and layout > is actually better done by HTML. You take a subset of XHTML for > that part. > > The new language, however, has no DTD. The XHTML DTDs have not been > constructed for reuse of their parts using the only available mechanism, > parameter entities. So, cutting and pasting of definitions from the XHTML > DTDs would be required to define such a language. > > Namespaces don't define a language. All you have done is punt a second > level of parsing off into the application (with no validity checking). > > Your language is bound together with a subset of XHTML, but is > still a new, unique XML grammar. If all XHTML variants were one > namespace, then that XHTML subset being used in this new XML > grammar would also belong to the XHTML namespace. The new > language would need the change the default namespace from > XHTML to the rest of the language all the time or use colons. But > logically, this is a different kind of animal, and should have its own, > unique namespace so applications can identify it as such. > In this example you have made XHTML structure the root and the new elements the leaves (the opposite of the previous example). First, constructing a DTD for this language would involve cutting and pasting since you are defining new possible contents for some XHTML elements. In particular you would be redefining the body element to accept this new kind of form definition (newlang:form as opposed to html:form). So really my body element is different from the HTML body element so I should prefix it with a newlang. In doing that I've changed the top level 'html' element's content to use 'newlang:body' so I should prefix that with newlang too. The result is I've used the new prefix on all of the higher html elements. <!ELEMENT newlang:html (head, newlang:body)> <!ELEMENT newlang:body ((#PCDATA | %block; | newlang:form | %inline; | %misc;)> So, none of the HTML elements would belong to the HTML namespace. Here you have a basic question: does a namespace define the content model of a language or does it define the semantic meaning of its elements. The answer is it defines neither, don't try to make it do something it is defined not to do. > > The only reason I've seen presented is fragments. BUT, there is a > fragments > > working group, why not let them find a general solution to the problem? > Why > > are you usurping their authority? > > I just wanted to point out that it is sometimes handy to exactly > know what kind of XHTML this is, especially when we have many > different XHTMLs. Fragments were just an example, I'm not > usurping anyones authority. > I doublechecked the W3C groups and it looks like there isn't one that has been given the charter of re-use of DTD subsets (call it modules if you wish). Maybe it falls under the schema group. I just see XHTML trying to provide its own solution to a general XML problem, the solution doesn't work, and just adds to complexity and confusion. The issue should not be addressed by XHTML at all. There should ONLY be a general solution to the problem of reuse of sections of a DTD or schema. In addition I see a confusion between namespaces, modules, languages, DTDs, and schemas. Namespaces have no connection with any of the other items. That is explicit in the spec and the use of URIs. Namespaces do only 1 thing: resolve ambiguity. In the language examples given, I don't need to use namespaces UNLESS it conflicts with another name in the document. It would be a convention to identify non-ambiguous names. XHTML is changing it into a requirement, not in any way validating the elements (pass in a form instead of an image ref, how was that detected), and depending on an application convention of checking the namespace of elements and essientially providing a subset of an HTML parser to validate the elements. You could drop the convention of checking the namespace and just check the element names (except if ambigious). The namespace buys no simplification for the application. Marc B. McDonald Principal Software Scientist Design Intelligence, Inc. 1111 Third Avenue, Suite 1500 Seattle, WA 98101 marc.mcdonald@design-intelligence.com Ph: 206.343-7797 Fax: 206.343.7750 http://www.design-intelligence.com From Marc.McDonald at Design-Intelligence.com Fri Sep 10 02:45:10 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:14:50 2004 Subject: RFP: Namespace URI for HTML Message-ID: <4454C011BDE5D211B6C800609776E54016CDFC@master.design-intelligence.com> Tim Bray Wrote: > At 01:24 AM 9/10/99 +0200, Sebastian Schnitzenbaumer wrote: > >HTML is a damn useful vocabulary after all. Designing a completely > >new XML language is often the only way. But sometimes, a new > >application is rather a mixture of the features that HTML (or a > >subset of HTML) already provides together with entirely new > >features. In this case, one would re-use a subset of HTML in a new > >XML language, forming a new XHTML family member. > > Exactly. I suspect that 100% of the readers of this list agree 100% > with this contention. In fact, this is already happening - people > are stealing chunks of HTML tags in other XML languages. Good design, > IMHO. > > But, if I want, in my own XML language, to use an HTML table here and > an HTML hyperlink there, it seems to me the most natural thing in > the world to do this: > > <myRootElement xmlns:html="the-namespace-URI-for-HTML"> > <myTag> ... > <myOtherTag> ... > <html:a href="adsafa;dfs">sfasafsdj</html:a> > <yetAnotherTagOfMine> ... > <html:table> > <html:tr>...</html:tr></html:table> > </myRootElement> > > why on earth would I want different namespaces for all these different > HTML modules? There is no possibility of collisions since they're > all from HTML. -Tim > And if the elements 'a', 'table' and 'tr' were not in my own XML language why would I need to use a namespace at all? If there's no ambiguity there is no need to use a namespace. > Marc B. McDonald > Principal Software Scientist > > Design Intelligence, Inc. > 1111 Third Avenue, Suite 1500 > Seattle, WA 98101 > marc.mcdonald@design-intelligence.com > Ph: 206.343-7797 > Fax: 206.343.7750 > > http://www.design-intelligence.com > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schen at falconwing.com Fri Sep 10 05:20:13 1999 From: schen at falconwing.com (schen@falconwing.com) Date: Mon Jun 7 17:14:50 2004 Subject: XML Database/Repository with content indexing ? In-Reply-To: <v04220504b3f9dcd32bad@[171.66.196.146]> Message-ID: <Pine.LNX.3.96.990909182205.2589A-100000@www.falconwing.com> Hi Avi, everyone, On Mon, 6 Sep 1999, Avi Rappoport wrote: [ ... ] > and the XQL proposal at > <http://www.w3.org/TandS/QL/QL98/pp/xql.html>. Pretty interesting set of links, Avi, thanks! Seems to me that XPath http://www.w3.org/TR/xpath has taken over instead of XQL. There are several XPath libraries available, including mine which I'll be releasing soon. There's also XML-QL and various implementations, many of which you can find on the excellent Free XML Software list: http://birk105.studby.uio.no/linker/XMLtools.html . . . Sean. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msf at mds.rmit.edu.au Fri Sep 10 06:02:05 1999 From: msf at mds.rmit.edu.au (Michael Fuller) Date: Mon Jun 7 17:14:50 2004 Subject: SAX spec.; C++ apps/parsers? Message-ID: <19990910140440.B15531@io.mds.rmit.edu.au> I'm interested in using SAX as an API for a C++ application, and was looking for a spec. for it. Is there anything besides the Java class documentation at www.megginson.com, or can that be considered the "definitive" SAX specification. (The SAX pages that used to be at microstar that had some extra documentation seem to have dodo-ed.) Also, can anyone point me at any extant C++ implementations of SAX, in addition to the IBM4C++ parser and Jez Higgins' C++ SAX classes? In particular, any idea if a SAX APIs is under development for any of the other C/C++ parsers (expat, f'instance)? Michael ____________________________________________ http://www.mds.rmit.edu.au/~msf/ Multimedia Databases Group, RMIT, 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 schen at falconwing.com Fri Sep 10 06:28:33 1999 From: schen at falconwing.com (schen@falconwing.com) Date: Mon Jun 7 17:14:50 2004 Subject: DOM and Grove In-Reply-To: <37FF5D1E.77AEECB6@prescod.net> Message-ID: <Pine.LNX.3.96.990909192413.2589B-100000@www.falconwing.com> Hi Paul, everyone, On Sat, 9 Oct 1999, Paul Prescod wrote: [ ... ] > The real reason groves were invented was > to answer the question: > > * what is the result of hyperlinking into an arbitrary media type? [ ... ] > You cannot build a sophisticated hypertext system without answering that > question. This will become apparent after XLink, XPointer and RDF are > implemented. We'll start to see many divergences of behavior when links > are made into (e.g.) PDF, MPEGs, JPEGs and so forth. Over time we will > need to develop a framework for describing the correct results of links > in a generic way. Then we will reinvent groves. I am just learning about groves now and am interested in your claim. There's a note in the Property Set Requirements annex of the HyTime specification: NOTE 440 Property sets are designed to support the HyTime and DSSSL processing and representation of notation-specific data by providing the information needed by those processes. They are not intended as a general model for making notation-specific data available for arbitrary processing. But you're saying that we should be able to use groves for other arbitrarily structured data? I guess I can see that in a way, but I would like to see example groves of things like relational databases? Has anyone attempted to define a subset of ESIS for XML yet? I'm very interested in seeing something like that, along with a corresponding grove plan for XPath's (and therefore XSLT and XPointer/XLink's) data model. Having just struggled through the abomination that is the DOM Level 1 in order to attempt to implement XPath, I can definitely see a need for XML processing using efficient, tailored data models produced for each kind of processing, and maybe groves are it. If there's nothing like this yet I would like to collaborate with any other interested parties in defining an XML property set and XPath grove plan, and perhaps also a Java implementation for grove manipulation. . . . Sean. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Sep 10 07:31:49 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:50 2004 Subject: RFP: Namespace URI for HTML Message-ID: <3.0.32.19990909223311.00c874d0@pop.intergate.bc.ca> At 05:49 PM 9/9/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: > And if the elements 'a', 'table' and 'tr' were not in my own XML >language why would I need to use a namespace at all? If there's no ambiguity >there is no need to use a namespace. Because presumably there will be software around that will do the right thing with HTML automatically, based on namespace recognition. -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 James.Anderson at mecomnet.de Fri Sep 10 07:52:17 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:14:50 2004 Subject: Namespaces in XML and XHTML References: <199909050304.UAA02082@boethius.eng.sun.com> Message-ID: <37D89D22.5EF93DC4@mecomnet.de> Jon Bosak wrote: > ... > ------------------------------ > What are namespaces all about? > ------------------------------ > > Namespaces are about unique identification; they are not about > meaning. Identification is necessary to the establishment of meaning, > but it does not constitute meaning in itself. > > [followed by a long discussion to the point that namespaces govern identity in the > encoding and decoding process only and leading to the following conclusions: ] > > ------------------------------------- > Should XHTML use multiple namespaces? > ------------------------------------- > > ... > > - The main argument for specifying three namespaces for XHTML rests > on the assumption that there is a one-to-one association between > namespaces and schemas. This is not true. as established above, it is also insignificant. > > - A second argument for specifying three namespaces is that it's > intended to indicate that XHTML actually specifies three different > tag languages and that <h2> in one of these languages means > something basically different from <h2> in the other two. In my > opinion, <h2> means basically the same thing in all three > versions. ... > ... If the HTML WG decides to maintain the position that > XHTML is defining three different languages, then it should be > ready to explain how an <h2> in one would materially differ in > meaning from an <h2> in another, "meaning" here being expressed in > terms of the intention of the person who causes elements to have > the type "h2." which is also, as established above, insignificant. > > - Another way of making what I believe to be essentially the same > point is that distinctions between a strict <h2> and a > transitional <h2> are not reflected in actual machine processing > outside of validation. which decides the issue. as the namespaces are about unambiguously identifying the encoded specifications for the validation, it is appropriate to make adequate distinctions. ? is it specified somewhere that the various XHTML forms will never appear in the same document? > > - If XHTML really is several languages and the similarly named > elements of those languages really are different from each other, > then those different languages are going to require different HTML > DOMs. i don't understand this one: if the variants are in different namespaces, then elements of each could well be mixed in the same dom instance. isn't that the point of the whole thing? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Fri Sep 10 08:18:20 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:14:50 2004 Subject: Ps --> xml (or html) Message-ID: <3.0.1.32.19990909232740.01b20ec0@mail.accessone.com> Hi; Anyone know of a PS to xml (or html) converter? TIA Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Sep 10 08:52:25 1999 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:14:50 2004 Subject: Ps --> xml (or html) In-Reply-To: <3.0.1.32.19990909232740.01b20ec0@mail.accessone.com> Message-ID: <4.2.0.58.19990910165030.00c8cd10@203.41.126.17> At 16:27 10/09/1999 , David LeBlanc wrote: >Hi; > >Anyone know of a PS to xml (or html) converter? > >TIA > >Dave LeBlanc If "PS" means Postscript, then that's a big ask ... Postscript can contain absolutely anything that can be output to a printer: test, graphics, equations, line art, anything ... Even worse, a lot of the text is broken up and specified according to exact placement on the page, etc, so it's not trivial to try and reconstruct a text flow ... Also, if XML is your target, how would you determine what tags to use for the text? That being said, who know's what some brilliant mind has created out there, but I wouldn't hold your breath. 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 h.rzepa at ic.ac.uk Fri Sep 10 09:03:55 1999 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:14:50 2004 Subject: LISTADMIN: Errors due to full mailboxes Message-ID: <v04205501b3fe5bfe1368@[155.198.224.86]> Can I bring to the attention of the list (but by definition, sadly not to the people who this message is directed to) that an increasing proportion of the errors on this list are being generated by "mailbox full" errors. It is normally my policy to remove email addresses that return with "address unknown" errors, but to leave the generators of mailbox full errors subscribed, in the hope that they will eventually make room on their mailbox for the receipt of new messages. On some systems of course, automatic purges will happen with no user intervention, but some seem to remain full for weeks, or even months at a time. However, I am increasingly believing that these full mailboxes may in fact also be "abandoned" ones. So I think its time to change my policy on these mailboxes. Please note that from now on, if I detect a full mailbox, it is liable to be unsubscribed (again by definition without notice to its owner). I have also noticed a marked increase in (un)subscription requests for accounts sent from an email address that differs from the list value. These all need manual intervention. Currently, this is being batched up for processing about once a week. You might be unlucky and have to wait a week for the request to be processed. Can I ask you to be patient, and not flood me with repeated requests for action. If the continuing emails really offend you, then it is nowadays a simple matter to set a filter on most mailers to divert all the messages straight to the trash, so that you do not even notice them Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elm at arbortext.com Fri Sep 10 14:05:33 1999 From: elm at arbortext.com (Eve L. Maler) Date: Mon Jun 7 17:14:50 2004 Subject: Ps --> xml (or html) In-Reply-To: <4.2.0.58.19990910165030.00c8cd10@203.41.126.17> References: <3.0.1.32.19990909232740.01b20ec0@mail.accessone.com> Message-ID: <4.2.0.58.19990910080659.00b31570@pophost.arbortext.com> Ghostscript claims to be able to "extract text" (so that you could do a PostScript-to-text-to-XML process), but at a quick glance I can't see how you do it. Eve At 04:53 PM 9/10/99 +1000, James Robertson wrote: >At 16:27 10/09/1999 , David LeBlanc wrote: > >>Hi; >> >>Anyone know of a PS to xml (or html) converter? >> >>TIA >> >>Dave LeBlanc > >If "PS" means Postscript, then that's a big >ask ... > >Postscript can contain absolutely anything >that can be output to a printer: test, graphics, >equations, line art, anything ... > >Even worse, a lot of the text is broken up >and specified according to exact placement >on the page, etc, so it's not trivial to >try and reconstruct a text flow ... > >Also, if XML is your target, how would >you determine what tags to use for the >text? > >That being said, who know's what some >brilliant mind has created out there, but >I wouldn't hold your breath. > >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) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 10 15:48:21 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:50 2004 Subject: RFP: Namespace URI for HTML In-Reply-To: <3.0.32.19990909165535.00ac0aa0@pop.intergate.bc.ca> Message-ID: <4.1.19990910094516.01e84100@mail.webgeek.com> At 04:55 PM 9/9/99 -0700, Tim Bray wrote: >why on earth would I want different namespaces for all these different >HTML modules? There is no possibility of collisions since they're >all from HTML. I'd like to point out that the issue of namespaces for mixed modules has NOT been resolved within the working group. That's current work effort. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Fri Sep 10 15:45:25 1999 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:14:50 2004 Subject: Ps --> xml (or html) References: <3.0.1.32.19990909232740.01b20ec0@mail.accessone.com> <4.2.0.58.19990910080659.00b31570@pophost.arbortext.com> Message-ID: <37D91108.CED2E304@finetuning.com> Actually, Ghostscript does it pretty easily. You just go to the "Edit" menu nand then "Text Extract", but you have to make sure that the "PS to Text" is checked on "Normal". ("PS to Text" is on the "Options" menu) lisa Eve L. Maler wrote: > > Ghostscript claims to be able to "extract text" (so that you could do a > PostScript-to-text-to-XML process), but at a quick glance I can't see how > you do it. > > Eve > > At 04:53 PM 9/10/99 +1000, James Robertson wrote: > >At 16:27 10/09/1999 , David LeBlanc wrote: > > > >>Hi; > >> > >>Anyone know of a PS to xml (or html) converter? > >> > >>TIA > >> > >>Dave LeBlanc > > > >If "PS" means Postscript, then that's a big > >ask ... > > > >Postscript can contain absolutely anything > >that can be output to a printer: test, graphics, > >equations, line art, anything ... > > > >Even worse, a lot of the text is broken up > >and specified according to exact placement > >on the page, etc, so it's not trivial to > >try and reconstruct a text flow ... > > > >Also, if XML is your target, how would > >you determine what tags to use for the > >text? > > > >That being said, who know's what some > >brilliant mind has created out there, but > >I wouldn't hold your breath. > > > >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) > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 jmbolles at ThoughtWorks.com Fri Sep 10 15:48:17 1999 From: jmbolles at ThoughtWorks.com (jmbolles@ThoughtWorks.com) Date: Mon Jun 7 17:14:50 2004 Subject: Ps --> xml (or html) Message-ID: <OF869E19B3.31B44437-ON862567E8.004B12F0@thoughtworks.com> James Tauber's FOP tranlates objects to PDF. It may be a good starting point for writing your own converter. Is PGML still alive? The latest version is dated April 1998. <http://www.w3.org/TR/1998/NOTE-PGML> Jack Bolles David LeBlanc <whisper@acce To: xml-dev@ic.ac.uk ssone.com> cc: Sent by: Subject: Ps --> xml (or html) owner-xml-dev @ic.ac.uk 09/10/99 01:27 AM Please respond to David LeBlanc Hi; Anyone know of a PS to xml (or html) converter? TIA Dave LeBlanc xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 10 15:50:58 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:50 2004 Subject: RFP: Namespace URI for HTML In-Reply-To: <4454C011BDE5D211B6C800609776E54016CDFB@master.design-intel ligence.com> Message-ID: <4.1.19990910094808.01e84480@mail.webgeek.com> At 05:44 PM 9/9/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: >Because there is no such thing as 'the image module from XHTML' Sure there is. Please read http://www.w3.org/MarkUp/#drafts and specifically http://www.w3.org/TR/xhtml-modularization/xhtml_modules.html#s_imagemodule There are two issues here right now. 1. XHTML 1.0 and namespaces (which has been beaten to death) 2. Future/current work in XHTML Modularization is that current work. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Sep 10 16:11:03 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:50 2004 Subject: W3C's 'Moral Majesty' Message-ID: <199909101413.KAA00440@hesketh.net> This Computerworld article might be interesting reading for those involved in the recent discussions of W3C process. http://www.computerworld.com/home/print.nsf/all/990906bf62 The article's perspective is interestingly different from that on XML-dev, though some of the same issues arrive. It's definitely the view from the Fortune 500, not from 'independents', but there still seem to be similar pluses and minuses. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matthew at praxis.cz Fri Sep 10 16:22:54 1999 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:14:50 2004 Subject: confidentiality in W3C WGs References: <199909071900.PAA25558@gw.sqwest.bc.ca> <37D70003.E62@hiwaay.net> Message-ID: <37D91483.AA7C1CE6@praxis.cz> > Right. Do it the OldeFashionedWay: Document by paragraph number the > text, the suggested edit to the text, the rationale for the technical > change, the submittor. the reason for accepting or rejecting the > change. There are some sage standards editors on this > list (Dr. Goldfarb? Dr. Newcomb?) who can provide a precise format > for this kind of document. > > It really is that easy. We can't fix the W3C. We can't fix the > press. We can go our own way.... or we can state in earnest to > whatever authority can provide support that the need for clearly > documented public rationale for public utilities outweighs the > need for confidentiality. > > Editing such documents before publishing them is good practice. > Publishing blow by blow summaries of meeting debates is bad practice. > There is plenty of experience in this community to explain those > practices. Well, I wonder if the argument for doing it Ye Olde Fashioned Way is really as strong as all that. I see two reasons to at least consider that this might not be the case, assuming that the primary motivation for the current confidentially policy is the one laid out my Lauren earlier in this thread: 1) The situation in the DOM group was exceptional in that two very high-profile companies were engaged in a very public legal battle at the same time as the WG was attempting to consolidate and improve on the well-known and broadly-used technology of these companies. It would be safe to say that a situation of this type hardly ever arises. Even the industry press is unlikely to latch onto a debate over, say, how many namespaces XHTML should use. I am therefore not sure whether such rare cases should be given too much weight in setting general policy. 2) The world is changing. Someone made a comment that the press will continue to distort facts even if these facts are publicly available. Maybe so, but they can and do do this anyway. Surely a situation where these facts can at least be confirmed and rebutted by interested parties would be more desirable than one where no one but W3C members can even comment, and all they can say is "Please trust us, its not true but we cant say why or explain the real situation". Even 5 (3?) years ago it was not possible for the vast majority of people to gain preliminary access to information about W3C goings-on (or any other standards activities) through any means other than the media. Now almost everyone who is at least as interested in these activities as in the square-footage (acreage?) of Bill Gates new house has access to the Web. As technologists of one breed or another we should be the first to recognize that radical changes in the way the world communicates should affect the way that we address this kind of issue. I am honestly not expecting the W3C to change their confidentially policy because me and a couple of other crackpots on this list think they should, although I do think that complete openness would have huge benefits far outweighing the disadvantages. Actually, it occurred to me that there is a more convincing argument for at least keeping the exact contents of discussions (i.e. who said what) secret: companies (especially startups eager for publicity) might take extreme viewpoints to attract attention, distracting everyone from the work at hand. Be that as it may, this policy needs revision of some sort. Apart from what appears to be overall agreement that the content of and motivation behind important decisions should be published more consistently in a clear and timely manner, it should *never* be necessary for a W3C member to refuse to discuss any technical detail of work in progress with any outsider, even if they are not willing to reveal who said what. No one has stepped forward and even attempted to present an argument as to why this is necessary, and that it is counterproductive both in the political and technical sense (not only W3C members have good ideas, right?) is quite clear. Matthew xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Fri Sep 10 16:40:00 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:14:50 2004 Subject: Ps --> xml (or html) References: <OF869E19B3.31B44437-ON862567E8.004B12F0@thoughtworks.com> Message-ID: <00b801befb9a$657ed9a0$0300000a@cygnus.uwa.edu.au> ----- Original Message ----- From: <jmbolles@ThoughtWorks.com> > James Tauber's FOP tranlates objects to PDF. It may be a good starting > point for writing your own converter. Actually, a PS or PDF to XML converter would gain next to nothing from FOP. Note that PS -> XML is not that bad if your XML is itself a page description markup language but I'm guess that's not what the original poster wanted. James P.S. wouldn't a PS to XML converter violate the second law of thermodynamics?! :-) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From greynolds at datalogics.com Fri Sep 10 17:01:31 1999 From: greynolds at datalogics.com (Reynolds, Gregg) Date: Mon Jun 7 17:14:51 2004 Subject: confidentiality in W3C WGs Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16DA2@martinique> The situation you describe certainly could happen, but I respectfully submit that the possibility of such situations arising would be a very bad reason indeed for the confidentiality agreement, at least from the perspective of the "web community". The W3C should not provide a cloak of secrecy for companies who do not want to cooperate or who subvert the standards process for their own ends. Of course, we can take it as axiomatic that private, for-profit corporations will do everything they can to use the W3C to their advantage, and to the detremint of their competitors - that's their job, after all. All the more reason to insist on openness and candor. Openness would make it that much harder for those dastardly journalists to distort the facts. I also strongly disagree with the notion that the W3C WG structure removes politics from the equation. The smoky back room doesn't go away. Companies can and no doubt do still hold private discussions. W3C secrecy hasn't changed this, and openness wouldn't either. The only place I can see for secrecy is in the vote itself. Sincerely, Gregg (These are my personal opinions only, and don't necessarily reflect those of anybody on the XSL WG nor of my employer.) > -----Original Message----- > From: Lauren Wood [mailto:lauren@sqwest.bc.ca] > Sent: Monday, September 06, 1999 2:16 PM > To: xml-dev@ic.ac.uk > Subject: confidentiality in W3C WGs > > > The only really good reason I see for the confidentiality agreement > that exists in several W3C Working Groups has marketing, public > relations, and politics at its base. > > Imagine a lively WG discussion, in which two large member > companies (let's call them A and B) disagree. The rest of the WG > agrees with A and that's what goes into the spec. Maybe B gives in > graciously, maybe B gives in less than graciously, maybe B > doesn't give in at all. Then imagine the minutes are all public, and > everyone can tell everyone else exactly what happened. > > The upshot is that some journalist, or maybe a public relations > person in company A, starts making a big thing out of how > company A "won" over company B in this issue. Next thing you > know, company B starts fighting back in public, or refuses to give > in graciously on any issue, or doesn't contribute properly to the > discussions, or leaves the WG. > > Could this happen? Yes. I've had journalists call me to talk about > specs such as the DOM or XML, and when I've said that there are > discussions and sometimes companies disagree, I've had > questions such as "tell me when company A won and company B > lost" (no prizes for guessing which companies they were > most concerned with). I've seen articles written about other > standards committees (not in W3C) where the journalist has tried > to make out there is a fight in every small disagreement, and to get > quotes from any participant and twist them to make it look like a > fight. Makes for better press, I guess. Not so great if you're on the > WG involved, trying to get some consensus on sticky technical > issues. That can be hard enough without press articles and PR > problems getting in the way. > > So sometimes you need confidentiality, to build trust and a > knowledge that what is said in a WG remains within that WG, so > that people can concentrate on the technical work, and not on the > politics. > > > 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) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 10 17:03:38 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:51 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) References: <14294.39104.190422.759370@localhost.localdomain><01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de><14294.39104.190422.759370@localhost.localdomain> <4.2.0.58.19990909093108.00b88c00@pophost1.fore.com> <016401befad7$19d49f30$091d12d1@mccdell> Message-ID: <37D8A79B.FD581D6@prescod.net> Michael Champion wrote: > > Third, there was a widespread > perception that the groves model implies, in DOM terms, that "every > character is a node", and people concerned about implementing the DOM API > felt strongly that this would lead to unacceptable footprint and run-time > overhead. Two years later we have incompatible models of string handling in the DOM, the infoset and XSLT. This is *exactly* the problem that groves were invented to solve. I don't mean that in a loose way. I mean that very specifically: it was precisely to head off these sorts of incompatibilities between HyTime and DSSSL that groves were invented. Character handling was only one issue but a major one. The grove world decided that character-level addressing is: a) necessary b) highly optimizable using first CS 201 lazy evaluation tricks. I claim that there is no DOM implementation that can match the performance of James Clark's Jade grove builder. Of course I haven't tied them all but I know that the Jade grove builder is an astoundingly fast part of an astoundingly fast style processor. > Most importantly, someone is going to have to write a *clear* statement of > the paradigm, its power, why it's "the next big thing, etc. You're asking the impossible. Pretend I am a skeptical mid-1980s dbase user. Now write the one-page description of the relational model that will convince me that the model is better than DBase and other proprietary, ad hoc models. Pretend that I am a mid-1980s C programmer. Now write a one-page description of the object oriented model that will convince me that it is better than the procedural model? Insofar as there is always a way to hack around the limitations of the CURRENT model it is essentially impossible to sell the benefits of the new model in simple terms. Rather, the listener needs to have wrestled with the problem and needs to have developed a dislike for ad hoc half-answers. And there are still smart people who I respect that reject both OO and the relational model so I wouldn't expect groves to ever be uncontroversial. I am still discovering the Zen of OO and the Zen of relational myself so how could I brain-dump the Zen of groves (which I am also still discovering)? I can give you some hints though: 1. addressing is the basis of everything. For the most part, the DOM could be replaced with an API of one method: "EvaluateQuery()". Of course that presumes a more powerful "query" language than we have -- we need a full data manipulation language. So just as almost all of Microsoft's "ADO", "DAO", "ODBC" and "RecordSet" APIs boil down to optimizations of and layers on top of "EvaluateSQLQuery", the DOM could be (!should be!) considred an optimizaition of and layer on top of "EvaluateXMLDMLQuery()". 2. addressing is always done in terms of a data model. This is a universal truth which I do not expect anyone will dispute. Even the USPS has a logical model of abstractions such as cities and states. 3. we need to address many different data types. The DOM already supports CSS, HTML and XML. XPath/Pointer supports XML. URLs into PDF are also meaningful. Most other web media is pretty much hyperlink opaque (but should not be!). As soon as you can build a hyperlink that has anchors in a PDF and a JPEG (e.g. NOW) you need terminology to describe the linked objects. "Anchor" is not good enough -- what do the anchors contain? I claim "nodes"? What are the universal properties of nodes? When you define them you will have reinvented a major part of the grove model. 4. inventing, from scratch, a new data model for every media type would be incredibly tedious and hard to implement. Better to set up a framwork for describing the data models of media types: a meta data-model (very different from a meta-data model). 5. inventing, from scratch, a new query language for each media type would also be tedious and hard to implement. This is the path we are on now when we invent new fragment identifiers. If we had a standard data model then many media types could share a query language with shared concepts. Of course optimized query languages will never completely go away but often we don't need them. Addressing an anchor in a PDF is very much like addressing an anchor in HTML. Other media are similarly related. We could start with the goal that there be a universal syntax for fragment identifiers. A universal underlying model is just a few steps beyond that. 6. inventing, from scratch, a new API for each media type would ALSO be tedious and hard to implement. We already have three such APIs under the title "DOM." If an API is just a layer on a query/data manipulation language, then couldn't we algorithmically develop programming-language specific APIs from the same data model definition that we use to develop our query language? This would work in the same way that I can algorithmically generate Java interfaces from IDL 7. new layers on existing data types have all of the same problems as new data types. We need a data model, query language and API for XML, namespaced XML, namespaced XML with XLink, namespaced XML with RDF, XHTML, BizTalk and so forth. Developing each level by hand gets tired (and expensive) pretty quickly. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Sep 10 17:23:27 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:14:51 2004 Subject: an unfilled need References: <3.0.6.32.19990907100342.009fa980@gpo.iol.ie> <3.0.6.32.19990909151750.009b6690@gpo.iol.ie> Message-ID: <37D91C7C.D62832AD@prescod.net> Sean Mc Grath wrote: > > [Paul Prescod] > >All you've done is shifted the problem from document type design to API > >design. Now you need the "bank debit golden ration rte interest group" > >to standardize their Bank objects and Debit methods. > > But this only becomes an issue whenever there is > a need to interface between disparate systems. But if you don't need to interface between disparate systems why did you bring the "bank debit golden ration rte interest group" into it? They aren't relevant whether you take the declarative XML or programmatic Javascript path. > Case in point: There is no industry standard markup language > for creating a collapsible table of contents in a Web page. > There is a very nice one running on the Isogen site > (http://www.isogen.com/papers.htm) written in JavaScript. Sure, but it doesn't need XML. > XML gives me a beautifully simply, open systems, way > of expressing a hierarchical data structure. Why would > I throw that away? XML is no simpler than a language's custom pickle (serialization) format. If more than one language is involved then XML starts to become more compelling but at that point we're getting back into the realm of interchange. We are mostly in agreement: client-side arbitrary processing is certainly a good thing. As a matter of taste I see no reason to embed that program in the same XML document as the data. You can't embed Java classfiles that way and even if you could it is better to refer to the program so that it can be cached seperately. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Fri Sep 10 17:55:02 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:51 2004 Subject: confidentiality in W3C WGs Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFEA1@cc20exch2.mobility.com> From: Reynolds, Gregg [mailto:greynolds@datalogics.com] Sent: Friday, September 10, 1999 11:05 AM > > The situation you describe certainly could happen, but I > respectfully submit > that the possibility of such situations arising would be a > very bad reason > indeed for the confidentiality agreement, at least from the > perspective of > the "web community". The W3C should not provide a cloak of > secrecy for > companies who do not want to cooperate or who subvert the > standards process > for their own ends. Of course, we can take it as axiomatic > that private, > for-profit corporations will do everything they can to use > the W3C to their > advantage, and to the detremint of their competitors - that's > their job, > after all. All the more reason to insist on openness and candor. Actually, if I understand things properly, the "cloak of secrecy" is not to protect the companies who don't want to cooperate, but to protect the ones who DO. Members of the working groups, as things stand now, are free to agree or disagree with anything said on its technological merits, without having to worry about the political consequences of such agreement or disagreement. (Members from Company A can disagree with points that Company B makes, without having to worry about people thinking that it's only because they are competitors. Members from Company A can also agree with points that Company B makes, without having to worry about people thinking that some kind of battle has been won by B.) Again, who said what IS NOT IMPORTANT. Nobody in the world needs to know WHO it was that said it. The problem is that nobody knows WHAT was said. I don't need to know who's idea it was to give XHTML three namespaces. But I really need to know why XHTML was given three namespaces. A lot of people keep viewing the W3C as if Microsoft and Netscape and Sun and the other big players were trying to battle for power behind the closed doors; if this or that technology gets recommended then Microsoft won, but if that one does, then Netscape won... And yet W3C members tell us time and time again that on a working group, nobody is more important than anyone else. They just don't have the kind of clout inside the W3C to make these power struggles, even if they wanted to. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Fri Sep 10 18:00:44 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:14:51 2004 Subject: ANN: XML and Databases article In-Reply-To: <19990909043413.A9400@w3.org> (message from Daniel Veillard on Thu, 9 Sep 1999 04:34:13 -0400) References: <01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de> <14294.39104.190422.759370@localhost.localdomain> <199909082020.PAA02004@bruno.techno.com> <19990909043413.A9400@w3.org> Message-ID: <199909101602.LAA01752@bruno.techno.com> [Daniel Veillard:] > - Show me a definition so that I can understand the term and > underlying concept clearly enough that an implementation > time is spend not collecting and reading papers but implemening > something well defined. > Even reading http://www.prescod.net/groves/shorttut/ I still can't > get a clear definition of "what is a grove precisely". > Not at the concept level, but a implementable definition say > on top of the XML infoset (for XML documents). Designs that support the grove concept must not be confused with the grove concept itself. "What is a grove precisely" is an abstraction, not an implementation or an API. The "clear definition" you want is the ISO standard itself (http://www.ornl.gov/sgml/wg8/document/n1920/html/clause-A.4.html). While it's true that the standard is not a tutorial, and it is definitely not easy to read, the grove paradigm *is* rigorously defined there. There is a glossary at http://www.ornl.gov/sgml/wg8/document/n1920/html/clause-3.html > - Show me the code. Not that there is none, I just don't know. > Is there a program available in source code, that I can run > on say a laptop in front of a novice (but programmer kind) > audience (say a Gnome developper's group) allowing me in 3 mn > to show a "grove" in action and what it does for them. OK. James Clark's awesome DSSSL engine, JADE, is available in source form: http://www.jclark.com. JADE is in production use in industrial contexts. Eliot Kimber's PHyLIS was first demonstrated at XML Europe 1998 and again at XML Developers' Conference '98 in Montreal. While this is not an industrial-strength thing, it was the first demonstration of mixed grove types, with extended ("independent") linking among CGM components and SGML components. If you need the source code of an application that implements the grove paradigm, you can get the source for PHyLIS at http://www.phylis.com. PHyLIS also demonstrates some HyTime stuff. TechnoTeacher offers an industrial-strength generalized implementation of the grove paradigm called GroveMinder, which was demonstrated last February at XTech '99 and again at Metastructures '99 in Montreal. GroveMinder has a demo which can be used compellingly in the kind of 3-minute fashion you want. Contact me and I'll put this demo into your hands (you'll need a password). The source code of GroveMinder itself is not publicly available, but the Python souce that comes with the demo includes the entire demo application, including a couple of grove-to-HTML formatters and an HTTP server. You can get a pretty good idea of the Python API to GroveMinder from this source code, and the demo itself lets you explore groves interactively. You can even change the Python source if you like, to see what happens. (But the demo version of GroveMinder is not designed to support application development, so don't expect it to be easy or convenient to debug your programs.) Some of GroveMinder's applications in industrial contexts were discussed publicly at Metastructures 99. > Get both, and if you're lucky you will experience the same success > as linux. In the meantime me and others are still wondering what's > really behind that 5 letters word ! Fair enough. Thanks for asking. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 fax +1 972 994 0087 pager (150 characters max): srn-page@techno.com 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 donpark at docuverse.com Fri Sep 10 18:04:17 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:51 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) In-Reply-To: <37D8A79B.FD581D6@prescod.net> Message-ID: <000b01befba6$a1e16a00$b3eafea9@w21tp> Paul, What you are saying about groves makes great deal of sense and makes me want to rush out and buy it. So where is it? Does it come in a nice shrinkwrap box and have glitzy GUI to wow me? Will it have a wall full of books like DHTML at the local bookstore for Grove worshipers? Will my friends me bug me with questions like "how do I make my web page do fancy things with TheGroves?" If I post a job wanted ad saying "Groves programmer wanted", will there be thousands of applicants? How should I staff large Grove projects? How do I explain it all to corporate nullheads without sounding like a man from mantraland? What if they pin me down and screams into my ears "So what the hell is this Grove thing? My teenage daughter wants to know! Now! And don't use any mumbo jumbo words like property sets or I'll slap you silly." DOM might be awkward and incoherent but common people can definitely wrap their brain around it. Probably around half a million people already have while learning to enhance their web pages using DHTML. What you are saying about groves makes it sounds like some unified theory of information management but I think common people would rather chew rock than theory. If I walk down the street and tell people that everything is made out of quarks and that the quarks are beautiful and elegant, they will drop a quarter in my coffee cup. The bus has come and gone. While groves dance in my head like swimming suit models, DOM is in the kitchen and making my breakfast. Heck, I am all for groves. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pandeng at telepath.com Fri Sep 10 18:13:23 1999 From: pandeng at telepath.com (Steve Schafer) Date: Mon Jun 7 17:14:51 2004 Subject: an unfilled need In-Reply-To: <37D91C7C.D62832AD@prescod.net> References: <3.0.6.32.19990907100342.009fa980@gpo.iol.ie> <3.0.6.32.19990909151750.009b6690@gpo.iol.ie> <37D91C7C.D62832AD@prescod.net> Message-ID: <37f92e9b.243973997@90.0.0.40> On Fri, 10 Sep 1999 07:58:04 -0700, you wrote: >Insofar as there is always a way to hack around the limitations of the >CURRENT model it is essentially impossible to sell the benefits of the >new model in simple terms. Rather, the listener needs to have wrestled >with the problem and needs to have developed a dislike for ad hoc >half-answers. And there are still smart people who I respect that reject >both OO and the relational model so I wouldn't expect groves to ever be >uncontroversial. I am still discovering the Zen of OO and the Zen of >relational myself so how could I brain-dump the Zen of groves (which I >am also still discovering)? A good set of non-trivial, concrete examples would be useful. People won't be convinced to try the New Thing if they can't see how to apply it to familiar problems. -Steve xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 docuverse.com Fri Sep 10 18:13:03 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:51 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <199909101413.KAA00440@hesketh.net> Message-ID: <001001befba7$c7ef1fc0$b3eafea9@w21tp> Funny article. Maybe Tim should give his head a rest. Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schnitz at overflow.de Fri Sep 10 18:34:24 1999 From: schnitz at overflow.de (Sebastian Schnitzenbaumer) Date: Mon Jun 7 17:14:51 2004 Subject: RFP: Namespace URI for HTML In-Reply-To: <3.0.32.19990909165535.00ac0aa0@pop.intergate.bc.ca> Message-ID: <199909101736.TAA05837@server.overflow.de> > At 01:24 AM 9/10/99 +0200, Sebastian Schnitzenbaumer wrote: > >HTML is a damn useful vocabulary after all. Designing a completely > >new XML language is often the only way. But sometimes, a new > >application is rather a mixture of the features that HTML (or a > >subset of HTML) already provides together with entirely new > >features. In this case, one would re-use a subset of HTML in a new > >XML language, forming a new XHTML family member. > > Exactly. I suspect that 100% of the readers of this list agree 100% > with this contention. In fact, this is already happening - people > are stealing chunks of HTML tags in other XML languages. Good design, > IMHO. I absolutely agree. And that is what the Modularization of XHTML is all about. Instead of randomly stealing chunks from HTML, there is now a repository of XHTML modules. This ensures that everyone steals the image tag in the same way. There is great value in such a thing. Think of Modularization of XHTML as the "XHTML Development Kit". > But, if I want, in my own XML language, to use an HTML table here and > an HTML hyperlink there, it seems to me the most natural thing in > the world to do this: > > <myRootElement xmlns:html="the-namespace-URI-for-HTML"> > <myTag> ... > <myOtherTag> ... > <html:a href="adsafa;dfs">sfasafsdj</html:a> > <yetAnotherTagOfMine> ... > <html:table> > <html:tr>...</html:tr></html:table> > </myRootElement> Sure. You can do that. No question. > why on earth would I want different namespaces for all these different > HTML modules? There is no possibility of collisions since they're > all from HTML. -Tim Each module does not define its own namespace. Modularization itself has nothing to do with namespaces. It is just XHTML sliced into pieces. You can take some or all of the pieces, create your own pieces and come out with a new XHTML variant, XHTML family member or just a new XML language using some stuff from XHTML. How this interacts with namespaces must be decided regarding the context, there is no default way. Basically, it depends on to which degree your own language is intervoven with the XHTML modules. Your example above is perfectly fine and marks one end of the spectrum. The other end would be, for instance, XHTML being the root and your additional modules are some new leaves. You're taking XHTML as it is and add some new elements that are useful for a specific domain. Then the set of new elements could well be a namespace of its own and the XHTML part belongs to the XHTML namespace. But if the set of new elements only make sense to be used together with XHTML and the result of the combination of both is something quite different from the standard XHTML, then it should be possible that XHTML-MyML is an entirely new namespace including both the XHTML part and the MyML part - perhaps operating in a closed environment. Regards, Sebastian --- Stack Overflow AG Phone: +49-89-767363-70 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Sep 10 18:43:15 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:51 2004 Subject: Ps --> xml (or html) References: <3.0.1.32.19990909232740.01b20ec0@mail.accessone.com> Message-ID: <37D9357F.C7BDE98B@pacbell.net> > Anyone know of a PS to xml (or html) converter? Not a general one ... but I've heard tell of one that was used by a large company which had some _strict_ standards that all the PostScript documents adhered to. Same style guide, tools; and auditing of the PostScript output. The SGML conversion was possible in essence because PostScript was being heavily massaged by some PostScript-hosted tools, which would have been impossible without such consistent structure in the generated PostScript. It just happened to enable a surprise tool, later -- see what good design can win you? :-) The folk who wrote this PS-to-SGML conversion are at this time not wanting to talk about it or maintain it; it's not likely that particular technology would be made available publicly, and in any case it'd not be possible without a lot more attention to the emitted PostScript than I think most organizations pay. (As in, lots of person-years just to create clean PostScript in the first place.) - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ejfreed at infocanvas.com Fri Sep 10 18:44:19 1999 From: ejfreed at infocanvas.com (Erik James Freed) Date: Mon Jun 7 17:14:51 2004 Subject: Lotus XPath usage In-Reply-To: <000b01befba6$a1e16a00$b3eafea9@w21tp> Message-ID: <NCBBICOBAHLCGGGGCEIEKEGDELAB.ejfreed@infocanvas.com> Anyone have a simple example of using the lotus XPath package? I just want to write a simple portable query of a DOM tree like: org.w3c.dom.NodeList query(org.w3c.dom.Node root, String expression) The comments on the main entry points are fairly cryptic. I could figure it out from first principles, but I would not mind being spoon-fed either if you know what I mean... thanks! erik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990910/ce49aa7f/attachment.htm From greynolds at datalogics.com Fri Sep 10 19:09:52 1999 From: greynolds at datalogics.com (Reynolds, Gregg) Date: Mon Jun 7 17:14:51 2004 Subject: confidentiality in W3C WGs Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16DA4@martinique> > -----Original Message----- > From: Hunter, David [mailto:dhunter@Mobility.com] > Sent: Friday, September 10, 1999 10:53 AM > To: xml-dev@ic.ac.uk > Subject: RE: confidentiality in W3C WGs > > Actually, if I understand things properly, the "cloak of > secrecy" is not to > protect the companies who don't want to cooperate, but to > protect the ones > who DO. Members of the working groups, as things stand now, > are free to > agree or disagree with anything said on its technological > merits, without > having to worry about the political consequences of such agreement or > disagreement. (Members from Company A can disagree with > points that Company > B makes, without having to worry about people thinking that it's only > because they are competitors. Members from Company A can > also agree with > points that Company B makes, without having to worry about > people thinking > that some kind of battle has been won by B.) > Well, you've lost me here. Companies don't stop competing just because they join the W3C. Maybe it really IS because they're competitors, and company B really has won a battle. > Again, who said what IS NOT IMPORTANT. Nobody in the world > needs to know > WHO it was that said it. The problem is that nobody knows > WHAT was said. I > don't need to know who's idea it was to give XHTML three > namespaces. But I > really need to know why XHTML was given three namespaces. > Here is the best you will ever get without an open process: the reason proposition X passed is that it got the most votes. I'm not making a joke: that IS the reason XHTML got three name spaces, and its the only reason. Why doesn't matter. Nobody knows why participants voted the way they did. Vendors who choose to "explain" the vote in some way may do so; but for purely pragmatic reasons the pros and cons adduced by the various parties involved will never be abstracted out for public presentation. Think of what an impossible task that would be. And you would just end up with further disputes about the "real" justification - the whole thing would just get rehashed ad infinitum. > A lot of people keep viewing the W3C as if Microsoft and > Netscape and Sun > and the other big players were trying to battle for power > behind the closed > doors; if this or that technology gets recommended then > Microsoft won, but > if that one does, then Netscape won... And yet W3C members > tell us time and > time again that on a working group, nobody is more important > than anyone > else. They just don't have the kind of clout inside the W3C > to make these > power struggles, even if they wanted to. > And do you believe them? Look at it from another perspective: when dollars control power, what is the meaning of one person, one vote? When a powerful company can afford to develop multiple proposals and then flood an organization with them, what does one seat, one vote mean? -Gregg (My personal opinions only.) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schen at falconwing.com Fri Sep 10 19:23:33 1999 From: schen at falconwing.com (schen@falconwing.com) Date: Mon Jun 7 17:14:51 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) In-Reply-To: <000b01befba6$a1e16a00$b3eafea9@w21tp> Message-ID: <Pine.LNX.3.96.990910082239.3467B-100000@www.falconwing.com> Hi Don, everyone, On Fri, 10 Sep 1999, Don Park wrote: > Paul, > > What you are saying about groves makes great deal of sense and makes me want > to rush out and buy it. So where is it? Does it come in a nice shrinkwrap > box and have glitzy GUI to wow me? Will it have a wall full of books like > DHTML at the local bookstore for Grove worshipers? Will my friends me bug > me with questions like "how do I make my web page do fancy things with > TheGroves?" If I post a job wanted ad saying "Groves programmer wanted", > will there be thousands of applicants? How should I staff large Grove > projects? How do I explain it all to corporate nullheads without sounding > like a man from mantraland? > > What if they pin me down and screams into my ears "So what the hell is this > Grove thing? My teenage daughter wants to know! Now! And don't use any > mumbo jumbo words like property sets or I'll slap you silly." [ ... ] 1,$s/grove/XML/gc So did you say the same thing when XML came out? =) If groves will solve problems that people are already encountering with XML, then it's day will come. For example, relational DB-XML mapping, IDL-XML mapping, XML-object mapping, etc. etc. In my mind it's not much more than a more rigorous definition of the XML data model, with the potential application to other data models. Maybe what we need is something between DOM and full-fledged groves. Just as XML is taking off as a simpler version of SGML, how about a simplified version of groves? . . . Sean. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From msabin at cromwellmedia.co.uk Fri Sep 10 19:31:16 1999 From: msabin at cromwellmedia.co.uk (Miles Sabin) Date: Mon Jun 7 17:14:51 2004 Subject: confidentiality in W3C WGs Message-ID: <c=US%a=_%p=Cromwell_Media%l=ODIN-990910173255Z-4894@odin.cromwellmedia.co.uk> Gregg Reynolds wrote, > Well, you've lost me here. Companies don't stop > competing just because they join the W3C. True, but it's not the *companies* who are on the WGs, it's their technical representatives, who might be considerably more cooperative than their respective salespeople. The fact that confidentiality makes it harder to present a decision as 'company A beat company B' might, to a certain extent, free the techies to make the right decisions without having to worry too much about being moaned at (or worse) for making decisions which could be seen as damaging to corporate prestige. It's sad, but it's probably necessary ... > Maybe it really IS because they're competitors, and > company B really has won a battle. That, of course, would be important. But it's a trade off. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ msabin@cromwellmedia.co.uk England xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Sep 10 19:44:03 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:51 2004 Subject: confidentiality in W3C WGs Message-ID: <3.0.32.19990910104646.019f2bb0@pop.intergate.bc.ca> When I try to explain the W3C's structure to conference and tutorial audiences, sometimes I put it like this: "We lock the engineers from Netscape & Microsoft & Sun & IBM & Adobe & everyone else in a room and keep them there until they work it out. The idea is to keep the marketing droids from making trouble." which glosses over a lot of the details and subtleties of the picture. But is kind of how I think about the process. As a historical note, one big reason why Tim B-L and the guys were able to bootstrap the W3C back in '94 was the public self-destruction of the HTML3 process over in the IETF. I wasn't there so I won't comment on it, but it's certainly an interesting story. -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 srn at techno.com Fri Sep 10 19:59:43 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:14:51 2004 Subject: ANN: XML and Databases article In-Reply-To: <01BEFAB8.224F6E70@grappa.ito.tu-darmstadt.de> (message from Ronald Bourret on Thu, 9 Sep 1999 11:40:35 +0200) References: <01BEFAB8.224F6E70@grappa.ito.tu-darmstadt.de> Message-ID: <199909101759.MAA01822@bruno.techno.com> [Ron Bourret:] > What other common functions can you perform besides addressing / > hyperlinking? Hmmm. Anything that you can do with markup -- and that covers a lot of territory. Especially, anything that you can do with markup, but can't, for one reason or another, use markup to do. (E.g., you can't change what you want to mark up, or what you want to mark up can't be marked up without making it useless for its intended purpose.) A better question might be, "What *can't* you do if you have the ability to attach any information at all, for any reason whatsoever, to any other piece(s) of information, without changing any information except for creating the attachment instructions (which can be completely separate from everything else), in such a way that an application can always tell what is attached to what?" > > Well, actually, there's probably a one-to-one correspondence between > > property sets and database schemas. In order to address information > > in terms of its structure, you have to know the structure. In > > grove-land, the structure is defined by a property set. Different > > databases have different structures, normally expressed as database > > schemas. Making a database look like a grove is very straightforward. > > The bulk of the work is translating the schema into a property set > > (which is, after all, a kind of schema). There's a bit of coding > > involved, too, but the GroveMinder developer kit has tools that make > > this amazingly easy. (At least the Lockheed-Martin people were > > amazed, and they said so publicly at XML '98.) > > What do you mean by "different databases" here? If you mean > relational databases v. hierarchical databases v. object-oriented > databases, then there's no problem -- I would expect each to have a > different property set. On the other hand, if you mean DB2 > v. Oracle v. Informix v. SQL Server, then it seems there is > something broken -- I would very much expect all relational > databases to have the same property set. Let me define some terms here so it will be less confusing: database: a bunch of data, such as the Accounts Receivable of XYZ Corporation as of 6:00 am, Greenwich Mean Time, on January 1, 1999. Databases can have a variety of genres and schemas, and their management is generally facilitated by some sort of DBMS. database management system (DBMS): some specific software for storing and retrieving databases and components of databases, such as Oracle 8i, ObjectStore, etc. When I say "database", I try not to mean "DBMS", although I make this mistake a lot. database genre: a distinct but broad database paradigm, such as "relational", "hierarchical", "object-oriented", etc. When I say "database", I try not to mean "database genre", although I make this mistake a lot. database schema: the formal expression of the structure of a particular database. (Not the structure of a DBMS, and not a database.) When I said "different databases", I meant "different databases" -- different bunches of data. The data found in a particular field is an example of a "component" of a database. A particular table is a component of some particular database. It's true, what you said: you can have a property set for relational databases in general. I (confusingly) skipped that step, assuming that we would be making a property set for accessing the semantic aspects of databases in terms of their schemas, so that the properties of the database get their names from the field definitions in the schema, etc. What you're suggesting (i.e., that the properties of all relational databases can be represented with a single property set) is very similar in spirit to the SGML Property Set. The SGML Property Set is not configured for a particular DTD; it works for all DTDs. It knows nothing about the semantic properties of any particular DTD's vocabulary. Instead, the DTD is regarded as one of the properties of an SGML document. We could do the same thing for all relational databases, by regarding the schema as one of the properties of the database. But I think that it's often attractive, in terms of software re-usability and in terms of the reliability of information interchange, to create property sets for the information sets of specific DTDs (or "vocabularies"), in addition to using the SGML or XML property set. In the case of databases, in the same way and for the same reasons, it's attractive to create property sets for particular schemas, *in addition to* the generic SGML Property Set (or, someday, the XML Property Set) and the generic Relational Database Property Set. When an XML document is processed, you get a "primary XML grove", plus as many groves as there are vocabularies used in that document, each with values for the properties defined for that vocabulary. Similarly, when a grove interface is provided to a relational database, you get a "primary relational database grove", plus (a) grove(s) for the schema(s) that govern that database. > Saying that a grove is a database strikes me as a bit misleading, at > least in the database world. I take your point. I was trying to show that in grove-land it's all a matter of perspective whether something is a "document" (a word that connotes a lump of interchangeable data that normally must be read and processed before anything useful can be done with the information it contains) or a "database" (a word that connotes a bunch of data whose interconnectedness and accessibility exist in a state of full application-readiness). Groves offer both perspectives at the same time, which is why they allow applications to ignore the difference between documents and databases. > What I meant to do here was distinguish between the database that > GroveMinder uses to store groves and other databases that might be > external resources, such as that Informix database run by Billy Bob > over in Engineering. (Granted, GroveMinder's database can > undoubtedly be treated in a fashion similar to Billy Bob's database, > but that's getting a bit self-referential and misses the point that > GroveMinder runs just fine without Billy Bob's database but can't > run without its own.) I'm also assuming that the database used by > GroveMinder is configured for grove storage, although this might not > be such an earth-shaking amount of work -- I'll take a guess that > the class definitions are fed pretty much directly into the database > as schema. Yes. When all is said and done, GroveMinder runs as a native application of the DBMS in which the groves persist. A lot of the GroveMinder technology is devoted to making GroveMinder portable. > What I meant here was whether you could perform an operation similar to > embedding an Excel spreadsheet in a Word document -- that is, can I > (easily, generically, and without modification of property sets) combine > information from different groves into a single grove. The answer is, "Yes, iff your property sets allow it." Since you can write your own property sets (and, in the case of GroveMinder, your own minders), the short answer is "Yes". > This would be extremely useful because it would be a step on the way > towards being able to query the entire enterprise with requests such > as, "Get me the names, addresses, and company prospectuses of all > customers that I've sent email to in the last three days". The names > and addresses come from the corporate database, the email > information comes from my email, and the prospectuses come from a > document database somewhere or perhaps the Web. The result could be > navigable by a generic grove navigation tool. Ah. As you say below, you don't need to combine groves to do that. All you need is a document (grove), such as a HyTime document (grove) that addresses all these things in all these different groves (the corporate database grove, the email groves, and the document database grove or Web grove), so that it returns to your application an amalgamated node list of what you want. > My guess is that groves right now give me this functionality by > hyperlinking one grove to the next. This is fine in some cases (a > grove-based query tool), not in others (wanting to expose tabular > database data as XML). What advantage does converting the nodes of a tabular database into XML nodes offer, over accessing the nodes of the tabular database directly? > (Note that when the Word document is persisted, the result isn't > really a "Word" document, it's (if I've got my terminology right), > an OLE Compound Document. When you get to the point where the > spreadsheet is, Word no longer has a clue how to process > it. Instead, there's a flag that says, "Yo! Go start Excel" and > processing is handed over to Excel. A similar situation would be > reasonable in a "compound" grove. It could easily be persisted to a > grove database, which understands groves, but couldn't readily be > persisted as XML or a database without conversion software. Yeah, something has to copy the nodes from one grove (say, the Word grove) to a grove that is an XML grove, and then export the XML grove. But I don't see how this improves one's access to the information in the Word grove. (I can see how it improves access by people who have XML applications but not Word applications, but if you already have a Word grove, making it into an XML grove offers little advantage that I can see, unless you just need XML because you need XML.) > > You're right that one application of GroveMinder is data transfer > > middleware. The conversion program is comparatively easy to write, > > since everything already conforms to the same object model. > > I'm not quite sure I understand this. Above, you've just said you > need to make decisions about how database node classes are converted > to XML node classes, which makes sense to me. What do you mean by > "everything already conforms to the same object model"? As far as I > can tell, groves allow everything to be expressed as objects (which > have a few common properties), but these objects are no more the > "same object model" than a model for a person is the same as a model > for a book. Groves may have gotten me from some other format > (notation) into an object model, but whether converting one object > to another is easy depends on the objects themselves. I think what I'm saying is confusing only because it is too obvious. When I said "object model", above, I wasn't talking about particular classes of objects; I was talking about "what an object is" (or, "the virtual base class to which all objects belong, regardless of their class"). Fundamentally, the grove paradigm's object model is: Nodes (objects) consist of named properties, and values for those named properties. As object models go, it's a pretty simple one. Most object models also allow objects to have methods, but the grove paradigm's object model doesn't have methods. > In this case (since I'm the discusser ;) I'd say they're worth > discussing in individual product descriptions, but not in the meat > of the article, any more than a discussion of the DOM is relevant to > the discussion. I can't argue with that. Thanks for the stimulating discussion, Ron. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 fax +1 972 994 0087 pager (150 characters max): srn-page@techno.com 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 simonstl at simonstl.com Fri Sep 10 20:10:41 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:51 2004 Subject: confidentiality in W3C WGs In-Reply-To: <3.0.32.19990910104646.019f2bb0@pop.intergate.bc.ca> Message-ID: <199909101813.OAA11533@hesketh.net> At 10:46 AM 9/10/99 -0700, Tim Bray wrote: >As a historical note, one big reason why Tim B-L and the guys were able >to bootstrap the W3C back in '94 was the public self-destruction of the >HTML3 process over in the IETF. I wasn't there so I won't comment on it, >but it's certainly an interesting story. -T. I've heard that story described (by someone sympathetic to the IETF perspective, who must remain unnamed) as the: 'One broken process deserves another more broken process theory of standards' Of course, he (I think I can acknowledge gender) didn't think it was broken in the first place, but you know how these things go... Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Sep 10 20:20:05 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:51 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) In-Reply-To: <Pine.LNX.3.96.990910082239.3467B-100000@www.falconwing.com> from "schen@falconwing.com" at Sep 10, 99 08:29:28 am Message-ID: <199909101857.OAA27372@locke.ccil.org> schen@falconwing.com scripsit: > In my mind it's not much more than a more rigorous definition of the XML > data model, with the potential application to other data models. Maybe > what we need is something between DOM and full-fledged groves. Just as > XML is taking off as a simpler version of SGML, how about a simplified > version of groves? That is just what the XML Infoset WD is all about. There is no problem with expressing the XML Infoset as a grove, and the only reason it isn't going to be in the WD is that I don't know how. I do know how to do RDF schemas, so there will be one of those instead. AFAIK the Infoset meets the grove object model: there are objecdts with properties, some string-, integer-, or boolean-valued; other properties are either ordered or unordered lists of other objects. Does the grove model capture the difference between ordered and unordered lists directly, or does that require extra properties? -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Fri Sep 10 20:50:59 1999 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:14:51 2004 Subject: confidentiality in W3C WGs References: <199909101813.OAA11533@hesketh.net> Message-ID: <37D958AA.95883930@finetuning.com> You know, I would think that the conversations that have been taking place on this list over the last week or two are making a pretty good case for why we DON'T want everyone and their mother at working group meetings, wasting valuable time, holding up progress over what ultimately amounts to an individual's confusion regarding the technical issues that are involved. In a public forum, we'd really NEVER know for sure whether an individual was just acting on his or her own behalf, or who's larger agenda was being followed, when they launch a debate for the umpteenth time over a now-historical issue of record. (Hey, while we're going back in time, how 'bout we take a bullet for Kennedy and convince NASA to take an extra round of X-rays on the Challenger's O-rings while we're at it!) -- And all this just because they "can", because this is a public mailing list. Such hypothetical debates may be amusing, in small doses, on public mailing lists when nothing is at stake but an overfilled in-box, but at a face-to-face WG meeting, where people have flown in from all over the world, often on weekends, on their own time, with their own money, and on top of whatever else they are expected to keep going back home, such tactics are not appreciated. It amounts to "filibustering", which is a purely POLITICAL maneuver. If the WG meetings were held publicly and every step of the whole process were placed completely out in the open, that's all that would ever take place in them: politics. There would be no incentive to work together with your competitors to ensure that little discrepancies don't get in the way of technology moving forward. It is only because of the existing confidentiality agreements that the members of a working group are able to, in some capacity, put their cards on the table and trust that the group will try as a whole to find a realistic solution to fit everyone's needs. Without such agreements, every working group meeting would become a press conference. Member companies would soon be basing their votes on the popular opinion of their constituencies. At which point there would be no reason for these companies to even continue participating in the standards process. And the whole thing would be over. All of the software, hardware, telecom, cellular, satellite, microwave and whatever other companies that have actually been working together can and will go back to developing their own technologies in their own smoke filled rooms. And we'll end up with a VHS version of the World Wide Web. Now I better stop before somebody accuses me of filibustering, but this has been building up for weeks, and I just couldn't hold it in any more. Suffice to say that I think some of you need to seriously reconsider this little standards upheaval you keep going on and on about, before you undermine the very process that got us up to this point in the first place. Don't worry, I won't be going on any more about this or writing back to say it over and over again. I've said my peace. peace, lisa <uncontrollable rant> Do you think it's fun or something being on one of those groups? It sucks! You spend hours and hours working very hard on something that, if all goes well, no one will even notice or appreciate, because it will be working quietly in the background. We'll know you did it, maybe, but the this "public" at large that many on this list keep suggesting is somehow being cheated out of participating in the process... All they're going to know is that the web don't work so well no more. If you want to "participate" so badly, pay the money like any other company or individual, and participate, or just lurk around, enjoying your member privileges. If you don't have the money, become a real expert, not just someone who plays one on TV, and participate in one of the Sig groups or something, out of your own sheer dedication, and who knows, maybe you'll be invited in as an expert! But don't even, for one minute, take the current unprecedented level of corporate inter-monolith interest in web standards for granted, or you'll be watching it go "poof!" and it'll be defacto heaven all over again. Sheesh! It's only been three years! Have you forgotten the good old days before standards already? </uncontrollable rant> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From niko at cmsplatform.com Fri Sep 10 21:05:18 1999 From: niko at cmsplatform.com (Nik O) Date: Mon Jun 7 17:14:51 2004 Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial) Message-ID: <006b01befbbf$c9770b60$1a5e360a@tetondata.com> <escape_clause> If an overriding design goal of XML 1.0 is to ensure that all existing well-formed documents will always be well-formed, forever and ever, then the rest of this message is moot, and should be promptly sent to the trash-bin. If, OTOH, it might be acceptable to break a miniscule number of documents in return for a more dynamic and extensible handling of characters in XML, please consider this message. </escape_clause> It is a given that changes from Unicode 2.0 to 3.0 will require changes to XML 1.0, and thus all existing XML-compliant parsers will cease to be compliant when the changes are made. These Unicode changes aren't "corrections of printers errors" -- they are real changes in the XML spec, and will require changes to XML parsers and apps, as well. I guess my previous message was sufficiently obtuse, since my real intention was to raise the issue of how these sorts of changes are to be managed. I previously wrote: >> >> This change of classification may well break some existing XML parsers >> and/or apps, no matter whether or not these characters remain legal in XML >> names. > >John Cowan replied: > > Only if those parsers are not compliant. Appendix B explicitly lays out in the > BNF what is and what is not legal in XML names, which is precisely > why it needs revision now. I should have said that "..the new BaseChars changes _will_ break _all_ existing XML parsers and/or apps..". Once this change is made to XML, existing parsers won't be compliant since they've implemented BNF rule 85 from REC-xml-19980210, and thus won't recognize these new BaseChars (e.g. #x01F6) as legal name characters. XML 1.0 is frozen in the time of Unicode 2.0 since XML used a copy of, rather than a reference to, the Unicode character encodings. What i was suggesting (rather poorly, it seems) is that if XML were to simply refer to Unicode there would never be the need to squeeze changes to XML into "corrigenda". I do understand that using BNF to describe XML required this sort of copying, since rule 85 is the foundation of many other rules. But i seriously doubt that most parsers actually use the BNF directly to build their internal tables -- the BNF is merely the specification of data that are translated into internal bitmaps or whatever. I previously wrote: >> >> IMHO, "backward compatibility" does not justify a special rule for the >> treatment of these characters! If symbols, in general, are not legal name >> characters, then these symbols should not receive special treatment, just >> because there were erroneously classified in an earlier Unicode. > >John Cowan replied: > > Adding an extra rule isn't that hard, I<em>M</em>HO. Very true, but isn't this the top of a slippery slope, whereby every change to Unicode might require yet another special rule to maintain backward compatibility? It would be possible to define XML characters as being based directly upon the current Unicode data tables, i.e., replace the whole BNF rule 85 table with a rule that directly referenced Unicode: "BaseChar ::= [..what Unicode says..]". I realise that this example isn't real BNF, but it is just as valid a method of specifying characters. We could perhaps refer to Unicode's BNF rules for the purpose of the XML grammar, but use Unicode tables for actual XML implementations. This way, XML would simply need to use "..a set of rules whereby you can extract the XML lists from those in the [Unicode] standard automatically." It's true that some characters might re-classified and thus cause some documents that were well-formed to lose that status (again, i believe this to be a miniscule subset of all XML documents). But the advantage would be a simple and open identification of documents as "XML 1.0 + Unicode x.x compliant". If i'm using XML in a real-world environment, it doesn't matter if XML 1.0 has been changed to allow some new character if i haven't upgraded my Unicode support, and vice versa. This would tighten the bond between XML and Unicode, since the latter organization couldn't make their changes oblivious to their impact upon XML (no insult intended to Unicode, Inc.). Since XML is based upon Unicode, XML developers are also, by definition, Unicode developers -- these two communities are already interdependent. As mentioned in the annotated version of XML 1.0, there exists are a contradiction between the abstract and section 1.1 of XML 1.0 regarding the completeness of the XML spec. A specification's text typically takes precedence over its abstract. Given this, we could presume that XML is intended to be based upon Unicode and ISO 10646, and we could/should defer to those standards for classifications of characters, assignments of values, etc. I'm just speculating about a future implementation of these interlocking standards that would be extensible by relying upon commonly shared data tables, rather than specified grammars -- a little more OO, a little less BNF/ML. Regards, Nik O, Teton Data Systems, Jackson, Wyo. ======= Begin excerpts (from XML 1.0 Rec) ======= Abstract The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. : 1.1 Origin and Goals : This specification, together with associated standards (Unicode and ISO/IEC 10646 for characters, Internet RFC 1766 for language identification tags, ISO 639 for language name codes, and ISO 3166 for country name codes), provides all the information necessary to understand XML Version 1.0 and construct computer programs to process it." ======= End excerpt ======= ======= Begin excerpts (from Tim Bray's Annotated XML 1.0) ======= XML Rules For Character Classification Although the Working Group emphatically did argue over the inclusion and exclusion of individual characters, we (well, mostly James Clark) were able to work out a set of rules whereby you can extract the XML lists from those in the standard automatically. ======= End excerpt ======= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schen at falconwing.com Fri Sep 10 21:13:07 1999 From: schen at falconwing.com (schen@falconwing.com) Date: Mon Jun 7 17:14:52 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) In-Reply-To: <199909101857.OAA27372@locke.ccil.org> Message-ID: <Pine.LNX.3.96.990910095054.3467C-100000@www.falconwing.com> Hi John, everyone, On Fri, 10 Sep 1999, John Cowan wrote: > schen@falconwing.com scripsit: > [ ... ] > > Just as > > XML is taking off as a simpler version of SGML, how about a simplified > > version of groves? > > That is just what the XML Infoset WD is all about. [ ... ] > AFAIK the Infoset meets the grove object model: there are objecdts with > properties, some string-, integer-, or boolean-valued; other properties > are either ordered or unordered lists of other objects. I read the Infoset standard yesterday, but it seems to me that it's not enough. Among objections raised on this list is that too many things are optional. What I like about the grove system is that at least everything is present but the application developer can specify using a grove plan what information can be omitted (or rather, what info he/she wants). Also it seems to me that groves go a step further in defining a canonical representation using SGML markup and also a mental model using a tree-like data structure. I do appreciate the difficulty of defining the Infoset what with XML not mandating that all processors validate documents. But it should be possible to define a complete InfoSet first as a grove, then define that non-validating processors should present a grove plan that specifies the InfoSet subset they do provide. Other XML standards like XPath and the DOM can also provide a grove plan for their processing model. One concrete advantage would be that developers who are doing particular XML processing can specify a grove plan saying what they need out of the InfoSet, then match it with XML processors and technologies like XSLT. > Does the grove model capture the difference between ordered and > unordered lists directly, or does that require extra properties? That I'll leave for the grove experts to answer =) From a brief scanning, it looks like everything is ordered though. . . . Sean. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Sep 10 21:17:30 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:52 2004 Subject: confidentiality in W3C WGs In-Reply-To: <37D958AA.95883930@finetuning.com> from "Lisa Rein" at Sep 10, 99 12:14:50 pm Message-ID: <199909101955.PAA29188@locke.ccil.org> Lisa Rein scripsit: > In a public forum, we'd really NEVER know for sure whether an individual > was just acting on his or her own behalf, or who's larger agenda was > being followed, when they launch a debate for the umpteenth time over a > now-historical issue of record. (Hey, while we're going back in time, > how 'bout we take a bullet for Kennedy and convince NASA to take an > extra round of X-rays on the Challenger's O-rings while we're at it!) > -- And all this just because they "can", because this is a public > mailing list. While some IETF working groups have blown up in this way, many of them have come to very satisfactory conclusions using a totally public process: anyone can show up, that means you too. So your conclusions are, er, overblown. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 10 21:23:02 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:52 2004 Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial) Message-ID: <3.0.32.19990910122302.00c07af0@pop.intergate.bc.ca> This moving-Unicode-target is a very good issue for this forum, and thanks are due to John Cowan for bringing it to our attention. Things we could do include: 1. freezing XML 1.0 at Unicode 2 2. updating it per John's suggestion to accommodate Unicode 3 3. putting in a by-reference pointer so that XML and Unicode conformance are (to the degree possible) orthogonal. #3 is the most elegant solution, but it certainly made a majority of the original XML WG very nervous. In fact, people (I'm one of them) *did* use the character tables from the XML spec to construct parser tables in their code. This is a reassuringly deterministic way to build software, and leads to a very high degree of confidence that my software and yours will interoperate in a surprise-free way. Option 3, to my mind, opens a door a lot of interoperability surprises. IMHO, xml ain't perfect but by golly it has already proven itself to be *damn* interoperable, let's try to preserve that. So my leaning would be to a series of widely-spaced and well-publicized revisions along the lines John proposes, which might be regarded as tracking Unicode in a controlled way. But I think the community is certainly open to other suggestions in this area. -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 Fri Sep 10 21:35:04 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:52 2004 Subject: confidentiality in W3C WGs In-Reply-To: <37D958AA.95883930@finetuning.com> References: <199909101813.OAA11533@hesketh.net> Message-ID: <199909101937.PAA15369@hesketh.net> At 12:14 PM 9/10/99 -0700, Lisa Rein wrote: >You know, I would think that the conversations that have been taking >place on this list over the last week or two are making a pretty good >case for why we DON'T want everyone and their mother at working group >meetings, wasting valuable time, holding up progress over what >ultimately amounts to an individual's confusion regarding the technical >issues that are involved. There are times when I wonder whether I get a different version of this list than do other readers. In the past few weeks I've heard: 1) Excellent technical arguments for and against the inclusion of three namespaces in XHTML 2) Detailed exploration of the relationships between namespaces and XML 1.0, and different possibilities therein, not to mention similar issues in updating XML 1.0 to deal with Unicode 3.0 3) Better explanation of the grove concept than I've heard previously in my three years working with XML 4) Intelligent discussion of different possibilities for development models and processes building on XML. 5) Examination of the boundaries between scripting and data I'm sure there's a lot more I could come up with, if I took the time to go back and read more of the messages. While this does involve an overflowing mailbox, it also represents an impressive gathering of minds that can examine difficult issues in depth, present different solutions, and still maintain some level of coherence. But heck, maybe I'm just an obstructionist! Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Fri Sep 10 22:29:03 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:52 2004 Subject: enumeration and defaults Message-ID: <199909102031.QAA17913@hesketh.net> For language lawyers - I've found myself in a somewhat odd situation, where I'd like to be able to include empty (i.e., no value) as a choice in a list of enumerated possibilities. It doesn't seem possible. (Empty is not a token.) It might be nice to declare: <!ATTLIST myElement myAtt (0|1|2) #IMPLIED> but it isn't clear to me what the implications are. If I just write: <myElement /> I haven't provided a 'wrong' value for myAtt, but I haven't in fact provided a value that matches an entry in the list. #REQUIRED would get me out of this by requiring that I use 0, 1, or 2, but that obviously leaves out the possibility of omission. >From 3.3.2 > #IMPLIED [means] that no default value is provided. The particular case I'd like to explore would allow the use of notations to identify content if desired, but omission would allow the application to rely on external tools like MIME types. I could default to a NOTATION of 'NONE' where the notation references something describing nothing, but that seems a bit, well, existential. I may simply be lacking a key set of assumptions, but I feel like I could read the spec either way. Does no default value mean that there is no value to check against constraints, or does it imply a null value that will violate constraints of this sort? Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Sep 10 22:33:58 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:52 2004 Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial) In-Reply-To: <006b01befbbf$c9770b60$1a5e360a@tetondata.com> from "Nik O" at Sep 10, 99 01:07:52 pm Message-ID: <199909102111.RAA02087@locke.ccil.org> Nik O scripsit: > It is a given that changes from Unicode 2.0 to 3.0 will require changes to > XML 1.0, and thus all existing XML-compliant parsers will cease to be > compliant when the changes are made. These Unicode changes aren't > "corrections of printers errors" -- they are real changes in the XML spec, > and will require changes to XML parsers and apps, as well. I think only to the parsers, and only to their lowest levels at that; apps are probably not sensitive to what characters appear in names for the most part. > I guess my previous message was sufficiently obtuse, since my real intention > was to raise the issue of how these sorts of changes are to be managed. Obscure (hard to understand) maybe, but not obtuse (stupid). > I should have said that "..the new BaseChars changes _will_ break _all_ > existing XML parsers and/or apps..". Once this change is made to XML, > existing parsers won't be compliant since they've implemented BNF rule 85 > from REC-xml-19980210, and thus won't recognize these new BaseChars (e.g. > #x01F6) as legal name characters. Correct. And in fact there may wind up being XML 1.0 vs. XML 1.0 with Unicode 3.0 support (a la SGML TCs). Not, I trust, XML 1.1. > Very true, but isn't this [backward-compatibility rules] the top of > a slippery slope, whereby every change > to Unicode might require yet another special rule to maintain backward > compatibility? In principle yes, in fact no. The Unicode Consortium and WG2 are focused on adding support for new characters in Unicode 4.0 and beyond, not on making changes to old stuff, though no one can rule out the possibility of an error that has simply gone undetected hitherto, like the classification of U+212E ESTIMATED SYMBOL as a lower-case letter. (The glyph looks a lot like "e", but isn't subject to font variants, which accounts for the persistent error.) In particular, for reasons having to do with canonical forms of Unicode, decompositions are most unlikely to change henceforth. So we can expect some new XML name and name-start characters in Unicode 4.0, new backwards compatibility hacks are rather unlikely. > It would be possible to define XML characters as being based directly upon > the current Unicode data tables, i.e., replace the whole BNF rule 85 table > with a rule that directly referenced Unicode: "BaseChar ::= [..what Unicode > says..]". I realise that this example isn't real BNF, but it is just as > valid a method of specifying characters. We could perhaps refer to > Unicode's BNF rules for the purpose of the XML grammar, but use Unicode > tables for actual XML implementations. Tim Bray laid out the perceived risks here pretty nicely. > If i'm using XML in a real-world environment, it doesn't matter if XML 1.0 > has been changed to allow some new character if i haven't upgraded my > Unicode support, and vice versa. Well, not if you are trying to *render* the new characters. But an application that translates XML to some legacy format could cope with new Unicode characters without change. > This would tighten the bond between XML > and Unicode, since the latter organization couldn't make their changes > oblivious to their impact upon XML (no insult intended to Unicode, Inc.). > Since XML is based upon Unicode, XML developers are also, by definition, > Unicode developers -- these two communities are already interdependent. Yes, but overly detailed coupling between independently developed standards makes for tricky management issues. Particularly because the Unicode Standard is developed by both the Unicode Consortium and ISO JTC1/SC2/WG2, coordinating a third body is probably too tricky. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mike.champion at sagus.com Fri Sep 10 22:38:23 1999 From: mike.champion at sagus.com (Michael Champion) Date: Mon Jun 7 17:14:52 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) References: <14294.39104.190422.759370@localhost.localdomain><01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de><14294.39104.190422.759370@localhost.localdomain> <4.2.0.58.19990909093108.00b88c00@pophost1.fore.com> <016401befad7$19d49f30$091d12d1@mccdell> <37D8A79B.FD581D6@prescod.net> Message-ID: <026b01befbcc$c2e377e0$fabeb3c7@mccdell> ----- Original Message ----- From: Paul Prescod <paul@prescod.net> To: <xml-dev@ic.ac.uk> Sent: Friday, September 10, 1999 2:39 AM Subject: Re: Groves, the next big thing (Re: ANN: XML and Databases article) > > Most importantly, someone is going to have to write a *clear* statement of > > the paradigm, its power, why it's "the next big thing, etc. > > You're asking the impossible. Pretend I am a skeptical mid-1980s dbase > user. Now write the one-page description of the relational model that > will convince me that the model is better than DBase and other > proprietary, ad hoc models. [snip] > I am still discovering the Zen of OO and the Zen of > relational myself so how could I brain-dump the Zen of groves (which I > am also still discovering)? OK, fine ... my point is that if it is so difficult to beome enlightened about the Zen of groves, it's not likely to become "the next big thing" or "the next Linux". > > I can give you some hints though: > > 1. addressing is the basis of everything. For the most part, the DOM > could be replaced with an API of one method: "EvaluateQuery()". This is what I've suspected all along. The DOM is an attempt to develop a pragmatic solution to a number of real problems faced by ordinary people building Websites, writing XML-aware applications, etc. It's got numerous flaws, and those of us with it on our consciences are painfully aware of them. (My personal "favorite" flaw is exactly the one Paul Prescod mentioned, i.e. the rather clumsy way in which one must address individual characters and its incompatibility with XPath, XSL, etc.; I rant about this to the point that I'm sure my colleagues find rather tiresome). In retrospect it is clear to me that the DOM would be a better API if it were built on a more explicit and formalized notion of what the underlying data model is and how one addresses individual sub-components (down to the character level) in that data model. But the Internet economy was not about to wait for the best possible XML API, so we had to get out one that is good enough. Groves, on the other hand, is an extremely general framework, somebody in this thread called it a "Grand Unified Theory of Information". It would appear that the groves paradigm is general enough to encompass just about any XML or non-XML data model -- including the DOM's implicit data model, the Info Set data model, RDF (?), etc But this very generality puts it at a level of abstraction that is simply not appreciated by most people trying simply to get their jobs done. I'm VERY sure that had the DOM working group somehow proposed an API that consisted simply of an EvaluateQuery() method it would have been soundly rejected by the W3C membership or failing that, gotten absolutely nowhere in the marketplace of ideas. It simply would not solve any of problems the DOM is intended to solve, i.e., it doesn't make it any easier to develop an interoperable Web site or XML application, maintaining the maximum possible degree of compatibility with languages, tools, and APIs in widespread use. What we did come up with is, well, what you call "ad hoc" and I call "pragmatic": not pretty, flawed in many ways, but highly serviceable and widely adopted. Sooner or later, maybe after we've all retired to live off the rich rewards due us as XML pioneers ;~) somebody will come along and re-define the chaos we now call the DOM, XML, XSL, XPath, XQL/XML-QL, RDF, etc. in a clean, consistent way and on top of a firm theoretical foundation -- let's call this "X-Nirvana". At the very bottom, that theoretical foundation will probably look an awful lot like the Zen of Groves. Some people on this list seem to believe that a more widespread appreciation of the Zen of Groves will shorten the path to X-Nirvana. I personally doubt it. To pick up Don Park's analogy elsewhere in this thread, what would 18th or 19th century chemists done had they the knowledge that ultimately atomic theory could be formulated in terms of quarks? Would that have speeded up the process of figuring out the periodic table, discovering the chemical composition of familiar materials, or leveraging this knowledge to economically produce new materials? I doubt it -- quark theory is just at the wrong level of abstraction to be useful for solving the practical problems of that age... and I'm far from convinced that the grove paradigm does much TODAY to solve the problems we face in our day jobs. Maybe after a lot more "ad hoc" exploration of how to solve real problems, but not anytime soon. Mike Champion xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 10 23:30:03 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:52 2004 Subject: enumeration and defaults Message-ID: <3.0.32.19990910143224.0091b420@pop.intergate.bc.ca> At 04:34 PM 9/10/99 -0400, Simon St.Laurent wrote: >I've found myself in a somewhat odd situation, where I'd like to be able to >include empty (i.e., no value) as a choice in a list of enumerated >possibilities. It doesn't seem possible. (Empty is not a token.) Right - and I agree that this does seem like something reasonable to want. >>From 3.3.2 >> #IMPLIED [means] that no default value is provided. This is a little different from SGML. The wording in the SGML standard that describes what #IMPLIED means is really hard to understand, something about the attribute being "implied" by the software. In SGML parsers, the effect was that the parser told you about missing #IMPLIED attributes (this element could have had a FOO attribute but doesn't), and in early drafts of the XML spec we had language requiring XML processors to do the same thing. On reflection, we took it out, and decided that #IMPLIED really means that if the attribute isn't there, it just isn't there, that's all. (#REQUIRED says it has to be there, and the presence of a default value covers the missing case in another way). Of course, an attribute being absent is obviously different from it being present with an empty-string value. So I'd say that XML DTDs more or less can't do what I think Simon is trying to do here. If there are some strong use-cases, someone should bombard the Schema WG with them so that next-gen schemas have this hole filled. -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 Marc.McDonald at Design-Intelligence.com Fri Sep 10 23:41:19 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:14:52 2004 Subject: RFP: Namespace URI for HTML Message-ID: <4454C011BDE5D211B6C800609776E54016CE20@master.design-intelligence.com> I looked at the structure of the XHTML DTDs which provided no means of extracting the image module, i.e. there were no parameter entities that held the associated definitions (table would be a better example of this). I did look at the referenced documents and with associated processing software that can be very nice. I didn't see any XML for the modules involved however. With a module breakup shouldn't the namespace be the module involved, i.e. htmlTables:table? But, namespaces still aren't modules and modules haven't been defined. I would wait and use XML modules rather than overloading namespaces in the context of XHTML. I assume modules would fall under the Schema group. Marc B. McDonald Principal Software Scientist Design Intelligence, Inc. 1111 Third Avenue, Suite 1500 Seattle, WA 98101 marc.mcdonald@design-intelligence.com Ph: 206.343-7797 Fax: 206.343.7750 http://www.design-intelligence.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken at bitsko.slc.ut.us Sat Sep 11 00:50:26 1999 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Mon Jun 7 17:14:52 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) In-Reply-To: "Michael Champion"'s message of "Fri, 10 Sep 1999 16:40:45 -0400" References: <14294.39104.190422.759370@localhost.localdomain><01BEFA20.9D5E8F30@grappa.ito.tu-darmstadt.de><14294.39104.190422.759370@localhost.localdomain> <4.2.0.58.19990909093108.00b88c00@pophost1.fore.com> <016401befad7$19d49f30$091d12d1@mccdell> <37D8A79B.FD581D6@prescod.net> <026b01befbcc$c2e377e0$fabeb3c7@mccdell> Message-ID: <m3g10ms7lk.fsf@biff.bitsko.slc.ut.us> "Michael Champion" <mike.champion@sagus.com> writes: > Groves, on the other hand, is an extremely general framework, > somebody in this thread called it a "Grand Unified Theory of > Information". It would appear that the groves paradigm is general > enough to encompass just about any XML or non-XML data model -- > including the DOM's implicit data model, the Info Set data model, > RDF (?), etc > > But this very generality puts it at a level of abstraction that is > simply not appreciated by most people trying simply to get their > jobs done. I'm VERY sure that had the DOM working group somehow > proposed an API that consisted simply of an EvaluateQuery() method > it would have been soundly rejected by the W3C membership or failing > that, gotten absolutely nowhere in the marketplace of ideas. It > simply would not solve any of problems the DOM is intended to solve, > i.e., it doesn't make it any easier to develop an interoperable Web > site or XML application, maintaining the maximum possible degree of > compatibility with languages, tools, and APIs in widespread use. > What we did come up with is, well, what you call "ad hoc" and I call > "pragmatic": not pretty, flawed in many ways, but highly serviceable > and widely adopted. [I'm reiterating] > But this very generality puts it at a level of abstraction that is > simply not appreciated by most people trying simply to get their jobs > done. I don't agree. Most people (noting the target audiences) understand the idea of nested objects/nodes. What's trying to be described here is that it should be very easy to have an API to access those objects/nodes that doesn't have a hardcoded idea of what the properties and values of those objects/nodes. With an API that isn't hardcoded to one set of properties it becomes natural, intuitive even, to be able to apply that API to any set of properties. I believe people would quickly come to appreciate that. In some languages, accessing the properties of a particular object are part of the syntax of the language (ECMA Script, Python, Perl, ...). In other languages this can be simulated easily using container class interfaces/protocols (Java, C/C++, SmallTalk, ...). Trying to address a deeper level of properties is what most languages or container classes don't support natively and where query methods come into play, i.e. node.query(). The most difficult concepts about groves are not basic access to properties. One of the most difficult concepts about groves is that the user gets to choose what level of detail they want to see in a grove at any particular time. DOM is well noted for having too much or too little information for many users, what if the user could choose? One concept that is actually very easy for users, but difficult for grove implementors, is the concept of addressability. The description of groves goes into great detail on what it means to point into a grove. For users, it's as easy as ``get characters 1 through 50 of paragraph 3 of node with id "foo-node"'', even if those characters span multiple nodes. I understand why it's hard to approach groves, all the grove descriptions I'm familiar with try to cram all of the concepts into one document while using the SGML property set as an example. I have some ideas for another introduction but I'll need to become more familiar with some of the richer implementations, mine is just a bit too primitive to do groves full justice ;-) -- Ken MacLeod ken@bitsko.slc.ut.us xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sat Sep 11 02:16:20 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:52 2004 Subject: ANN: XML and Databases article References: <01BEFAB8.224F6E70@grappa.ito.tu-darmstadt.de> <199909101759.MAA01822@bruno.techno.com> Message-ID: <37D99D68.438F@hiwaay.net> Steven R. Newcomb wrote: > > [Ron Bourret:] > > > What other common functions can you perform besides addressing / > > hyperlinking? > > Hmmm. > > Anything that you can do with markup -- and that covers a lot of > territory. Ok Dr. To you or Eliot. Here is a challenge. Give an example in which groves and markup are used as the basis of documenting a standard or specification including the editing decisions and technical discussions that result in the final version. I've seen you do this before. Bring two noisy threads together and show how the technologies invented almost a decade ago apply to the problems of today right here, right now, in this community. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sat Sep 11 02:14:15 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:52 2004 Subject: confidentiality in W3C WGs References: <3.0.32.19990910104646.019f2bb0@pop.intergate.bc.ca> Message-ID: <37D99CA1.669C@hiwaay.net> Tim Bray wrote: > As a historical note, one big reason why Tim B-L and the guys were able > to bootstrap the W3C back in '94 was the public self-destruction of the > HTML3 process over in the IETF. I wasn't there so I won't comment on it, > but it's certainly an interesting story. -T. It reveals a lot about what happens in certain communities in certain contexts. It can always happen. It comes down to individuals. What is reasonable to expect from the W3C: 1. Documented requirements 2. Documented processes 3. Documented specifications I did not use the word standard. I don't consider the specifications for technologies to be standards. That is a mincing, of course, but useful. Again: 1. Never publish or even document the discussions. People will say many things and take many positions in a discussion. Even well-written transcripts are insufficiently dimensional. 2. Publishing votes is reasonable. It isn't required. 3. Publishing a document which takes each issue, each assertion about the issue, and the rebuttal points, or acceptance based on common standards editing practices and requirements (for example, a call for a change must be accompanied by the text of the suggested change plus the issues to which it pertains) is well within reason. We have been sitting here inventing technologies which make it even more practical than it was when we started (anyone remember one of the best applications of independent links - creating named relationships in texts, eg, asserts, refutes; old ideas when Conklin wrote about them). The W3C cannot expect to avoid this when the community it serves expects nothing less. They want to know why. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sat Sep 11 04:17:20 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:52 2004 Subject: confidentiality in W3C WGs References: <199909071900.PAA25558@gw.sqwest.bc.ca> <37D70003.E62@hiwaay.net> <37D91483.AA7C1CE6@praxis.cz> Message-ID: <37D9BB7E.5B3D@hiwaay.net> Matthew Gertner wrote: > > Well, I wonder if the argument for doing it Ye Olde Fashioned Way is > really as strong as all that. Then use the technology invented to do it. I have presented a challenge to Dr Newcomb and Mr. Kimber to show by example what is possible here using groves. Groves are not necessary to achieve it, but they may be necessary to sustain what is achieved by putting such documents into a form rigorous enough to withstand both time and the changes of power and authority. > Be that as it may, this policy needs revision of some sort. Apart from > what appears to be overall agreement that the content of and motivation > behind important decisions should be published more consistently in a > clear and timely manner, Yes. I think all clear thinking persons on this list can agree. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sat Sep 11 08:14:23 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:52 2004 Subject: Layers, again (was Re: fixing (just) namespaces and validation) Message-ID: <001801befc1d$ce5bdad0$37f96d8c@NT.JELLIFFE.COM.AU> From: Simon St.Laurent <simonstl@simonstl.com >No, you don't have the choice of applying _validation_ at whatever level >you like - currently, you have the choice of applying it or not applying it >during the parser. It seems a bit strange to say on the one hand that "XML is too monolithic" and at the same time that namespaces should not be a separate layer and should be folded into the base spec. Which is not to say that it is an impossible view. However, I don't understand the quoted paragraph: who has the choice of validation? The recipient of a document can choose validation only by installing a validating parser; the generator of a document can only choose validation the same way! The instructions needed for a document to *instruct* a system as to what kind of validity may be required are missing from any XML spec: the standalone declaration is advisory. Without such a mechanism, validity cannot be part of schemata: a document cannot assert that it should be valid (according to a DTD or any other schematic) before it is used. I think this is a hole that should be plugged. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sat Sep 11 08:46:57 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:52 2004 Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial) Message-ID: <007501befc22$54731b70$37f96d8c@NT.JELLIFFE.COM.AU> From: Nik O <niko@cmsplatform.com> >I argue that keeping simple "legal name character" rules is more important >than the rather slight possibility of breaking some existing XML documents. >At the risk of being labeled Anglo-centric, how many docs are likely to have >used these Greek, Arabic, Thai, Lao, or Tibetan symbols in XML names? IMHO it should only be a wf-requirement to check for name characters only with a granularity of the low half-blocks: an application should only need to look at 512 notional bits to test well-formedness of names, apart from the first half block (i.e., the ASCII repertoire). XML will track Unicode, so the fine-grained approach of allocating name roles character-by-character to every Unicode codepoint is overkill for well-formedness and perhaps even for validity. The full rules can be kept for full validity or as guidelines for generating data. They are not bad, they are just more than is needed. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sat Sep 11 08:58:17 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:52 2004 Subject: Ps --> xml (or html) Message-ID: <008e01befc23$e9b7e2f0$37f96d8c@NT.JELLIFFE.COM.AU> >> Anyone know of a PS to xml (or html) converter? The shareware utility "Magellen" converts PDF to HTML. It makes every word into a span element. Then it makes a big stylesheet to position every word on the canvas individually by X and Y coodinate. If a word has multiple fonts, it will be split into separate words. If you text is simple lines, you can easily write a program to figure out how words will fit into lines, and then you can use the other style information to add style attributes and guess the best element names. Xerox has some product which does something like this at the inXight site. However, it all becomes very tricky if there is tables or graphs or equations or multiple columns or runarounds or initial large caps on paragraphs or sidebars etc etc. For that kind of text, you may find it easier to use OCR on a printout or to rekey the data; if you are not using the page for republishing, but merely want to index it or add metadata, then you could use Acrobat and keep it in PDF for better or worse. But don't believe marketing claims that you can magically go from unmarked-up legacy publications to usefully marked-up XML; the best you can expect is to go to some nice HTML. If some product claims more, be forgiving in your expectations! Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sat Sep 11 09:35:24 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:52 2004 Subject: W3C's 'Moral Majesty' Message-ID: <009f01befc29$15b673d0$37f96d8c@NT.JELLIFFE.COM.AU> From: Simon St.Laurent <simonstl@simonstl.com> >The article's perspective is interestingly different from that on XML-dev, >though some of the same issues arrive. It's definitely the view from the >Fortune 500, not from 'independents', but there still seem to be similar >pluses and minuses. All standards processes are subject to the same constraints that face-to-face meetings require travel, which requires money. Indeed, this fact makes W3C into largely a rich Westerners' club; there seems almost no participation from non-residents of Western countries (except Japan, which is rich). When people complain that standards processes disenfranchise them, they usually mean that their immediate neighbours are franchised and they are not. However, the facts of geography mean that a standards process that relies on unsubsidised face-to-face meetings is intrinsically discriminatory. There are four approaches: * "that is the way of the word": it cannot be helped; * positive discrimination, e.g. subsidies; * reduce the reliance on face-to-face meetings; * universal enfranchisement. I think there is no clear best solution; indeed to be frank, I cannot see the superiority of W3C opening its doors to allow non-member voting if in fact all those members are just more rich Americans: the groupthink may only increase. Complex standards and standards which do not allow alternative technologies (the bazaar) reduce the chance that non-Western or poor W3C members can contribute viable and well-formed technology to W3C. Of course, there are other big blocks, notably the reliance on text rather than diagrams in W3C specifications, and indeed the fact that English is the only language. Some complaints about W3C "standards"-making processes are based on the naive idea that standards-making can ever be fair, given the tyranny of distance and the Tower of Babelon. To an extent, there will always be a political aspect where the weak lobby to appeal to the liberality or self-interest of the strong to give them a voice. Rick Jelliffe "The very thing that makes you rich, makes you poor." Ry Cooder song. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Sep 11 10:08:53 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:52 2004 Subject: ANN: XML and Databases article Message-ID: <01BEFC3E.40379930@grappa.ito.tu-darmstadt.de> Steven R. Newcomb wrote: > > What other common functions can you perform besides addressing / > > hyperlinking? > > Anything that you can do with markup -- and that covers a lot of > territory. Especially, anything that you can do with markup, but > can't, for one reason or another, use markup to do. (E.g., you can't > change what you want to mark up, or what you want to mark up can't be > marked up without making it useless for its intended purpose.) > > A better question might be, "What *can't* you do if you have the > ability to attach any information at all, for any reason whatsoever, > to any other piece(s) of information, without changing any information > except for creating the attachment instructions (which can be > completely separate from everything else), in such a way that an > application can always tell what is attached to what?" I'm still not getting it. I honestly can't think of much to do with markup except marking up data. Most of the things I can think of doing I do with data -- the markup just tells me what the data means. Let me try asking the question in this way: what facilities do I inherently get from using groves and their related technologies that I can use in a generic manner? For example, in the XML world, I can pass the data around in a text file, navigate it with the DOM, link to other data with XLink, query the data with XQL, transform it with XSL, and so on and so forth. So far, what I've heard about groves tells me that I can express any data as a set of objects, I can navigate through those objects, and I can build links between any of those objects, regardless of their class. What else can I do? Thanks for all the other answers as well -- they cleared up a lot of things in my mind. Two points: a) Modeling a database in general v. modeling a specific schema in a database (e.g. customer data). Your explanation was very helpful and mirrors the distinction I make between modeling an XML document and mode ling the data in that document. Both are useful and both have distinct uses. b) Converting from one property set to another (e.g. from a database node to an XML node). As you pointed out, this is useful if the recipient wants XML, not groves. We're not going to see an all-grove world any time soon, any more than we're going to see an all-XML world. Conversions, like death and taxes, will always be with 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/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sat Sep 11 11:08:00 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:52 2004 Subject: confidentiality in W3C WGs Message-ID: <01BEFC46.88E67EF0@grappa.ito.tu-darmstadt.de> Reynolds, Gregg wrote: > Here is the best you will ever get without an open process: the reason > proposition X passed is that it got the most votes. I'm not making a joke: > that IS the reason XHTML got three name spaces, and its the only reason. > Why doesn't matter. Why does often matter. Here's two reasons: * Why helps explain what. As a simple example of this, consider the design goals at the start of each W3C spec. These certainly aren't required by the rules written in the spec, which are undoubtedly clear, concise, and unambiguous ;), but they go a long way towards setting up the context in which the reader understands the spec. * Why helps adoption. If there's a hard technical trade-off to be made in a spec, the result is not going to make everybody happy. Explaining why helps people understand why the decision was made as it was and gives them a stake in that position. Telling them what only leaves them confused, annoyed, and ready to jump ship for something better. Dictatorships and democracies both work, but democracies get a lot more genuine support. Why doesn't have to be directly in the spec, but it needs to be somewhere more than in just a few people's heads. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Sep 11 12:36:41 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:52 2004 Subject: RFP: Namespace URI for HTML In-Reply-To: <199909092315.BAA02929@server.overflow.de> References: <199909091814.UAA02554@server.overflow.de> <14295.60596.319911.71044@localhost.localdomain> <199909092315.BAA02929@server.overflow.de> Message-ID: <14298.11834.246339.578615@localhost.localdomain> [I'll answer this one question, and then will try to shut up again.] Sebastian Schnitzenbaumer writes: > > Then why not allow the html:version attribute on *any* HTML > > element? Then you can specify version information for subtrees > > as well as for an entire HTML document. > > This mechanism would then be similar to namespaces in design. Well, in scope, at least... > You are suggesting that the namespace is the highest level of > hierarchie, and every XML grammar that has multiple variants shall > introduce its own mechanism to distinguish the variants as the > second level below namespaces. Only if they need to. The problem is that there are at least two different kinds of information needed about an element or attribute name: 1. What is the major group that this belongs to (HTML, TEI, DocBook, etc.)? 2. What is the special variant (version/flavour) that this belongs to (XHTML 1.0 strict, etc.)? No matter how we slice it, *one* of these is going to be easy for programs to discover and one of them is going to be harder. Using a single XHTML Namespace URI and an html:version attribute makes #1 easy and #2 only slightly more difficult; using multiple XHTML Namespaces and complex schema/RDF constructions makes #2 easy but #1 relatively much more difficult. So the question is not whether #1 or #2 should be omitted (both are needed), but which one most applications will care about. My guess is that most applications will care about #1, and that applications that need #2 will be sophisticated enough anyway that checking another attribute won't be a big deal. > XHTML is a language with quite some history. I a few years, it is > likely that other XML grammars will have the same situation like > HTML (SMIL, for instance). I feel unconfortable introducing such a > mechanism now just for XHTML where it will be likely that a similar > mechanism will be needed in different languages as well. In the > end, the version attribute will be used in conjunction with the > xmlns attribute for many popular languages. So then why have two > mechanisms, where one is global and the other one is always > language-specifc, but both are in the same space. There's good precedent -- think of Perl packages, for example, which have a single, persistent package name across all versions and then use a conventional $VERSION attribute, as in the following example: package XML::Writer; $VERSION = "0.2"; All well-behaved Perl packages use the $VERSION attribute the same way. That way, applications written to work with XML::Writer 0.1 will continue to work with XML::Writer 0.2, but applications that need to be sure can check the $XML::Writer::VERSION attribute. In other words, this suggestion is well-proven in major-scale, real-world implementations (last I heard, Perl was still the driving engine behind Amazon.Com and Yahoo!, for example). 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 Sat Sep 11 15:11:50 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:52 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <009f01befc29$15b673d0$37f96d8c@NT.JELLIFFE.COM.AU> References: <009f01befc29$15b673d0$37f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <14298.20819.618323.967973@localhost.localdomain> Rick Jelliffe writes: > There are four approaches: > * "that is the way of the word": it cannot be helped; > * positive discrimination, e.g. subsidies; > * reduce the reliance on face-to-face meetings; > * universal enfranchisement. The third is by far the best solution. Face-to-face meetings are generally more useful for working out political problems than they are for technical problems, precisely they tend to make it even easier for a minority of fast-thinkers and loud talkers (like me) to dominate the discussion: often the best ideas come from quiet, thoughtful people who need to mull over a new idea for a couple of hours (or days) before stating an opinion. Business and technical people used to need a lot of face-to-face contact, but there is a new generation (the under 45's) that's very comfortable with e-mail and telecommuting, and e-mail is a great equalizer -- you can pick up mail for a whole group of people just by setting up an old 286 to dial a local ISP once a day (of course, many people in the world don't have electricity or phone, much less an old 286, but at least the circle is a little wider). As a case in point, SAX 1.0 was designed and implemented on XML-Dev in a few weeks without a single F2F meeting. > Of course, there are other big blocks, notably the reliance on text > rather than diagrams in W3C specifications, and indeed the fact that > English is the only language. The reliance on text is important for accessibility -- both visually-impaired people can have text read to them by software, while hearing-impaired people can read it; diagrams don't work as nicely. The reliance on English is more of a problem. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken at bitsko.slc.ut.us Sat Sep 11 15:42:40 1999 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Mon Jun 7 17:14:52 2004 Subject: ANN: XML and Databases article In-Reply-To: Ronald Bourret's message of "Sat, 11 Sep 1999 10:13:09 +0200" References: <01BEFC3E.40379930@grappa.ito.tu-darmstadt.de> Message-ID: <m3emg5sgv9.fsf@biff.bitsko.slc.ut.us> Ronald Bourret <rbourret@ito.tu-darmstadt.de> writes: > Steven R. Newcomb wrote: > > > > What other common functions can you perform besides addressing / > > > hyperlinking? > > > > Anything that you can do with markup -- and that covers a lot of > > territory. Especially, anything that you can do with markup, but > > can't, for one reason or another, use markup to do. (E.g., you can't > > change what you want to mark up, or what you want to mark up can't be > > marked up without making it useless for its intended purpose.) > > > > A better question might be, "What *can't* you do if you have the > > ability to attach any information at all, for any reason whatsoever, > > to any other piece(s) of information, without changing any information > > except for creating the attachment instructions (which can be > > completely separate from everything else), in such a way that an > > application can always tell what is attached to what?" > > I'm still not getting it. I honestly can't think of much to do with > markup except marking up data. Most of the things I can think of > doing I do with data -- the markup just tells me what the data > means. In the paragraphs quoted above, Steven is referring to a benefit that well-defined addressing provides -- the ability to attach ``markup'' to instances you don't control (owned by others or on read-only media). This benefit can only be gained if consistent addressing is available, which the grove paradigm goes to great lengths to define. > Let me try asking the question in this way: what facilities do I > inherently get from using groves and their related technologies that > I can use in a generic manner? For example, in the XML world, I can > pass the data around in a text file, navigate it with the DOM, link > to other data with XLink, query the data with XQL, transform it with > XSL, and so on and so forth. So far, what I've heard about groves > tells me that I can express any data as a set of objects, I can > navigate through those objects, and I can build links between any of > those objects, regardless of their class. What else can I do? What more are you expecting? If we were to say that groves provide all the same functions you attribute to the XML world but without being tied to XML specifically, wouldn't that alone be worthwhile? The grove paradigm results from recognizing that the same functions you attribute to XML actually apply to many different sets of data. Hence APIs, link languages, query languages, transformation languages, and so on and so forth that can be used in a generic manner across many different sets of data. Note that in many cases, the tools and specs for working with XML can easily be adapted to work with groves. In general (and IMO), XML tools and specs are much simpler than several existing SGML-derived grove tools and specs, just as XML is to SGML. I believe adopting those tools and specs would be a great addition to the grove world. [somewhat out of context :-) ] > We're not going to see an all-grove world any time soon I agree, I don't see the W3C or the community just changing direction based on promise alone (even if there are implementations currently available). I believe it's high time (pun not originally intended ;) that grove advocates banded together and started promoting groves more directly: build a web site, create a mailing list, start drafting grove APIs where they're not already, adapting XML tools and specs, etc. I would be glad to start working on much of the administrivia, the first need would be for a solid mail-list host, offers? -- Ken MacLeod ken@bitsko.slc.ut.us xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From macherius at darmstadt.gmd.de Sat Sep 11 16:03:10 1999 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:14:52 2004 Subject: ANN: XML and Databases article In-Reply-To: <000c01befb00$611cc600$0b00a8c0@grissom> Message-ID: <199909111404.QAA15064@sonne.darmstadt.gmd.de> Ken North <ken_north@compuserve.com> wrote at 9 Sep 99, 13:17: > Ingo Macherius wrote > > The other problem is you can store XML, but > > have to explicitely model relations (parent, sibling, child, ... and > > all other axis you need) by foreign keys. > This reads like you always decomposed or mapped XML documents to store them, > as opposed to storing some XML documents as a single column. The choice of > how to store documents in a database will vary on a case-by-case basis, > depending on application needs. First, this is not a plea for help on a customers problem. We are a research institute, so all problems are homemade and imginary. They may, however, be applicable in the real world. And yes, we need a fully decomposed XML view. On top of the database an XQL processor is running, which is implememented in terms of the W3C-DOM methods. I consider XQL (and XPath and all the other variations of XML path-expression QLs) basically as declarative notation for DOM traversals. If there was a fixed schema and XML was an exchange format only I agree with you. The best thing to do is to define fixed mappings, maybe parse some values from the XML into tables, and store the whole XML as a BLOB or VARCHAR. But this can not be done with arbitrary, well-formed XML when you want to query them. The main advantage of storing XML along the "natural" DOM structure is the fact you don't need mappings anywhere. Defining a mapping from XML to a DB schema (e.g. in Oracle8i) always requires administrator interaction, skill, and time. With a DOM-DB solution you just drop in the XML and you are done. Excelon comes very close to this. Of course it depends on what you wanna do with the data. For mostly fixed applications it is reasonable to define a fixed mapping once. But in my case we need to deal with wrapper outputs, so there is no such thing as a fixed schema, there are hundreds :) > > The number of "metatables" with structural information quickly outnumbers > the useful data. > > That's an accepted behavior in the OLAP world -- even more so now that disk > and memory are inexpensive. What hurts is not disk space, but the number of foreign keys and joins to be performed while evaluating a query. The system gets slow, and a simple "checkout" (in XQL the "/" query) may take very long. My knowledge of OLAP is limited, but can this technique(s) model - arbitrary access of structural node-neighbours (sibling, parent, child, namespace, ...) - transparent storage of query-processor internal metadata, e.g. as used for structural indices, along with each node with reasonable access times ? With the PDOM, we can pump through 3.3 MB of XML (or about 160.000 DOM objects) per second without any caching. The number may be 10 times better if the cache is doing fine, but this depends on access patterns. ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@gmd.de http://www.darmstadt.gmd.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Zappa) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mike.champion at sagus.com Sat Sep 11 16:27:17 1999 From: mike.champion at sagus.com (Michael Champion) Date: Mon Jun 7 17:14:52 2004 Subject: W3C's 'Moral Majesty' References: <009f01befc29$15b673d0$37f96d8c@NT.JELLIFFE.COM.AU> <14298.20819.618323.967973@localhost.localdomain> Message-ID: <005b01befc62$2cdf2a50$181d12d1@mccdell> ----- Original Message ----- From: David Megginson <david@megginson.com> To: XML-Dev Mailing list <xml-dev@ic.ac.uk> Sent: Saturday, September 11, 1999 9:12 AM Subject: Re: W3C's 'Moral Majesty' > Face-to-face meetings are > generally more useful for working out political problems than they are > for technical problems, precisely they tend to make it even easier for > a minority of fast-thinkers and loud talkers (like me) to dominate the > discussion: often the best ideas come from quiet, thoughtful people > who need to mull over a new idea for a couple of hours (or days) > before stating an opinion I used to believe this too .... until I got involved in the W3C. My experience has been that face to face meetings provide the collective *focus* that is necessary to move the technical discussions to closure. The ideas may come from quiet thoughtful people and get thrashed around in e-mail, but when it comes time to make a DECISION, keeping 10 or 20 people together until they figure out what they can really live with and what they really can't compromise on is a very effective process. In fact, the thing that kills progress in coming up with specs is "OK, we've agreed in principle, now let's hammer out the little details in e-mail." People get caught up in their obligations back at their day jobs, go on the road, discussion threads get broken, promises forgotten .... until the next face to face meeting forces everyone to focus on drafting the spec again. I certainly agree with the underlying notion that specs could be developed with more diversity of perspective if face to face meetings could be avoided. The keys, I think, are to facilitate the kind of focus and level of commitment that a face to face meeting engenders without forcing people onto airplanes. There's gotta be a way to harness some combination of text editing/revision control, email or instant messaging, and project management/workflow software to make this work better "asynchronously", or at least via shorter, more frequent "synchronous" electronic meetings. It would be fun an illuminating if some IETF or W3C workgroup, or for that matter the xml-dev list, could put something together that proves that the concept works, then maybe that process will start to replace the face to face meeting culture of the W3C. Mike Champion xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 11 16:30:37 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:52 2004 Subject: W3C's 'Moral Majesty' Message-ID: <3.0.32.19990911073154.00bb1320@pop.intergate.bc.ca> At 03:40 PM 9/11/99 +0800, Rick Jelliffe wrote: Rick has committed a basic error of fact, which I absolutely must correct. >"The very thing that makes you rich, makes you poor." Ry Cooder song. That's "The very thing that makes you rich, gonna make *me* poor" -Ry Oh yes, Rick's remarks on the standards process? Sound and sensible IMHO. I'm not as convinced as David that we can lose the Face2Face, if only because it gets people out of their offices and away from their email and phone and forces them to focus on the issue at hand for two days in a row. But it's right that they're a major barrier to entry. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Sat Sep 11 17:09:01 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:52 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <009f01befc29$15b673d0$37f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <199909111511.LAA22651@earth.isni.net> At 03:40 PM 9/11/99 +0800, Rick Jelliffe wrote: >All standards processes are subject to the same constraints that >face-to-face meetings require travel, which requires money. Indeed, >this fact makes W3C into largely a rich Westerners' club; there seems >almost no participation from non-residents of Western countries (except >Japan, which is rich). I think this is a little misleading. A. You don't have to be rich to be involved in the W3C. HWG is a prime example of limited budget, yet commited participation. (we're a non-profit organization (US tax-exempt 501(c)3)) No, we can't send someone to every WG out there, we choose the ones most important to us, and have participation in as many non-travelling Interest Groups as we can. Yes, the expenditures we make are still beyond the means of most individuals, but (for better or worse, a different argument) W3C doesn't allow individual membership. Invited experts often have their participation funded, at least in part, by their employers. It's not impossible to participate for individuals who have the expertise and work at establishing appropriate contacts to be recognized as a viable participant. B. If the complaint is about the lack of Australian firms, or Israeli firms, Indian firms, or some other geographic area being represented, that in part is a function of how many members there are from those areas. A 50MM company in Australia is no different than a 50MM company in Germany in terms of being able to participate. You must make the decision to fund the effort. The W3C is proactively trying to recruit membership in areas that are "underrepresented" through the process of opening offices in new areas (Hong Kong now has one, in terms of the Pacific regions, to name just one), and more are being considered. Within individual working groups, the location of face to face meetings is determined in part by the makeup of the group. If there are 20 participants, 10 are from the US, 5 from Europe, and 5 from Japan/Pacific, you'll probably have 2 meetings in the US, 1 in Europe and 1 in Asia/Pacific over the course of a year. Everyone travels. If, on the other hand, you have 15 participants from Asia/Pacific, 3 from the US, and 1 from Europe, the meetings are likely to be concentrated in Asia/Pacific areas. There's no concerted effort to place meetings in far flung locations just for the hell of it (don't know how many non-WG members have ever travelled 12-14 time zones for a 2 day meeting, but it's not exactly a vacation). In the HTML WG, we've had 3 US meetings, and (counting our meeting coming up in 2 weeks) 2 European meetings. We only have two participants from Japan, and they're both attached to the W3C, so it doesn't make sense to have everyone else travel to Asia at greater expense. And finally, I must agree with Tim wrt: the value of face to face meetings. In fact, if we *weren't* so global in nature, I'd argue for *more* face to face meetings, rather than fewer, as productivity is so greatly increased during those periods. Ann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sat Sep 11 17:33:17 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' References: <009f01befc29$15b673d0$37f96d8c@NT.JELLIFFE.COM.AU> <14298.20819.618323.967973@localhost.localdomain> Message-ID: <37DA7624.37F8@hiwaay.net> David Megginson wrote: > > Business and technical people used to need a lot of face-to-face > contact, but there is a new generation (the under 45's) that's very > comfortable with e-mail and telecommuting, and e-mail is a great > equalizer -- you can pick up mail for a whole group of people just by > setting up an old 286 to dial a local ISP once a day (of course, many > people in the world don't have electricity or phone, much less an old > 286, but at least the circle is a little wider). Without the ageism, the important characteristic is Practice. Those who encourage list communities as a vital aspect of standards and specifications design note that the lists must practice and understand the process of editorial work. The disappointing aspect of this discussion is that this list community has as members some of the best minds in the industry with regards to both the design and the use of the technology created to enable distributed enterprise. That they cannot see that the need to apply the technology to this issue of disenfranchisement means that both vested interest and fear now dominate their actions. Lame, folks. Really lame. > As a case in point, SAX 1.0 was designed and implemented on XML-Dev in > a few weeks without a single F2F meeting. QED, David. It can be done. You do not have to submit to the authority of a single individual in all decisions unless you believe you have to. The idea that the W3C represents some kind of moral majesty is both repugnant and the proof that Tim Berners-Lee and the W3C have failed to produce anything resembling a moral solution. 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 cbullard at hiwaay.net Sat Sep 11 17:42:31 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' References: <199909111511.LAA22651@earth.isni.net> Message-ID: <37DA784F.65BC@hiwaay.net> Ann Navarro wrote: > > And finally, I must agree with Tim wrt: the value of face to face meetings. > In fact, if we *weren't* so global in nature, I'd argue for *more* face to > face meetings, rather than fewer, as productivity is so greatly increased > during those periods. Then, Ann, there is no difference between the processes which the W3C uses to create specifications and ISO uses to create standards. The four F2Fs a year typical in ISO work exactly the same. The difference is ISO produces documented issues and change lists. It uses professional and proven means to edit standards. Where are the issues and reasons for the changes to the XHTML specification being asked for by members of the development community? Produce these and answer their questions or drop the pretense of moral majesty. In effect, the W3C is a consortium trying to write standards and has no moral majesty, just a single authority vested to make decisions. This is neither moral nor more effective: just speedy. Given the results for XHTML and the wide umbrage, that speed may be perceived as bought at the cost of quality. So, the criticism of ISO and IETF in the article is obsequious and underhanded. Don't expect the press to report the right facts as long as the W3C feeds them self-serving propaganda. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Sat Sep 11 17:45:34 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:14:53 2004 Subject: [peter@techno.com: Re: [schen@falconwing.com: Re: DOM and Grove]] Message-ID: <199909110353.WAA02588@bruno.techno.com> ------- Start of forwarded message ------- Date: Fri, 10 Sep 1999 20:44:38 -0500 From: Peter Newcomb <peter@techno.com> Subject: Re: [schen@falconwing.com: Re: DOM and Grove] Hi Dad... Could you forward my response to xml-dev? [schen@falconwing.com on Thu, 9 Sep 1999 19:34:44 -0400 (EWT)] > There's a note in the Property Set Requirements annex of the HyTime > specification: > > NOTE 440 Property sets are designed to support the HyTime and DSSSL > processing and representation of notation-specific data by providing the > information needed by those processes. They are not intended as a general > model for making notation-specific data available for arbitrary > processing. I'd like to emphasize the point that this note tries to make, and possibly clear up its intended meaning. (After all, I have to take full responsibility for the obtuseness of the note...) First of all, this note does not mean that property sets/groves only really support HyTime and DSSSL notations, but rather that they support the representation of only those portions of other notations that are relevant to HyTime and DSSSL engines/applications. The grove paradigm is simply HyTime's answer to the question that Paul so concisely stated: >> * what is the result of hyperlinking into an arbitrary media type? In other words, groves are specifically meant to provide HyTime with the data abstraction layer that was needed in order to identify components of documents or information sets. Note that HyTime doesn't require that the information itself be accessible through the grove, only that the components of the information be identifiable. On the other hand, some types of information lend themselves well to being modeled as groves. SGML (and, of course, XML) is such an information type. DSSSL takes advantage of this by specifying a property set that constitutes a complete data model for SGML, and using it to access the modeled data itself. Other applications can also use this model to access SGML data-- for SGML, a grove is a relatively convenient abstraction for many types of processing. Of course, groves are not always an appropriate abstraction for data processing. It would not be convenient, for instance, to use a grove model of a video stream to perform a contrast-enhancement transformation. It would, however, be convenient to use a grove model of a video stream to select the range of frames to be enhanced. Similarly, a grove model of tables in a relational database may not be a convenient data model over which to resolve queries. Such a model would, however, be convenient for representing the result of such a query. Even better would be to define the grove model of the database such that it reflects the intent of the relational schema being used, in effect defining a view of the database as a single grove. Queries against the database would be resolved with respect to the efficient but possibly non-intuitive relational schema, but the information found using the queries could be viewed using the, IMHO, more humanly-understandable grove model. Of course the main reason that one would want to create a grove view of any information set is so that that information can participate in hyperlink and other relationships along with other information that may be of different types. - -peter - -- Peter Newcomb TechnoTeacher, Inc. peter@techno.com http://www.techno.com/ ------- End of forwarded message ------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Sat Sep 11 17:48:39 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <37DA784F.65BC@hiwaay.net> References: <199909111511.LAA22651@earth.isni.net> Message-ID: <199909111551.LAA24688@earth.isni.net> At 10:42 AM 9/11/99 -0500, Len Bullard wrote: >Produce these and answer their questions or drop the pretense of moral >majesty. Len, I don't claim "moral majesty", nor do I carry any pretenses about it. Nor, however, will I unilaterally decide to make public issues that have not been put into our documents. It is not my place. It is unreasonable to demand it of me. >So, the >criticism of ISO and IETF in the article is obsequious and underhanded. >Don't >expect the press to report the right facts as long as the W3C feeds them >self-serving propaganda. Then go lend your efforts to ISO and IETF and have fun, Len. Nobody's holding you hostage. Ann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Sep 11 19:20:43 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <005b01befc62$2cdf2a50$181d12d1@mccdell> References: <009f01befc29$15b673d0$37f96d8c@NT.JELLIFFE.COM.AU> <14298.20819.618323.967973@localhost.localdomain> <005b01befc62$2cdf2a50$181d12d1@mccdell> Message-ID: <14298.35986.942391.133518@localhost.localdomain> Michael Champion writes: > I certainly agree with the underlying notion that specs could be > developed with more diversity of perspective if face to face > meetings could be avoided. The keys, I think, are to facilitate > the kind of focus and level of commitment that a face to face > meeting engenders without forcing people onto airplanes. There's > gotta be a way to harness some combination of text editing/revision > control, email or instant messaging, and project > management/workflow software to make this work better > "asynchronously", or at least via shorter, more frequent > "synchronous" electronic meetings. It would be fun an illuminating > if some IETF or W3C workgroup, or for that matter the xml-dev list, > could put something together that proves that the concept works, > then maybe that process will start to replace the face to face > meeting culture of the W3C. Throwing more technology at the problem probably won't help: with e-mail, a teleconference, or a face-to-face meeting, it's really the moderator who makes it or breaks it (I'm still a mediocre moderator myself, but I'm willing to learn). 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 lisarein at finetuning.com Sat Sep 11 20:03:57 1999 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:14:53 2004 Subject: confidentiality in W3C WGs References: <01BEFC46.88E67EF0@grappa.ito.tu-darmstadt.de> Message-ID: <37DA9E7F.BE9551C4@finetuning.com> It has been my experience that both: 1) They put it in the spec if they think of it. 2) Someone in the group will tell you if you ask them (private email is sometimes better than mailing list email -- you can't tell me (any of you) that you don't maybe leave out details sometimes when you post to a public mailing list -- you're inviting a public discussion that you might not always have the time to have to monitor adinfinitum (or until the damn thread dies down) -- whereas with an individual you can answer their question and if they have another, they can ask that too! 3)I guess my biggest problem with all these complaints about the process is that I, personally, have NEVER had a problem finding out the technical nature of anything occurring in a W3C spec. Period. (except those things where the working group themselves hadn't gotten around to blessing the "thing" itself yet -- in which case whoever I've written will say -- we don't know if that's going to stay that way -- and that's it) I will admit that sometimes the explanation of the rationale goes "over my head" as it were, in which case I will usually spend a few emails trying to understand it, in which case, consistenty, whomever I have contacted has always been willing to help me figure it out. Now, sometimes I don't agree with the rationale, but I don't argue about it. If I wanted to argue about it THAT's when you go to the public discussion list and take it from there (and not THIS public discussion list, please! This isn't the "my beefs with every W3C spec" list, is it? Sometimes I wonder!) lisa Ronald Bourret wrote: > > Reynolds, Gregg wrote: > > > Here is the best you will ever get without an open process: the reason > > proposition X passed is that it got the most votes. I'm not making a > joke: > > that IS the reason XHTML got three name spaces, and its the only reason. > > Why doesn't matter. > > Why does often matter. Here's two reasons: > > * Why helps explain what. As a simple example of this, consider the design > goals at the start of each W3C spec. These certainly aren't required by > the rules written in the spec, which are undoubtedly clear, concise, and > unambiguous ;), but they go a long way towards setting up the context in > which the reader understands the spec. > > * Why helps adoption. If there's a hard technical trade-off to be made in a > spec, the result is not going to make everybody happy. Explaining why helps > people understand why the decision was made as it was and gives them a > stake in that position. Telling them what only leaves them confused, > annoyed, and ready to jump ship for something better. Dictatorships and > democracies both work, but democracies get a lot more genuine support. > > Why doesn't have to be directly in the spec, but it needs to be somewhere > more than in just a few people's heads. > > -- Ron Bourret > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Sep 11 20:34:36 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' Message-ID: <3.0.32.19990911113544.00bc5790@pop.intergate.bc.ca> At 01:21 PM 9/11/99 -0400, David Megginson wrote: >Throwing more technology at the problem probably won't help: with >e-mail, a teleconference, or a face-to-face meeting, it's really the >moderator who makes it or breaks it (I'm still a mediocre moderator >myself, but I'm willing to learn). Another issue is the size of the group. A committee with 10 people can do approximately twice as much work as one with 20. Some of the reasons are obvious, others more subtle - in a relatively small group, after a while, you get better mutual understanding and thus have to do less work to explain a complicated issue, and in fact you just get more practiced and skilled at working toward consensus. This is one advantage of the W3C process, where you have a small and relatively productive WG and an arbitrarily-large interest group where all the shouting happens, that makes sure that you get a really wide range of inputs. People who were along for the original XML 1.0 ride will remember that on several occasions, the WG took some decision and the IG basically just wouldn't stand for it, and howled in outrage until the WG reversed itself. Sometimes 2 or 3 times on the same issue. Another intangible is that virtually all the (couple of hundred) people who were on the original XML IG became ardent advocates of XML, and for my money one of the reasons that XML is doing well is the existence of this attack team, that may have flamed away at a couple of the design decisions but basically bought into the shared understanding of what XML was about. Now, that might be seen as an argument for a more IETF-like process where you get a *really* large team of evangelists. Or maybe not. -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 donpark at docuverse.com Sun Sep 12 04:02:19 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <3.0.32.19990911113544.00bc5790@pop.intergate.bc.ca> Message-ID: <000501befcc3$63276120$1b7afea9@w21tp> 1. F2F and weekly telephone conferences Without a doubt, both forms of meetings are valuable. Faces and voices encourage people to work closer and reduces extremism through bonding and group behaviors. However, these meetings are not efficient enough to justify the cost of participation to individual members. If the WG member is an employee of a large company, then the cost is less and even enjoyable to certain extent. If the WG member is an independent developer/consultant, the cost is high enough to prevent participation unless the member also happens to be the Chair. I have been to only one WG F2F meeting and I found it painfully boring, tiring, and also disgusting to certain extent. Creativity is discouraged, progress is measured in number of easy decisions and issues raised, difficult decisions are deferred without exception, myriad issues are chewed enthusiastically only to be spitted out and left on the floor like cheap gum, political complications are raised and usually dealt with sarcastic jokes which leaves the conflict hidden and dangerous, dinner conversations are laced with petty thoughts, bureacratic whining, and blatant discussion of personal gains. Discussion of F2F meeting location is not based on reason but pleasure without regard to cost. A meeting at South of France is great if your company is paying for it but not if it is coming out of your pocket. Telephone meetings are more efficient than F2F except there is no room for indepth discussions. It is a breeding ground for hasty decisions without proper representation of the issues. 2. Mailing lists Both WG and IG mailing lists are great but unsearchable and private. Confidentially is too broad and laced with political issues which ends up reducing representation of the outsiders. Issues are raised, dropped by inattention, and killed by time. Field of vision in mailing list discussions is one dimensional (even with hyperlinks) which restricts awareness and thus limits the level of complexity the WG can deal with. All this is encouraged indirectly by W3C and its policies. If W3C can change itself, it should first relax its policy to reflect public opinions more formally rather than at mercy of WG members' kindness. It should also install policy of independence from W3C bureacracy. The director should be stripped of his unspoken right to interfere with his unfairly heavy hand. Second, W3C should start using and investing in groupware tools that allows efficient and focused online meetings, bookkeeping of issues and decisions so that status, factors, and justificaitons can be seen at a glance. We must change W3C to fit the changing needs. W3C must allow us to change it because it can not change itself. Most of all, W3C must stop being arrogant bureacratic fools with grandeur self image of being THE innovative leader with THE right vision. To me, W3C is Tim Berners-Lee. Tim, you must stop thinking that you have a monopoly on the future vision. Instead of pushing your vision, try building a place where visions of others from far abroad can come together and interact so that the right vision can be born out of them. Be a mother, not a father. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 12 05:36:15 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:53 2004 Subject: enumeration and defaults In-Reply-To: <199909102031.QAA17913@hesketh.net> from "Simon St.Laurent" at Sep 10, 99 04:34:23 pm Message-ID: <199909120414.AAA04299@locke.ccil.org> Simon St.Laurent scripsit: > I've found myself in a somewhat odd situation, where I'd like to be able to > include empty (i.e., no value) as a choice in a list of enumerated > possibilities. It doesn't seem possible. (Empty is not a token.) > > It might be nice to declare: > <!ATTLIST myElement > myAtt (0|1|2) #IMPLIED> > > but it isn't clear to me what the implications are. If I just write: > <myElement /> > > I haven't provided a 'wrong' value for myAtt, but I haven't in fact > provided a value that matches an entry in the list. That is all right: in fact, it's commonplace. A declaration like <!ATTLIST OL compact (compact) #IMPLIED> such as is found in the DTD for XHTML 1.0 Transitional, means that either <OL> or <OL compact="compact"> is legal. > I may simply be lacking a key set of assumptions, but I feel like I could > read the spec either way. Does no default value mean that there is no > value to check against constraints, or does it imply a null value that will > violate constraints of this sort? The former. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Sun Sep 12 06:04:58 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' References: <009f01befc29$15b673d0$37f96d8c@NT.JELLIFFE.COM.AU> <14298.20819.618323.967973@localhost.localdomain> Message-ID: <37DB26DC.4FFBBF60@pacbell.net> David Megginson wrote: > > Rick Jelliffe writes: > > > [ folk other than first world are "disenfranchised" ] > > > > There are four approaches: > > * "that is the way of the wor[l]d": it cannot be helped; > > * positive discrimination, e.g. subsidies; > > * reduce the reliance on face-to-face meetings; > > * universal enfranchisement. > > The third is by far the best solution. Face-to-face meetings are > generally more useful for working out political problems than they are > for technical problems, I tend to agree -- "reduce". This is the 1990s after all, at least for another few months, and it's OK to use technology to improve the decision making of an organization like W3C !! Of course there's a real issue that there DO exist political problems that need working out. There are real dollars (whoops, sorry Rick ;-) riding on this stuff, and those decisions filter into technical stances too. And those political problems can relate to focus and direction (as Mike Champion has noted). F2F meetings of a core constituency can be great enablers; though of course they can also be overdone (just like the secrecy of W3C is clearly, IMHO, overdone). On-line communities work best if they're adjuncts to offline ones, and I think XML-DEV reflects that: there are key players who know each other off-line to various degrees. Outside of W3C, I know that a main function of F2F meetings is to facilitate the personal side of things -- be it pub crawling a new city, or hammering out issues when you've got real person-to-person bandwidth, or whatever. That's also an issue with W3C's intended role, which isn't quite the role it actually has. The intended role (per that article) is essentially "advanced development" (AD) ... the sort of thing that in a group like the IETF is done in very open working groups and without any particular commercial timetable in mind. That sort of AD work is easily (perhaps habitually) done on open mailing lists; that's often how academic folk work, and it's the best way to see what the important issues are (vs having companies tell you what their pet issues are). The reality of W3C's role is that it's putting out specs that get used in commercial products as "the Next Big Thing" regardless of the fact that, in the big scheme of things, they've not been well cooked. (That helps the marketing folk a lot more than the techies who are well represented on this list!) Plus, there's no real expectation that two vendors can just just the W3C spec when they create implementations -- there are no conformance "teeth" as in a real standards organization, again displaying a marketing bias. That is, the W3C academic/AD role isn't its real world role. And that's another reason to call attention to the expense of F2F level participation: it reflects the real world role, not the chartered "advanced development" sort of role. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Sun Sep 12 06:29:16 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' References: <3.0.32.19990911113544.00bc5790@pop.intergate.bc.ca> Message-ID: <37DB2C8F.389AC987@pacbell.net> Tim Bray wrote: > > People who were along for the original XML 1.0 ride will > remember that on several occasions, the WG took some decision and > the IG basically just wouldn't stand for it, and howled in outrage > until the WG reversed itself. Sometimes 2 or 3 times on the > same issue. Did the WG then dust off one of the original proposals, or was it more of a "spiral development" process than a true reversal? Successive refinement is critical to making design processes work, and it's typical to have some core team (even in a geographically dispersed mailing list :-) be responsible for moving forward in such a "spiral" development process. > Another intangible is that virtually all the (couple of hundred) > people who were on the original XML IG became ardent advocates of XML, > ... > > Now, that might be seen as an argument for a more IETF-like process where > you get a *really* large team of evangelists. Or maybe not. -Tim >From my observation of, and participation in, the IETF I'd say that's not quite the process that happens there. It's more of an "open source" thing where the whole system is open enough that either there's some real consensus supporting each forward movement, or it can't go anywhere at all. (Snd without such consensus, there's no loss.) And of course, there's no notion of central control -- people can work on OpenPGP and S/MIME concurrently, nobody's able to prevent OpenPGP from moving forward because they like the vendor lock-in potential of S/MIME (which is rather complex due to its use of ASN.1/BER). There's no TimBL analogue who is able to say "screw you, this is how it'll be" -- and who is dependent on secrecy to prevent negative stories from getting out in any very significant way, disproving the "moral majesty" claims. (Maybe I'll meet Tim in person someday, and find him a nice guy, but I don't hear his W3C role as really reflecting such "moral majesty".) The IETF approach is more "big tent" than W3C since in the IETF the architectural decisions are decentralized, AND the process is designed to permit competing approaches to progress -- except on standards track things, where consensus really matters. Meanwhile W3C (staff, bureaucracy, and all) can dictate what goes on in the absence of consensus, and with no real attempts to consider alternatives which may be better. In the long run, I don't think that the non-consensus approach is viable. But it's clearly having a strong impact in the short term, even if folk do not agree whether it's always a positive one. It may have been needed to get folk out of the mess preceding HTML 3.2 ... but I'm not sure that such non-consensus approaches are needed any more, except in the "get your browser to support HTML 4.0 and CSS and XML" sort of ways. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Sun Sep 12 06:44:02 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' References: <199909111511.LAA22651@earth.isni.net> Message-ID: <37DB3006.30FE020B@pacbell.net> Ann Navarro wrote: > > There's no concerted effort to place meetings in far flung locations just > for the hell of it (don't know how many non-WG members have ever travelled > 12-14 time zones for a 2 day meeting, but it's not exactly a vacation). One of the things that some "standards" bodies do is try to group many working group F2F meetings in one place at the same time. I'll point at the IETF and the OMG here. That not only permits folk to get to multiple F2F meetings on one plane ticket (saving costs!!) but it also facilitates having wider exposure of the issues that are driving any given working group, and facilitates cross-pollination. (W3C evidently tries to have its own staff do that cross-pollination, which has some issues.)) And of course, anyone who does travel 12-14 time zones without any plan for a vacation has my sympathy. I suggest one day per zone. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Sep 12 06:49:03 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' Message-ID: <000601befcdb$01049ef0$52f96d8c@NT.JELLIFFE.COM.AU> From: David Megginson <david@megginson.com> >The reliance on text is important for accessibility -- both >visually-impaired people can have text read to them by software, while >hearing-impaired people can read it; diagrams don't work as nicely. On the other hand, text reduces comprehensibility for people for whom English is the second language, and even for those of us who have more graphical imaginations. I think these outweigh the number of visually-impaired, but of course, there is no reason why both graphics and text cannot proivde alternatives. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Sep 12 07:17:04 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:14:53 2004 Subject: W3C's 'Moral Majesty' Message-ID: <003101befcde$f10d9110$52f96d8c@NT.JELLIFFE.COM.AU> From: Len Bullard <cbullard@hiwaay.net> >QED, David. It can be done. You do not have to submit to the >authority of a single individual in all decisions unless you >believe you have to. The idea that the W3C represents some >kind of moral majesty is both repugnant and the proof that >Tim Berners-Lee and the W3C have failed to produce anything >resembling a moral solution. This seems to be turning into "why T.B-L is bad for the WWW" which is completely against the point I was trying to put forward: personally, I think the idea of someone (or body) at the top whose primary job is to unblock logjams is good (indeed, my countries political constitution is based on this, very successfully). If the W3C presents itself as a "standards-making" body, then it must systematically address questions of global fairness to have credibility. But I think it is not a standards-making body in the sense that ISO is: I see the W3C as like a big happy elephant that poops out technology at intervals, and if one has a garden to grow and a shovel to pick the technology up with, it is a good thing. In other words, the criticisms of W3C closed procedures etc are the natural result of the pretense of standards-making. Rick 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 rbourret at ito.tu-darmstadt.de Sun Sep 12 10:40:03 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:53 2004 Subject: ANN: XML and Databases article Message-ID: <01BEFD0B.C3BF3BF0@grappa.ito.tu-darmstadt.de> Ken MacLeod wrote: > What more are you expecting? If we were to say that groves provide > all the same functions you attribute to the XML world but without > being tied to XML specifically, wouldn't that alone be worthwhile? It wasn't a matter of expectations or whether groves are worthwhile -- they certainly seem to be. I'm just curious what capabilities are available and if there's anything obvious I'm missing, in the sense that SAX might be obvious to someone who's worked with XML for a while, but not to a newcomer. > Note that in many cases, the tools and specs for working with XML can > easily be adapted to work with groves. So my question still stands: which of these capabilities are there today? That is, which linking / querying / navigating / whatever specs have already been designed to work with groves and for which of these are there tools today? -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Sun Sep 12 15:24:06 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:14:53 2004 Subject: DOM and Grove In-Reply-To: <37D7F01A.2B90@hiwaay.net> Message-ID: <NBBBJPGDLPIHJGEHAKBAAEKMEBAA.martind@netfolder.com> Hi Len, These are words of wisdom Len. What we re-discover is that history repeats itself and that sometimes (or should I say often) humanity is slow to learn from its mistakes. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Len Bullard Sent: Thursday, September 09, 1999 1:36 PM To: Paul Prescod Cc: xml-dev@ic.ac.uk Subject: Re: DOM and Grove Correct. Not just possible; it's happening. This is precisely what the IETM community faced in the late eighties and early nineties. The answer was to convert everything to HTML to get the job done. Now they have to convert again. Every time that is done, the costs recur and the information gets a little more damaged. While it is hard on some to understand terms like "notation", it is vital to understand what Paul is saying. This is where everything stopped. This where CALS broke down. This is where the war was lost and the shaky structure known as the World Wide Web emerged a winner because no two ISO committee heads could agree. Study the history of CGM. Look at the relentless duplication of the effort of SGML for reasons I still cannot fathom. Note how SGML was blamed. Look at what is happening in other notations being invented today for graphics. Note the deliberate duplication of effort spent trying to keep separate syntaxes. Note how XML is blamed. Study groves. Write the simplified explanations if you need them. You do need them. len >Paul Prescod wrote: > > The real reason groves were invented was > to answer the question: > > * what is the result of hyperlinking into an arbitrary media type? > > What are the properties of the abstract object returned? The grove > answers that question: the object has properties such as "parent", > (possibly null), "children" (possibly null), "containing entity" and so > forth. > > You cannot build a sophisticated hypertext system without answering that > question. This will become apparent after XLink, XPointer and RDF are > implemented. We'll start to see many divergences of behavior when links > are made into (e.g.) PDF, MPEGs, JPEGs and so forth. Over time we will > need to develop a framework for describing the correct results of links > in a generic way. Then we will reinvent groves. > > Or not... we could keep doing things in an ad hoc manner for ever I > suppose. It would be expensive and inefficient but it is possible. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From martind at netfolder.com Sun Sep 12 15:24:11 1999 From: martind at netfolder.com (Didier PH Martin) Date: Mon Jun 7 17:14:54 2004 Subject: Groves, the next big thing (Re: ANN: XML and Databases article) In-Reply-To: <016401befad7$19d49f30$091d12d1@mccdell> Message-ID: <NBBBJPGDLPIHJGEHAKBACEKMEBAA.martind@netfolder.com> Hi Michael Micheal said: ------------------------------------------------ There are three basic reasons why the DOM is not more groves-like. First, as someone pointed on earlier in the "XML and Databases" thread, not enough people outside the hard-core SGML/XML community understand the groves paradigm, so there was no general familiarity that we felt we should leverage. Second, the available documentation for groves (at least a couple of years ago) was mainly the DSSSL spec, which is very difficult for non-specialists to make sense out of. Third, there was a widespread perception that the groves model implies, in DOM terms, that "every character is a node", and people concerned about implementing the DOM API felt strongly that this would lead to unacceptable footprint and run-time overhead. Didier says: ------------------------------------------------ I agree the specs are usually not enough to sell something. If XSL or CSS is popular its mainly because library shelves are becoming full of books about it. Actually there is very little work done about DSSSL except to say it is difficult. I personally think that it has been very badly explained and sold. Sorry about the XML technical marketers you encountered, they probably lacked a good tech/marketer in their team to do the bridge. They could have simply introduced (as Paul Prescod did ) DSSSL at the same level as CSS. Just look at the example below and notice the similarities. Just, sit and relax and observe the two expressions, let go any preconceived idea and just trust your perception system. CSS par { display: block font-size: 1.3em } DSSSL ( element par (make paragraph font-size: 10 pt ) ) At the minimum DSSSL could be used simply like CSS - without the expression language. It is only the expression language (quite powerful) that adds difficulties (mainly because people are not used to its lispish syntax). However, DSSSL could be used as CSS - simply as a basic style language without any expression language. Thus to have a beginner level (only style) and an advanced level (with expression language). So the next time the XML technical marketing people you spoke about are having difficulties sorting a technology into beginners and advanced level please give them my email, I'll be glad to help them make complex things simple (Didier PH Martin martind@netfolder.com). Michael said: --------------------------------------- Groves may or may not become the next Linux; if this is going to happen, two obstacles must be overcome. Most importantly, someone is going to have to write a *clear* statement of the paradigm, its power, why it's "the next big thing, etc. Sortof "Groves for Dummies", or the "Grove Manifesto". I can't stress enough the importance of writing this for a fairly general audience. I recall conversations a couple of years ago with very smart technical marketing people at large companies who are now big players in the XML world; the level of fustration they expressed at trying to make sense out of things like the DSSSL spec was quite memorable! I have not read the recent attempts by groves adovocates to offer tutorials, etc., so forgive me if this has already been done. I frankly doubt it, because if a clear and compelling case for the groves paradigm has been made, it hasn't come to the world's attention. Also, even if the "grove paradigm" is a fundamentally more powerful way of looking at XML and other types of data than what is in wide use today, it's unlikely to be adopted unless there is a clean migration path from familiar APIs like ODBC/SQL, the W3C DOM, the (forthcoming?) JCP XML data binding spec, etc. One of the most eye-opening aspects of my experience on the DOM WG has been to understand that most users of Web scripting languages, Visual Basic, etc. know very little about computer science. I began my DOM "career" assuming that everyone who would be using such APIs understood tree and graph data structures and would understand how nicely they represented the types of things we were talking about. I was quickly set straight by my colleagues from companies with larger customer bases: ARRAYS are about as sophisticated a data structure as the typical Web scripter or VB programmer can handle. [I *know* that someone reading this wants flame me, but rest assured that I don't like this notion any more than you do, and just about every conceivable counter-argument has been raised, and very reluctantly dismissed, by the DOM WG already.] So, I would *love* to see someone define a grove API that extends the DOM, and/or to see the grove paradigm cleanly incorporated into the Java Community Process XML data binding, and/or to see a repository-friendly API that builds from ADO or JDO and incorporates groves concepts. But don't expect the typical consumer of XML APIs to be impressed by a groves API that offers a "new paradigm" that assumes that the reader understands graph theory and data structures and builds up from there with little reference to existing efforts. Didier says: ---------------------------------------------- I agree with you on that point Michael, a lot of people do not have enough knowledge nor time to learn that groves are abstract data models. They need API to implement things. Now speaking of APIs, it would have been possible to create an API inspired from groves and following the composite pattern. This would have lead to an more extensible API. The basic idea behind groves is that they are hierarchical structures and as such, the perfect match for navigating in a hierarchical structure is an API based on the composite pattern (gamma & al.). Also, groves are not condemme to a single model. Grove could be based on different models (i.e. the document model, the hyperlink model, etc..) For example ADSI is based on the composite pattern and can support several hierarchical directories are near directories. It support different model and schemas. So, as already shown by ADSI and people just knowing VB, javaScript and basic scripting language, this API is useful to these people and understood. Thus, it is possible to create a simple, extensible API based on grove concept. regards Didier PH Martin mailto:martind@netfolder.com http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Sun Sep 12 16:14:27 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:54 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <37DB3006.30FE020B@pacbell.net> References: <199909111511.LAA22651@earth.isni.net> Message-ID: <199909121417.KAA07032@earth.isni.net> At 09:45 PM 9/11/99 -0700, David Brownell wrote: >Ann Navarro wrote: >> >> There's no concerted effort to place meetings in far flung locations just >> for the hell of it (don't know how many non-WG members have ever travelled >> 12-14 time zones for a 2 day meeting, but it's not exactly a vacation). > >One of the things that some "standards" bodies do is try to group >many working group F2F meetings in one place at the same time. I'll >point at the IETF and the OMG here. Do people really think that doesn't occur with the W3C? There seem to be an awful lot of negative assumptions going around. Yes, meetings are coordinated, both within the W3C and with events outside (AC meetings are now coordinated with the WWWx events, this past May in Toronto, next May in Amsterdam. Many WGs appended meetings to these events based, in part, on the fact that a majority of participants would already be there. > (W3C evidently tries to have its own >staff do that cross-pollination, which has some issues.)) What is that based on? Yes, there's a staff contact on every group -- and they tend to specialize within certain fields (Dan tends to do XML groups, etc). But that doesn't mean that's the *only* occurance of multiple group participation. >And of course, anyone who does travel 12-14 time zones without any >plan for a vacation has my sympathy. I suggest one day per zone. Raises the cost of participation exponentially, no? ;) Ann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cgfield at email.msn.com Sun Sep 12 18:27:03 1999 From: cgfield at email.msn.com (C. Field) Date: Mon Jun 7 17:14:54 2004 Subject: linking, breaks - simple question Message-ID: <011601befd3a$d47c50c0$0a71fed0@oemcomputer> I have just read a few books over the weekend and I am very new to this. I was wondering if someone could please help me out on two basic questions. How do you get links to work in XML, and how about line breaks or spacing in content. I use style sheets, but I only see DIV or blocks to break up units of content. I want to actually have breaks in my content located in the xml document. Below is my simple document. Can anybody help me out? Thanks in advance, and sorry for the simplicity of this question, but I am just getting started. C.Field <?xml:stylesheet type="text/css" href="instr.css"> <?xml version="1.0" standalone="no"?> <!DOCTYPE InternetClass [ <!ELEMENT InternetClass (title, section+)> <!ELEMENT SECTION (topic,example,code+,sites+)> <!ATTLIST SECTION area CDATA #IMPLIED> <!ELEMENT TITLE (#PCDATA)> <!ELEMENT TOPIC (#PCDATA)> <!ELEMENT EXAMPLE (#PCDATA)> <!ATTLIST EXAMPLE number CDATA #REQUIRED> <!ELEMENT SITES (#PCDATA)> ]> <InternetClass> <TITLE>Advanced Internet Class
Javascript Book javascript(windows){ x = other stuff }
XML Book http://www.xml.com/xml/pub/tools/ruwf/check.html http://www.networking.ibm.com/xml/XmlValidatorForm.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 cbullard at hiwaay.net Sun Sep 12 20:40:04 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:54 2004 Subject: W3C's 'Moral Majesty' References: <003101befcde$f10d9110$52f96d8c@NT.JELLIFFE.COM.AU> Message-ID: <37DBF191.3045@hiwaay.net> Rick Jelliffe wrote: > This seems to be turning into "why T.B-L is bad for the WWW" > which is completely against the point I was trying to put forward: > personally, I think the idea of someone (or body) at the top whose > primary job is to unblock logjams is good (indeed, my countries > political constitution is based on this, very successfully). The idea in ours is that in a deadlock vote, one man or woman, can break a tie. Otherwise, the executive branch can propose and lobby for legislation and acts as top cop. It cannot thwart majority rule. The person of the Tim-BL is not relevant except insofar as it preserves the role of one person who can thwart majority rule. This is not a good role to assume regardless of who assumes it. So, this is not a "Tim is bad" but a "Tim can change his mind about his decisions with regards to his role". That is a fair thing to ask. Look at the role of Washington in the US. When the time came to pass the office of the presidency, it was done without force. It was considered a marvel at the time and a credit to his capacity as a leader. That is moral majesty. > In other words, the criticisms of W3C closed procedures etc > are the natural result of the pretense of standards-making. Yes. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sun Sep 12 20:40:07 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:54 2004 Subject: W3C's 'Moral Majesty' References: <3.0.32.19990911113544.00bc5790@pop.intergate.bc.ca> Message-ID: <37DBEE4E.1D1@hiwaay.net> Tim Bray wrote: > > Now, that might be seen as an argument for a more IETF-like process where > you get a *really* large team of evangelists. Or maybe not. -Tim The original WG was made up of people who for the most part, were long time members of the original markup community. They had practice in debate, understood the issues, and tolerated each other well. They came by invitation and were committed to results. There is always an inner core team that does the nit work. This is a good means and acceptable. The issues here revolve around getting documented technical reasons for technical changes to the community that exists outside the W3C dues paying members. It is possible to do this. It requires a change by the director, Mr. Tim Berners-Lee and a ratification by the membership of the W3C. This should be presented as an issue of high importance. The technology can be used to assist in the editorship and the evaluation of comments as well as the archival of this technical document. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sun Sep 12 20:55:34 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:54 2004 Subject: W3C's 'Moral Majesty' References: <199909111511.LAA22651@earth.isni.net> <199909111551.LAA24688@earth.isni.net> Message-ID: <37DBF6AF.1CB8@hiwaay.net> Ann Navarro wrote: > Len, I don't claim "moral majesty", nor do I carry any pretenses about it. It is the organization. The moral majesty of an individual should correspond to their role. The actions of the organization are in the hands of the members. > Nor, however, will I unilaterally decide to make public issues that have > not been put into our documents. It is not my place. It is unreasonable to > demand it of me. You cannot, in effect, break the contract to which you or your organization have signed. You can as an individual undertake to change the conditions of that contract if they are injuring the community. That is not unreasonable but you decide if that is your place. > Then go lend your efforts to ISO and IETF and have fun, Len. A nice kiss-off and perhaps deserved. What I have done and do are not within your purview. I do consider it prudent to answer misleading statements about the work, processes and achievements of the men and women I worked with in ISO on occasion. Those achievements and those individuals built the foundations on which the W3C work in markup stands. You have not done this. Do you consider it something that can be overlooked? > Nobody's holding you hostage. Quite right. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sun Sep 12 20:55:42 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:54 2004 Subject: W3C's 'Moral Majesty' References: <009f01befc29$15b673d0$37f96d8c@NT.JELLIFFE.COM.AU> <14298.20819.618323.967973@localhost.localdomain> <005b01befc62$2cdf2a50$181d12d1@mccdell> <14298.35986.942391.133518@localhost.localdomain> Message-ID: <37DBF717.8D6@hiwaay.net> David Megginson wrote: > > Throwing more technology at the problem probably won't help: with > e-mail, a teleconference, or a face-to-face meeting, it's really the > moderator who makes it or breaks it (I'm still a mediocre moderator > myself, but I'm willing to learn). Using the technology that was designed for precisely this set of requirements seems to me to be the best test of that technology and the proof of the reasonableness of the requirements. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mda at discerning.com Sun Sep 12 21:40:31 1999 From: mda at discerning.com (Mark D. Anderson) Date: Mon Jun 7 17:14:54 2004 Subject: namespace of attributes? Message-ID: <837149950.937140020@MDAXKE> in REC-xml-names, section A.2 says in part: "The Per-Element-Type Partitions Each type in the All Element Types Partition has an associated namespace in which appear the names of the unqualified attributes that are provided for that element. This is a traditional namespace because the appearance of duplicate attribute names on an element is forbidden by XML 1.0. The combination of the attribute name with the element's type and namespace name uniquely identifies each unqualified attribute. In XML documents conforming to this specification, the names of all qualified (prefixed) attributes are assigned to the global attribute partition, and the names of all unqualified attributes are assigned to the appropriate per-element-type partition." However, section 5.3 says that this example is acceptable because "the default namespace does not apply to attribute names: " So does this mean that A.2 should be clarified to say that unqualified attributes should not be assigned the per-element-type partition if it obtained its namespace through a default namespace? And what is a namespace-aware validator (is there such a thing?) supposed to do here? If "good" was declared as then which have i defaulted, a global "b", or a "n1:b"? and is the "a" attribute in violation of the dtd while n1:a is not? is it in violation because it was not declared or has the wrong value? -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 elharo at metalab.unc.edu Sun Sep 12 23:50:54 1999 From: elharo at metalab.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:14:54 2004 Subject: Bush Donor Lists in XML In-Reply-To: <37DBEE4E.1D1@hiwaay.net> References: <3.0.32.19990911113544.00bc5790@pop.intergate.bc.ca> Message-ID: Friday Governor George W. Bush of Texas posted complete records of his campaign contributions on his web site. However, he deliberately posted them in PDF format so they couldn't be imported into a database or a spreadsheet, and consequently reporters and voters couldn't find out just how much of his money was coming from whom. Or at least that's what he thought. :-) I am pleased to announce, that after a few hours of intense hacking I have succeeded in extracting the crucial information from the PDF files and have posted them online in XML and tab delimited formats for anybody who wants them. Accountants, start your spread sheets! You'll find the files at http://metalab.unc.edu/javafaq/bush/ I've written a very simple DTD for the XML version. Based on this DTD the results do appear to be well-formed and valid (though I've been burned by misbehaving validators before). The first two validators I tried gave up on trying to parse such a large (more than eight megabytes) document. Interestingly, the initial conversion to XML did turn up some bugs in my PDF-to-text converter program, but the validation of the XML did not find any additional problems. I can see where a schema language would be very useful for this sort of reverse engineering work though. Eventually I may try to cook up a more serious DTD that more closely matches the FEC's actual required format for filing electronic copies of donor lists. I'm also going to try to add a simple XSL stylesheet to these in the near future, but they're so large that they really challenge anyone trying to browse them directly. +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | The XML Bible (IDG Books, 1999) | | http://metalab.unc.edu/xml/books/bible/ | | http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://metalab.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Sep 13 02:40:31 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:54 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <37DBF191.3045@hiwaay.net> References: <003101befcde$f10d9110$52f96d8c@NT.JELLIFFE.COM.AU> <37DBF191.3045@hiwaay.net> Message-ID: <14300.18403.955077.363493@localhost.localdomain> [offline] Len Bullard writes: > Rick Jelliffe wrote: > > > This seems to be turning into "why T.B-L is bad for the WWW" > > which is completely against the point I was trying to put forward: > > personally, I think the idea of someone (or body) at the top whose > > primary job is to unblock logjams is good (indeed, my countries > > political constitution is based on this, very successfully). > > The idea in ours is that in a deadlock vote, one man or woman, > can break a tie. Otherwise, the executive branch can propose > and lobby for legislation and acts as top cop. It cannot > thwart majority rule. I don't know a lot about the U.S. constitution, but as I understood it, it takes a two-thirds majority to override a presidential veto, not 50% + 1. The problem in the W3C is that even a 100% majority cannot override a directorial veto; the benefit is that it's relatively easy for the members to vote with their feet. 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 zzyzlane at gte.net Mon Sep 13 03:04:03 1999 From: zzyzlane at gte.net (Christopher Lane) Date: Mon Jun 7 17:14:54 2004 Subject: Thanks for the sanity check Message-ID: <37DC4EF4.4CF2560C@gte.net> David Megginson's comment | OK, let's run a quick sanity check on IBM's top-level Web page (http://www.ibm.com/) | Thanks, David, for the reality check! IBM's whole corporate intranet is a richness of embarrassment. They use these crusty old, web-type forms, "templates" that design all pages to look nearly alike. But they also have a great lot of so-called "standards" that we writers at the lower levels are supposed to observe. And one of those, believe it or not, is to "as much as possible get ready to be in compliance with the up-and-coming XML standard"! Well, I'm one that didn't need to be convinced about that, anyway. But I've noticed that a huge number of the intranet pages do not conform even to their most basic published "standards." To give one trivial example, all web pages are supposed to "display some content" within no longer than 10 seconds on a 28.8 modem! When I'm on the intranet at work, I'm on a 100MB LAN than runs out to a SONET-based web, and even at 7 in the morning, the IBM corporate intranet pages don't display within anything approaching 10 seconds. We recently were directed to go to a training session that supposedly the president of the company was wild about, and wanted everyone in the company to attend. One of the trainers made the following statement, reviewing the topology of the typical corporate intranet: "The firewall is the place where they screen out viruses, and things like that"! I chalk it up to fear, and old time conservatism. They are really scared about being left behind like they were with the PC debacle. So, they give a lot of visibility to things like the IBM Alphaworks Java-based XML parser. But putting into actual practice is another story. Christopher Lane E-mail at home: zzyzlane@gte.net E-mail at work: clane2@us.ibm.com page: http://home1.gte.net/zzyzlane/index.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jlapp at webmethods.com Mon Sep 13 03:06:45 1999 From: jlapp at webmethods.com (Joe Lapp) Date: Mon Jun 7 17:14:54 2004 Subject: namespace of attributes? In-Reply-To: <837149950.937140020@MDAXKE> Message-ID: <199909130109.SAA13531@snipe.prod.itd.earthlink.net> At 12:40 PM 9/12/1999 -0700, Mark D. Anderson wrote: >[...] >So does this mean that A.2 should be clarified to say that unqualified >attributes should not be assigned the per-element-type partition if it >obtained its namespace through a default namespace? I believe 5.3 and A.2 are both correct and consistent with each other, although I have to admit that the spec originally gave me trouble too. My conclusion was that it is *not* possible to put an attribute in the default namespace. An attribute goes in the per-element namespace unless the attribute explicity has a prefix that assigns it a namespace. >And what is a namespace-aware validator (is there such a thing?) supposed >to do here? If "good" was declared as > >then which have i defaulted, a global "b", or a "n1:b"? >and is the "a" attribute in violation of the dtd while n1:a is not? >is it in violation because it was not declared or has the wrong value? I had trouble making sense of your ATTLIST declaration, but I don't believe it is possible to assign namespaces to anything but element or attribute instances unless you use ATTLIST to define a default xmlns value for every element. Consider a DTD that contains the following declarations: To which namespace does e3 belong? I can only conclude that DTDs and namespaces don't mix. However, I'm believe that the namespaces of the elements and attributes in the following DTD subset is unambiguous and uncontroversial: -- Joe Lapp (Looking for some good people to help design Senior Engineer and build the Internet's business-to-business webMethods, Inc. XML infrastructure. We are 100% Java.) jlapp@webMethods.com http://www.webMethods.com/company/employment xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 13 03:08:04 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:54 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <14300.18403.955077.363493@localhost.localdomain> References: <003101befcde$f10d9110$52f96d8c@NT.JELLIFFE.COM.AU> <37DBF191.3045@hiwaay.net> <14300.18403.955077.363493@localhost.localdomain> Message-ID: <14300.20136.733679.632742@localhost.localdomain> David Megginson writes: > [offline] Or not, as the case may be. At least I didn't make fun of anyone. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Sep 13 03:10:26 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:54 2004 Subject: W3C's 'Moral Majesty' References: <003101befcde$f10d9110$52f96d8c@NT.JELLIFFE.COM.AU> <37DBF191.3045@hiwaay.net> <14300.18403.955077.363493@localhost.localdomain> Message-ID: <37DC4F66.BB4FA6B6@pacbell.net> David Megginson wrote: > > The problem in the W3C is that even a 100% majority cannot override a > directorial veto; the benefit is that it's relatively easy for the > members to vote with their feet. I'm not sure that it's fair to say folk can vote with their feet; where will their feet take them if they need to work with the web? I do agree the capability of such directatorial vetos is an issue; the role of a tie-breaker isn't what we see today. - 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 jlapp at webmethods.com Mon Sep 13 03:29:06 1999 From: jlapp at webmethods.com (Joe Lapp) Date: Mon Jun 7 17:14:54 2004 Subject: namespace of attributes? In-Reply-To: <199909130109.SAA13531@snipe.prod.itd.earthlink.net> References: <837149950.937140020@MDAXKE> Message-ID: <199909130132.SAA22114@snipe.prod.itd.earthlink.net> At 09:12 PM 9/12/1999 -0400, Joe Lapp wrote: >[...] However, I'm >believe that the namespaces of the elements and attributes in the following >DTD subset is unambiguous and uncontroversial: > > > > > > > I should point out why I think this works. Namespaces are only parsed and recognized in the instance, not in the DTD. Here the DTD says that the element having exactly name "a:e1" contains an element having exactly name "a:e3". The element declaration for "a:e3" associates the 'a' with a namespace URN, but this association is neither visible nor realized until parsing an instance that conforms to the DTD. (I'm trying to head off the argument asserting that you don't know what 'a' refers to in either contentspec. I'm saying, "You're right, you don't, but in the end this doesn't change anything." You can get a parser to do this without requiring the instance prefixes to match the prefixes in the DTD.) -- Joe Lapp (Looking for some good people to help design Senior Engineer and build the Internet's business-to-business webMethods, Inc. XML infrastructure. We are 100% Java.) jlapp@webMethods.com http://www.webMethods.com/company/employment xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Sep 13 03:43:19 1999 From: mda at discerning.com (Mark D. Anderson) Date: Mon Jun 7 17:14:54 2004 Subject: namespace of attributes? References: <199909130109.SAA13531@snipe.prod.itd.earthlink.net> Message-ID: <002d01befd89$39931540$0200a8c0@mdaxke> > >And what is a namespace-aware validator (is there such a thing?) supposed > >to do here? If "good" was declared as > > > >then which have i defaulted, a global "b", or a "n1:b"? > >and is the "a" attribute in violation of the dtd while n1:a is not? > >is it in violation because it was not declared or has the wrong value? > > I had trouble making sense of your ATTLIST declaration yeah, i had a mechanical problem with my editor..... > but I don't believe > it is possible to assign namespaces to anything but element or attribute > instances unless you use ATTLIST to define a default xmlns value for every > element. Consider a DTD that contains the following declarations: > > > > > > i think i get the element case, or at least get it more. where i'm losing it is in attributes. can i do this in a dtd? if i can't, then how can i declare the two supposedly different "a" attributes shown in the XML Names spec example: " -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 tbray at textuality.com Mon Sep 13 03:53:39 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:54 2004 Subject: namespace of attributes? Message-ID: <3.0.32.19990912185522.00c19100@pop.intergate.bc.ca> At 09:12 PM 9/12/99 -0400, Joe Lapp wrote: >I believe 5.3 and A.2 are both correct and consistent with each other, >although I have to admit that the spec originally gave me trouble too. My >conclusion was that it is *not* possible to put an attribute in the default >namespace. An attribute goes in the per-element namespace unless the >attribute explicity has a prefix that assigns it a namespace. I think Joe is correct. -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 jlapp at webmethods.com Mon Sep 13 04:41:44 1999 From: jlapp at webmethods.com (Joe Lapp) Date: Mon Jun 7 17:14:54 2004 Subject: namespace of attributes? In-Reply-To: <002d01befd89$39931540$0200a8c0@mdaxke> References: <199909130109.SAA13531@snipe.prod.itd.earthlink.net> Message-ID: <199909130244.TAA00709@snipe.prod.itd.earthlink.net> At 06:41 PM 9/12/1999 -0700, Mark D. Anderson wrote: >[...] how can i declare the two supposedly different "a" >attributes shown in the XML Names spec example: > xmlns="http://www.w3.org" > > > >" For now, I think it's best not to mix namespaces in a DTD. The W3C has not decided on the mechanics, and it may never do so since XML schemas are coming to save the day. -- Joe Lapp (Looking for some good people to help design Senior Engineer and build the Internet's business-to-business webMethods, Inc. XML infrastructure. We are 100% Java.) jlapp@webMethods.com http://www.webMethods.com/company/employment xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From kamiya at rp.open.cs.fujitsu.co.jp Mon Sep 13 08:29:19 1999 From: kamiya at rp.open.cs.fujitsu.co.jp (Takuki Kamiya) Date: Mon Jun 7 17:14:54 2004 Subject: non-ascii namespace name question Message-ID: <013701befdb1$76540890$866e230a@sysrap.cs.fujitsu.co.jp> I have encountered a usage of namespace'd XML where namespace name (i.e. URI) contains non-ascii characters, and is wondering how namespace-aware XML software should handle the URIs. As an example, think of the instance shown below. Both of the URIs conceptually denotes "http://www.fujitsu.co.jp" except that the part "fujitsu" is represented by using numeric character references in the first case and is represented as being encoded as mentioned in XML 1.0 spec. (I mean "4.2.2 External Entities") My question is, is a namespace-aware XML processor supposed to identify the two URLs shown above as identical ones so that the XML instance above is in error since n1:a and n2:a really means the same? If the answer to the question is "yes", then I believe XML processors should return encoded representation such as "http://www.%E5%AF%8C%E5%A3%AB%E9%80%9A.co.jp" to using applications as namespace name. Is my understanding correct? Can somebody make it clear as to how URIs are intended to be processed in the case shown above? Thanks. = Takuki Kamiya Phone: (045)476-4586 Fax: (045)476-4749 = = FUJITSU LIMITED (COINS:7128-4217 NIFTY:HHA01731) = xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From zzyzlane at gte.net Mon Sep 13 08:44:30 1999 From: zzyzlane at gte.net (Christopher Lane) Date: Mon Jun 7 17:14:55 2004 Subject: Random thought Message-ID: <37DC9ECE.AECE880D@gte.net> Lisa Rein: | You know, I would think that the conversations that have been taking place on this list over the last week or two are making a pretty good case ... Such hypothetical debates may be amusing, in small doses, on public mailing lists when nothing is at stake ... ... {never mind} ... | I was wondering if I might get permission to take the last four weeks' XML-DEV digests and condense into a book, titled: "Techies Rampage: When Experts Flagrantly Agree Publically in Uncontrollable Debate: The Inside Story of XML-DEV" (I knew there was a good reason for those archives.) Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From co at daisybytes.su.uunet.de Mon Sep 13 08:43:21 1999 From: co at daisybytes.su.uunet.de (Carsten Oberscheid) Date: Mon Jun 7 17:14:55 2004 Subject: Ps --> xml (or html) In-Reply-To: <3.0.1.32.19990909232740.01b20ec0@mail.accessone.com> Message-ID: <3.0.5.32.19990913084300.009595e0@kelly> At 23:27 09.09.99 -0700, David LeBlanc wrote: >Hi; > >Anyone know of a PS to xml (or html) converter? > >TIA > Have a look at http://www.cs.waikato.ac.nz/~ihw/papers/98NM-Reed-IHW-Extract-Text.pdf The tool presented in this paper (freely available) is based on ghostscript and it features HTML export. Best regards .co. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 13 09:55:08 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:55 2004 Subject: namespace of attributes? Message-ID: <01BEFDCE.AD838300@grappa.ito.tu-darmstadt.de> Joe Lapp wrote: > > > > > > > To which namespace does e3 belong? You've actually got two e3's here. An e3 nested directly beneath e1 is in namespace1 and an e3 nested directly beneath e2 is in namespace2, as can be seen in the following instances (default attribute values shown for clarity): Mark D. Anderson wrote: > can i do this in a dtd? > a (1|2) 1 > "urn:namespace2:a" (3|4) 3> > > if i can't, then how can i declare the two supposedly different "a" > attributes shown in the XML Names spec example: > xmlns="http://www.w3.org" > > > > " I'm afraid your ATTLIST syntax still doesn't make sense -- it's not legal syntax. In answer to your second question, here's the ATTLIST for the element type good (assuming that all attributes are #IMPLIED CDATA attributes): Note that this is subject to all the usual problems of using prefixes in DTDs -- in this case, that the prefix n1 will point to the URI "http://www.w3.org" at the time occurs. As Joe says, it's probably best not to mix namespaces and 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 Mon Sep 13 11:10:53 1999 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:14:55 2004 Subject: XED builds for FreeBSD, Linux now available, bug fixes Message-ID: I'm pleased to announce a bug-fix release of XED, which not only fixes a few bugs, but includes builds for FreeBSD and Linux, as well as WIN32 and Solaris 2.5. See http://www.ltg.ed.ac.uk/~ht/xed.html for a detailed description of XED and download information. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 13 12:56:54 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:55 2004 Subject: confidentiality in W3C WGs References: <01BEFC46.88E67EF0@grappa.ito.tu-darmstadt.de> <37DA9E7F.BE9551C4@finetuning.com> Message-ID: <02fc01befdd5$b003c110$4602a8c0@capella.co.il> Lisa Rein wrote: > It has been my experience that both: > > 1) They put it in the spec if they think of it. > > 2) Someone in the group will tell you if you ask them... > > 3)I guess my biggest problem with all these complaints about the process [and lack of rationale] > is that I, personally, have NEVER had a problem finding out the > technical nature of anything occurring in a W3C spec. Period... > > ... Now, sometimes I don't agree with the rationale, but I don't argue about > it. If I wanted to argue about it THAT's when you go to the public > discussion list and take it from there (and not THIS public discussion > list, please! This isn't the "my beefs with every W3C spec" list, is > it? Sometimes I wonder!) It seems as though you seriously suggest that the lack of documentation of the technical process of creating the spec (specifically, the issues, the alternatives, and the rationale for the adopted solutions) is "OK" since one can simple E-mail some WG member and ask him to explain it for you. After all, it works so well for you! Please say this is a misreading of your post? At any rate, I don't have the E-mail addresses of the XHTML WG members. I can't officially get these addresses AFAIK. Even if I could, it would not be practical for them to answer my questions - because they'd be swamped with the questions of every other interested reader of the draft. Even if they did somehow manage convey the rationale to all people writing to them, and I wouldn't agree with the rationale for some specific decision, I could not go to "another" discussion list - because there typically isn't one, or if there is it is as full of complaints about the W3C process as this one is. And yes, this mailing list _is_ about "my beefs with every (XML related) W3C spec", between other XML related things, unless someone creates a more appropriate list for the purpose. If you are aware of one, I'd appreciate the address. The more this thread continues, the more I'm getting convinced there's something wrong with the W3C. Obviously there is a reason why proper process documentation is not being provided. The problem is that the simplest reason is "to hide any shady politics between member companies". Another reason is "because it would harm the quality of the resulting recommendation" - obviously absurd, or maybe "it would slow things down too much" which people in this mailing list are simply not buying, because being able to understand a recommendation is more important then having it a few months early. Of course the W3C does not give a reason for why no reasons are given for why ... and so on. Maybe they are afraid that giving reasons is habit forming :-) 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 simonstl at simonstl.com Mon Sep 13 14:42:46 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:55 2004 Subject: Random thought In-Reply-To: <37DC9ECE.AECE880D@gte.net> Message-ID: <199909131245.IAA04965@hesketh.net> At 11:50 PM 9/12/99 -0700, Christopher Lane wrote: >I was wondering if I might get permission to take the last four weeks' >XML-DEV digests and condense into a book, titled: >"Techies Rampage: When Experts Flagrantly Agree Publically in >Uncontrollable Debate: The Inside Story of XML-DEV" Actually, it wouldn't be so crazy an idea, especially if an outsider (with enough XML understanding to follow the discussion) did it. A lot of people are confused when they find that the XML community, which looks pretty unified from the outside, has this much controversy in it. An intro to the various issues would help those folks a lot, though it might also make those of us participating chafe, myself included. Probably too much work, though. After all, wasn't XML (once upon a time) supposed to be _simple_? Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Mon Sep 13 15:15:35 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:55 2004 Subject: Random thought In-Reply-To: <199909131245.IAA04965@hesketh.net> References: <37DC9ECE.AECE880D@gte.net> Message-ID: <4.1.19990913091532.024c1ee0@mail.webgeek.com> At 08:49 AM 9/13/99 -0400, Simon St.Laurent wrote: >At 11:50 PM 9/12/99 -0700, Christopher Lane wrote: >>I was wondering if I might get permission to take the last four weeks' >>XML-DEV digests and condense into a book, titled: >>"Techies Rampage: When Experts Flagrantly Agree Publically in >>Uncontrollable Debate: The Inside Story of XML-DEV" > >Actually, it wouldn't be so crazy an idea, especially if an outsider (with >enough XML understanding to follow the discussion) did it. ObCopyrightIssues --- however, even though it's a "public list" with "public archives" that doesn't mean anyone's free to go and republish pieces as they see fit, without gaining permission of participants. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Sep 13 15:34:56 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:55 2004 Subject: Random thought In-Reply-To: <4.1.19990913091532.024c1ee0@mail.webgeek.com> References: <199909131245.IAA04965@hesketh.net> <37DC9ECE.AECE880D@gte.net> Message-ID: <199909131337.JAA07128@hesketh.net> At 09:16 AM 9/13/99 -0400, Ann Navarro wrote: >At 08:49 AM 9/13/99 -0400, Simon St.Laurent wrote: >>At 11:50 PM 9/12/99 -0700, Christopher Lane wrote: >>>I was wondering if I might get permission to take the last four weeks' >>>XML-DEV digests and condense into a book, titled: >>>"Techies Rampage: When Experts Flagrantly Agree Publically in >>>Uncontrollable Debate: The Inside Story of XML-DEV" >> >>Actually, it wouldn't be so crazy an idea, especially if an outsider (with >>enough XML understanding to follow the discussion) did it. > >ObCopyrightIssues --- however, even though it's a "public list" with >"public archives" that doesn't mean anyone's free to go and republish >pieces as they see fit, without gaining permission of participants. Christopher mentioned explicitly in his message - which I think was to some extent supposed to be humorous - 'asking permission'. It might be good for all of us to remember, however, that the archives are built automatically, and anything we say can and will be held us against by readers of those archives. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 boblyons at unidex.com Mon Sep 13 15:44:29 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:14:55 2004 Subject: Announcement: XML Convert 1.1 Message-ID: <01BEFDCC.DC2AA2D0@cc398234-a.etntwn1.nj.home.com> A new version of XML Convert is available for free at: http://www.unidex.com/download.htm The new features (e.g., Windows executable, faster & more powerful parser, inclusion of a DTD in the XML output, etc.) and bug fixes are described at: http://www.unidex.com/whatsnew.htm XML Convert 1.1 is a Java application that uses XFlat schemas to convert flat files into XML. XFlat is an XML language for defining flat file schemas. XML Convert uses an XFlat schema to parse and validate the flat file, and to produce the XML output. XML Convert 1.1 supports a wide variety of flat file formats, including CSV, semi-structured data (e.g., human readable reports), fixed length records and fields, multiple record types, groups of records, nested groups, etc. For more information about XML Convert 1.1 and XFlat, please see http://www.unidex.com/xflat.htm. Please send any comments or questions to mailto:boblyons@unidex.com. Best regards, Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Mon Sep 13 15:44:20 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:55 2004 Subject: Random thought In-Reply-To: <199909131337.JAA07128@hesketh.net> References: <4.1.19990913091532.024c1ee0@mail.webgeek.com> <199909131245.IAA04965@hesketh.net> <37DC9ECE.AECE880D@gte.net> Message-ID: <4.1.19990913094301.02404200@mail.webgeek.com> At 09:41 AM 9/13/99 -0400, Simon St.Laurent wrote: >Christopher mentioned explicitly in his message - which I think was to some >extent supposed to be humorous - 'asking permission'. Assuming a serious request for the moment -- permission must come from each participant, not from a single source (list owner), or a portion of the participants. As Simon pointed out, archives can be held against you, but they can't be republished without explicit permission ;) Ann (who's sent out far too many permissions letters over the last two weeks on this latest book) --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Sep 13 15:52:10 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:55 2004 Subject: non-ascii namespace name question In-Reply-To: <013701befdb1$76540890$866e230a@sysrap.cs.fujitsu.co.jp> from "Takuki Kamiya" at Sep 13, 99 03:30:23 pm Message-ID: <199909131430.KAA27178@locke.ccil.org> Takuki Kamiya scripsit: > > I have encountered a usage of namespace'd XML where namespace name (i.e. URI) > contains non-ascii characters, and is wondering how namespace-aware XML software > should handle the URIs. > > As an example, think of the instance shown below. > > xmlns:ns2="http://www.%E5%AF%8C%E5%A3%AB%E9%80%9A.co.jp" > > > > > Both of the URIs conceptually denotes "http://www.fujitsu.co.jp" except that > the part "fujitsu" is represented by using numeric character references in the > first case and is represented as being encoded as mentioned in XML 1.0 spec. > (I mean "4.2.2 External Entities") Technically, the first URI is not conforming, because the surface form of an URI can only contain plain ASCII. However, applications should treat such an URI as identical to the URLencoded UTF-8 in the second URI. > My question is, is a namespace-aware XML processor supposed to identify the > two URLs shown above as identical ones so that the XML instance above is in > error since n1:a and n2:a really means the same? Yes. > If the answer to the question is "yes", then I believe XML processors should > return encoded representation such as "http://www.%E5%AF%8C%E5%A3%AB%E9%80%9A.co.jp" > to using applications as namespace name. Is my understanding correct? It's a reasonable thing to do as a matter of error recovery. An alternative action is to reject the URI as ill-formed. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From marko.zerdin at ixtlan-team.si Mon Sep 13 16:25:23 1999 From: marko.zerdin at ixtlan-team.si (Marko Zerdin) Date: Mon Jun 7 17:14:55 2004 Subject: MSXML for Java Questions Message-ID: Erik, thank you for your answer. I've been out of town for a few days, so I wasn't able to respond earlier. So, what you're saying is that you don't advise me to use IE5 XML parser. Well, I've made quite a progress in the meantime. I've stopped using old XML parser for java and started using COM wrapper for MSXML, that is built in IE5. The only problem I had by now was my inability to specify encoding of an XML document (which could be quite a problem, because I live in Slovenia and we don't use ASCII or ISO Latin1). I've decided to postpone a problem to some better time. What are the bugs you were talking about (besides encoding, which generates error for no reason known to me)? I've kept XML quite simple and it's worked quite well by now. What solution would you recommend? The advantage of using IE5 built-in is huge. The system we're developing is going to a large distributed system that will work in IE5 (client's specification). The application will run in applets on client machines, so minimizing the transfer is on the top of priority list. Do you know of any XML parser for java, that is really small and works well? If so, I'd be happy to know about it, too. Thanks again, Marko. -----Original Message----- From: Erik James Freed [mailto:ejfreed@infocanvas.com] Sent: Thursday, September 09, 1999 11:29 PM To: Steven Livingstone; David Brownell Cc: xml-dev@ic.ac.uk Subject: RE: MSXML for Java Questions When you are attempting to create a product that has broad reach, the politics of standards become risks, roadblocks, slowdowns, and sometimes showstoppers for hard working innovative and vulnerable small companies like I represent. Hence, IMHO pushing hard on vendors to not play politics with standards and to be consistent in their support is fair. -----Original Message----- From: Steven Livingstone [mailto:ceo@citix.com] Sent: Thursday, September 09, 1999 1:21 PM To: David Brownell; Erik James Freed Cc: xml-dev@ic.ac.uk Subject: Re: MSXML for Java Questions I have recently found the best easiest way (i cost nothing) way to introduce the company I consult for to the capabilities of XML, is through a simple, but effective, part of their application using IE5. Reports are a successful area to show ROI using XML. I use as many capabilities of IE5 as no-one else is thereabouts with browser technology. I can never really understand why people who are trying to get technology to the masses are critisized. I'm sure there are many other XML type apps which have non-standard parts - at least from what I have heard on the list. MS maybe go a bit nuts pushing technology sometimes, but then I remember writing for the first Mosaic browser. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From clovett at microsoft.com Mon Sep 13 17:08:01 1999 From: clovett at microsoft.com (Chris Lovett) Date: Mon Jun 7 17:14:56 2004 Subject: MSXML for Java Questions Message-ID: <2F2DC5CE035DD1118C8E00805FFE354C155E59F6@RED-MSG-56> The encoding attribute should work great in the IE5 version of MSXML. Please send me the specific case you had trouble with. Thanks. -----Original Message----- From: Marko Zerdin [mailto:marko.zerdin@ixtlan-team.si] Sent: Monday, September 13, 1999 7:28 AM To: 'Erik James Freed' Cc: xml-dev@ic.ac.uk Subject: RE: MSXML for Java Questions Erik, thank you for your answer. I've been out of town for a few days, so I wasn't able to respond earlier. So, what you're saying is that you don't advise me to use IE5 XML parser. Well, I've made quite a progress in the meantime. I've stopped using old XML parser for java and started using COM wrapper for MSXML, that is built in IE5. The only problem I had by now was my inability to specify encoding of an XML document (which could be quite a problem, because I live in Slovenia and we don't use ASCII or ISO Latin1). I've decided to postpone a problem to some better time. What are the bugs you were talking about (besides encoding, which generates error for no reason known to me)? I've kept XML quite simple and it's worked quite well by now. What solution would you recommend? The advantage of using IE5 built-in is huge. The system we're developing is going to a large distributed system that will work in IE5 (client's specification). The application will run in applets on client machines, so minimizing the transfer is on the top of priority list. Do you know of any XML parser for java, that is really small and works well? If so, I'd be happy to know about it, too. Thanks again, Marko. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From marko.zerdin at ixtlan-team.si Mon Sep 13 17:13:23 1999 From: marko.zerdin at ixtlan-team.si (Marko Zerdin) Date: Mon Jun 7 17:14:56 2004 Subject: MSXML for Java Questions Message-ID: OK. Here is XML that I sent in my first mail at the beginning of the thread: value value value value value value value value value value When I pass this as an argument into the method DOMDocument.loadXML(String), I get following error: line 1, column 44: Switch from current encoding to specified encoding not supported. That's it. This is actually the only problem I had with this parser. I didn't really work with some very complicated XML, and I didn't even touch XSL yet, so I don't know what's waiting for me in the future. If anybody knows for other "features" of IE5 parser, I would appreciate any information. Wish you all the best, Marko. -----Original Message----- From: Chris Lovett [mailto:clovett@microsoft.com] Sent: Monday, September 13, 1999 4:57 PM To: 'Marko Zerdin'; 'Erik James Freed' Cc: xml-dev@ic.ac.uk Subject: RE: MSXML for Java Questions The encoding attribute should work great in the IE5 version of MSXML. Please send me the specific case you had trouble with. Thanks. -----Original Message----- From: Marko Zerdin [mailto:marko.zerdin@ixtlan-team.si] Sent: Monday, September 13, 1999 7:28 AM To: 'Erik James Freed' Cc: xml-dev@ic.ac.uk Subject: RE: MSXML for Java Questions Erik, thank you for your answer. I've been out of town for a few days, so I wasn't able to respond earlier. So, what you're saying is that you don't advise me to use IE5 XML parser. Well, I've made quite a progress in the meantime. I've stopped using old XML parser for java and started using COM wrapper for MSXML, that is built in IE5. The only problem I had by now was my inability to specify encoding of an XML document (which could be quite a problem, because I live in Slovenia and we don't use ASCII or ISO Latin1). I've decided to postpone a problem to some better time. What are the bugs you were talking about (besides encoding, which generates error for no reason known to me)? I've kept XML quite simple and it's worked quite well by now. What solution would you recommend? The advantage of using IE5 built-in is huge. The system we're developing is going to a large distributed system that will work in IE5 (client's specification). The application will run in applets on client machines, so minimizing the transfer is on the top of priority list. Do you know of any XML parser for java, that is really small and works well? If so, I'd be happy to know about it, too. Thanks again, Marko. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From reschke at medicaldataservice.de Mon Sep 13 17:24:56 1999 From: reschke at medicaldataservice.de (Julian Reschke) Date: Mon Jun 7 17:14:56 2004 Subject: MSXML for Java Questions In-Reply-To: Message-ID: loadXML only accepts Unicode. Either load the document using "load" from a file or a URL, or construct it in-memory in Unicode. -- Julian F. Reschke (mailto:reschke@medicaldataservice.de) MedicalData Service GmbH M?nster, Germany > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On > Behalf Of Marko Zerdin > Sent: Monday, September 13, 1999 5:17 PM > To: 'Chris Lovett' > Cc: 'xml-dev@ic.ac.uk' > Subject: RE: MSXML for Java Questions > > > OK. Here is XML that I sent in my first mail at the beginning of > the thread: > > > > > > value > value > value > value > value > > > > > > > > value > value > value > value > value > > > > > > > > When I pass this as an argument into the method > DOMDocument.loadXML(String), > I get following error: > line 1, column 44: Switch from current encoding to specified encoding not > supported. > > That's it. This is actually the only problem I had with this parser. I > didn't really work with some very complicated XML, and I didn't even touch > XSL yet, so I don't know what's waiting for me in the future. If anybody > knows for other "features" of IE5 parser, I would appreciate any > information. > > Wish you all the best, > > Marko. > > > -----Original Message----- > From: Chris Lovett [mailto:clovett@microsoft.com] > Sent: Monday, September 13, 1999 4:57 PM > To: 'Marko Zerdin'; 'Erik James Freed' > Cc: xml-dev@ic.ac.uk > Subject: RE: MSXML for Java Questions > > > The encoding attribute should work great in the IE5 version of MSXML. > Please send me the specific case you had trouble with. Thanks. > > -----Original Message----- > From: Marko Zerdin [mailto:marko.zerdin@ixtlan-team.si] > Sent: Monday, September 13, 1999 7:28 AM > To: 'Erik James Freed' > Cc: xml-dev@ic.ac.uk > Subject: RE: MSXML for Java Questions > > > Erik, thank you for your answer. I've been out of town for a few > days, so I > wasn't able to respond earlier. > > So, what you're saying is that you don't advise me to use IE5 XML parser. > Well, I've made quite a progress in the meantime. I've stopped > using old XML > parser for java and started using COM wrapper for MSXML, that is built in > IE5. The only problem I had by now was my inability to specify encoding of > an XML document (which could be quite a problem, because I live > in Slovenia > and we don't use ASCII or ISO Latin1). I've decided to postpone a > problem to > some better time. > > What are the bugs you were talking about (besides encoding, which > generates > error for no reason known to me)? I've kept XML quite simple and > it's worked > quite well by now. > > What solution would you recommend? The advantage of using IE5 built-in is > huge. The system we're developing is going to a large distributed system > that will work in IE5 (client's specification). The application > will run in > applets on client machines, so minimizing the transfer is on the top of > priority list. > > Do you know of any XML parser for java, that is really small and > works well? > If so, I'd be happy to know about it, too. > > Thanks again, > > Marko. > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 marko.zerdin at ixtlan-team.si Mon Sep 13 17:31:52 1999 From: marko.zerdin at ixtlan-team.si (Marko Zerdin) Date: Mon Jun 7 17:14:56 2004 Subject: MSXML for Java Questions Message-ID: String in Java is Unicode, isn't it? If I remove enocoding from the XML head then everything works great. I'd really appreciate if you gave me a bit more detailed instructions, because I don't quite understand what you're saying. Thanks, Marko. -----Original Message----- From: Julian Reschke [mailto:reschke@medicaldataservice.de] Sent: Monday, September 13, 1999 5:28 PM To: Marko Zerdin; 'Chris Lovett' Cc: xml-dev@ic.ac.uk Subject: RE: MSXML for Java Questions loadXML only accepts Unicode. Either load the document using "load" from a file or a URL, or construct it in-memory in Unicode. -- Julian F. Reschke (mailto:reschke@medicaldataservice.de) MedicalData Service GmbH M?nster, Germany > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On > Behalf Of Marko Zerdin > Sent: Monday, September 13, 1999 5:17 PM > To: 'Chris Lovett' > Cc: 'xml-dev@ic.ac.uk' > Subject: RE: MSXML for Java Questions > > > OK. Here is XML that I sent in my first mail at the beginning of > the thread: > > > > > > value > value > value > value > value > > > > > > > > value > value > value > value > value > > > > > > > > When I pass this as an argument into the method > DOMDocument.loadXML(String), > I get following error: > line 1, column 44: Switch from current encoding to specified encoding not > supported. > > That's it. This is actually the only problem I had with this parser. I > didn't really work with some very complicated XML, and I didn't even touch > XSL yet, so I don't know what's waiting for me in the future. If anybody > knows for other "features" of IE5 parser, I would appreciate any > information. > > Wish you all the best, > > Marko. > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 13 17:35:51 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:14:56 2004 Subject: Sybase and XML? Message-ID: <01BA10F0CD20D3119B2400805FD40F9F277D66@MDYNYCMSX1> Have any Sybase users read the PDF whitepapers about the new Adaptive Server's XML capabilities? The longer one is called "Using XML with the Sybase Adaptive Server SQL Databases" and the shorter one is "Increasing Developer Productivity with Java and XML in Sybase Adaptive Server Enterprise." (I don't have a URL, because they were passed to me at work, but they're probably at www.sybase.com somewhere.) It looks to me like the majority of their XML "support" is the fact that ASE is tightly integrated with Java and Java goes well with XML. Sybase provide you with a few classes to inherit from, but you still have a ton of Java coding to do. If they only advertised Java integration with no XML support, there wouldn't be much difference. Maybe I'm missing something. Any opinions? thanks, Bob DuCharme www.snee.com/bob see www.snee.com/bob/xmlann for "XML: The Annotated Specification" from Prentice Hall. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From reschke at medicaldataservice.de Mon Sep 13 17:41:29 1999 From: reschke at medicaldataservice.de (Julian Reschke) Date: Mon Jun 7 17:14:56 2004 Subject: MSXML for Java Questions In-Reply-To: Message-ID: I don't know how Java behaves, but as a COM object MSXML expects a UNICODE string (when you use loadXML to pass the XML document as string). Unicode (UTF-16) is different from what you are specifiying (ISO-8859-2), and thus MSXML complains. Hope this helps... -- Julian F. Reschke (mailto:reschke@medicaldataservice.de) MedicalData Service GmbH M?nster, Germany > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On > Behalf Of Marko Zerdin > Sent: Monday, September 13, 1999 5:35 PM > To: 'reschke@medicaldataservice.de'; Marko Zerdin; 'Chris Lovett' > Cc: xml-dev@ic.ac.uk > Subject: RE: MSXML for Java Questions > > > String in Java is Unicode, isn't it? > > If I remove enocoding from the XML head then everything works great. I'd > really appreciate if you gave me a bit more detailed > instructions, because I > don't quite understand what you're saying. > > Thanks, > > Marko. > > -----Original Message----- > From: Julian Reschke [mailto:reschke@medicaldataservice.de] > Sent: Monday, September 13, 1999 5:28 PM > To: Marko Zerdin; 'Chris Lovett' > Cc: xml-dev@ic.ac.uk > Subject: RE: MSXML for Java Questions > > > loadXML only accepts Unicode. Either load the document using "load" from a > file or a URL, or construct it in-memory in Unicode. > > -- > Julian F. Reschke (mailto:reschke@medicaldataservice.de) > MedicalData Service GmbH M?nster, Germany > > > -----Original Message----- > > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On > > Behalf Of Marko Zerdin > > Sent: Monday, September 13, 1999 5:17 PM > > To: 'Chris Lovett' > > Cc: 'xml-dev@ic.ac.uk' > > Subject: RE: MSXML for Java Questions > > > > > > OK. Here is XML that I sent in my first mail at the beginning of > > the thread: > > > > > > > > > > > > value > > value > > value > > value > > value > > > > > > > > > > > > > > > > value > > value > > value > > value > > value > > > > > > > > > > > > > > > > When I pass this as an argument into the method > > DOMDocument.loadXML(String), > > I get following error: > > line 1, column 44: Switch from current encoding to specified > encoding not > > supported. > > > > That's it. This is actually the only problem I had with this parser. I > > didn't really work with some very complicated XML, and I didn't > even touch > > XSL yet, so I don't know what's waiting for me in the future. If anybody > > knows for other "features" of IE5 parser, I would appreciate any > > information. > > > > Wish you all the best, > > > > Marko. > > > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 ejfreed at infocanvas.com Mon Sep 13 17:43:47 1999 From: ejfreed at infocanvas.com (Erik James Freed) Date: Mon Jun 7 17:14:56 2004 Subject: MSXML for Java Questions In-Reply-To: Message-ID: Hi Marko, Actually I tried very hard not to 'advise' you, but did suggest that you be cautious when using the datachannel parser which is the pure java version of IE5's XML and XSL capabilities. This match between IE5 and DC is it's best feature for those who want identical server and browser processing. (I have not tested how identical it really is) I do not know much about the reliability of the IE5 XML/XSL. The reliability of the datachannel parser is very low, and is not apparently going to improve anytime soon. There are serious bugs in the product, as admitted by datachannel after having simple code fragments sent to them. It also fails the majority of tests in the OASIS/NIST conformance tests. They are not exactly responsive to these problems. The most serious bug, where they were inserting NULLs and removing white space where entity references were used, made it impossible for us to use, and we had to port off of it at the last minute under great pressure. There only offer of help was to *maybe* do something once I gave them $5,000. This seemed more like blackmail than real interest in their users. As I said earlier, they are within their rights to charge, but the way that they are doing it is not confidence inspiring. Perhaps you can understand why I am not so happy with DC :-) Right now I am up and running on the IBM XML, Lotus XSLT/XPath environment. So far so good. It has full source, good licensing terms, responsive authors and support infrastructure, so I feel like it is going to be good value when I have to start paying for it. It does fail alot of the conformance tests, but they seem to be related to a small number of faults creating a global failures. And with source, you can always fix them yourself. Oracle's XML/XSLT product I have heard is good, but the licensing terms make it impossible to use for us. Sun's XML parser is excellent, but has no XSL/XSLT support. There are others, noble efforts with less resources and support. I have not tried them because for one reason or another, I found them not a match for our requirements. YMMV -more info can be found starting at the XML/XSL links found on http://www.w3.org . good luck, erik -----Original Message----- From: Marko Zerdin [mailto:marko.zerdin@ixtlan-team.si] Sent: Monday, September 13, 1999 7:28 AM To: 'Erik James Freed' Cc: xml-dev@ic.ac.uk Subject: RE: MSXML for Java Questions Erik, thank you for your answer. I've been out of town for a few days, so I wasn't able to respond earlier. So, what you're saying is that you don't advise me to use IE5 XML parser. Well, I've made quite a progress in the meantime. I've stopped using old XML parser for java and started using COM wrapper for MSXML, that is built in IE5. The only problem I had by now was my inability to specify encoding of an XML document (which could be quite a problem, because I live in Slovenia and we don't use ASCII or ISO Latin1). I've decided to postpone a problem to some better time. What are the bugs you were talking about (besides encoding, which generates error for no reason known to me)? I've kept XML quite simple and it's worked quite well by now. What solution would you recommend? The advantage of using IE5 built-in is huge. The system we're developing is going to a large distributed system that will work in IE5 (client's specification). The application will run in applets on client machines, so minimizing the transfer is on the top of priority list. Do you know of any XML parser for java, that is really small and works well? If so, I'd be happy to know about it, too. Thanks again, Marko. -----Original Message----- From: Erik James Freed [mailto:ejfreed@infocanvas.com] Sent: Thursday, September 09, 1999 11:29 PM To: Steven Livingstone; David Brownell Cc: xml-dev@ic.ac.uk Subject: RE: MSXML for Java Questions When you are attempting to create a product that has broad reach, the politics of standards become risks, roadblocks, slowdowns, and sometimes showstoppers for hard working innovative and vulnerable small companies like I represent. Hence, IMHO pushing hard on vendors to not play politics with standards and to be consistent in their support is fair. -----Original Message----- From: Steven Livingstone [mailto:ceo@citix.com] Sent: Thursday, September 09, 1999 1:21 PM To: David Brownell; Erik James Freed Cc: xml-dev@ic.ac.uk Subject: Re: MSXML for Java Questions I have recently found the best easiest way (i cost nothing) way to introduce the company I consult for to the capabilities of XML, is through a simple, but effective, part of their application using IE5. Reports are a successful area to show ROI using XML. I use as many capabilities of IE5 as no-one else is thereabouts with browser technology. I can never really understand why people who are trying to get technology to the masses are critisized. I'm sure there are many other XML type apps which have non-standard parts - at least from what I have heard on the list. MS maybe go a bit nuts pushing technology sometimes, but then I remember writing for the first Mosaic browser. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe 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 dhunter at Mobility.com Mon Sep 13 17:48:13 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:56 2004 Subject: MSXML for Java Questions Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFEA9@cc20exch2.mobility.com> The problem is that loadXML() in MSXML takes only Unicode strings, whereas load() will take strings in any character set (as long as it's specified). If you take that same XML and load it into MSXML using the load() method, you should find that it will work fine. The trick is that you have to either a) make sure any text you pass to loadXML is Unicode. This is easier if you use a language like Visual Basic, which uses all Unicode strings internally; this means that any text you generate using VB can be passed to load() no problem, without specifying the encoding. OR b) pass any XML which isn't Unicode to load() instead of loadXML(), and specify the encoding explicitly. It can sometimes take a bit of planning to get these issues straight. David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com -----Original Message----- From: Marko Zerdin [mailto:marko.zerdin@ixtlan-team.si] Sent: Monday, September 13, 1999 11:17 AM To: 'Chris Lovett' Cc: 'xml-dev@ic.ac.uk' Subject: RE: MSXML for Java Questions OK. Here is XML that I sent in my first mail at the beginning of the thread: value value value value value value value value value value When I pass this as an argument into the method DOMDocument.loadXML(String), I get following error: line 1, column 44: Switch from current encoding to specified encoding not supported. That's it. This is actually the only problem I had with this parser. I didn't really work with some very complicated XML, and I didn't even touch XSL yet, so I don't know what's waiting for me in the future. If anybody knows for other "features" of IE5 parser, I would appreciate any information. Wish you all the best, Marko. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From niko at cmsplatform.com Mon Sep 13 17:57:39 1999 From: niko at cmsplatform.com (Nik O) Date: Mon Jun 7 17:14:56 2004 Subject: Encoding attribute in IE5/MSXML (Was: RE: MSXML for Java Questions) Message-ID: <00f301befe00$ff602a20$1a5e360a@tetondata.com> It has been my observation that IE5 (i'm using version "5.00.2014.0216IC") will only accept two values for the " declaration: 1) "UTF-8"; or 2) "ISO-8859-1". All other values that i've tried, including "UTF-16", cause the error message: "Switch from current encoding to specified encoding not supported.". This would seem to be yet another indication that IE is *not* a conformant XML 1.0 parser/application, as support of both UTF-8 and UTF-16 is a requirement, not merely an option (see section "2.2 Characters", wherein it is stated: "All XML processors must accept the UTF-8 and UTF-16 encodings of 10646.."). I hope someone from MS who is on this list can tell us when the encoding attribute will be fully-supported in IE5 ("5.00.2525.0666IC", IE6?), as well as when we might expect proper XSL support in IE5? Regards, -Nik O, Teton Data Systems, Jackson, Wyo. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Mon Sep 13 18:13:45 1999 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:14:56 2004 Subject: confidentiality in W3C WGs References: <01BEFC46.88E67EF0@grappa.ito.tu-darmstadt.de> <37DA9E7F.BE9551C4@finetuning.com> <02fc01befdd5$b003c110$4602a8c0@capella.co.il> Message-ID: <37DD279E.DF3DD8C@finetuning.com> I respectfully decline from carrying on what is deteriorating into silly thread of layered misassumptions by people that just like to argue, I guess. I just don't have the time to commit to reading all of it and answering all of it, any longer. Many apologies. thanks, lisa Oren Ben-Kiki wrote: > > Lisa Rein wrote: > > It has been my experience that both: > > > > 1) They put it in the spec if they think of it. > > > > 2) Someone in the group will tell you if you ask them... > > > > 3)I guess my biggest problem with all these complaints about the process > [and lack of rationale] > > is that I, personally, have NEVER had a problem finding out the > > technical nature of anything occurring in a W3C spec. Period... > > > > ... Now, sometimes I don't agree with the rationale, but I don't argue > about > > it. If I wanted to argue about it THAT's when you go to the public > > discussion list and take it from there (and not THIS public discussion > > list, please! This isn't the "my beefs with every W3C spec" list, is > > it? Sometimes I wonder!) > > It seems as though you seriously suggest that the lack of documentation of > the technical process of creating the spec (specifically, the issues, the > alternatives, and the rationale for the adopted solutions) is "OK" since one > can simple E-mail some WG member and ask him to explain it for you. After > all, it works so well for you! > > Please say this is a misreading of your post? > > At any rate, I don't have the E-mail addresses of the XHTML WG members. I > can't officially get these addresses AFAIK. Even if I could, it would not be > practical for them to answer my questions - because they'd be swamped with > the questions of every other interested reader of the draft. Even if they > did somehow manage convey the rationale to all people writing to them, and I > wouldn't agree with the rationale for some specific decision, I could not go > to "another" discussion list - because there typically isn't one, or if > there is it is as full of complaints about the W3C process as this one is. > > And yes, this mailing list _is_ about "my beefs with every (XML related) W3C > spec", between other XML related things, unless someone creates a more > appropriate list for the purpose. If you are aware of one, I'd appreciate > the address. > > The more this thread continues, the more I'm getting convinced there's > something wrong with the W3C. Obviously there is a reason why proper process > documentation is not being provided. The problem is that the simplest reason > is "to hide any shady politics between member companies". Another reason is > "because it would harm the quality of the resulting recommendation" - > obviously absurd, or maybe "it would slow things down too much" which people > in this mailing list are simply not buying, because being able to understand > a recommendation is more important then having it a few months early. Of > course the W3C does not give a reason for why no reasons are given for why > ... and so on. Maybe they are afraid that giving reasons is habit forming > :-) > > 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) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 13 18:43:18 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:56 2004 Subject: Random thought Message-ID: <3.0.32.19990913094320.00c33940@pop.intergate.bc.ca> At 09:16 AM 9/13/99 -0400, Ann Navarro wrote: >ObCopyrightIssues --- however, even though it's a "public list" with >"public archives" that doesn't mean anyone's free to go and republish >pieces as they see fit, without gaining permission of participants. I disagree. I don't think you can stop republication of email that's been sent to a known-to-be-public mailing list. I base this on the fact that it is very nearly impossible for the sender of a private email to stop the recipient from printing it. We are all recipients of all this email. It's an open secret that there's a journalist from C|Net who's been tipped off that there's maybe a story here and has been sniffing around. I pointed him at the archive when he contacted me. Mind you, I think it would take Woodward & Bernstein combined to the power of 10 to dig out the multiple levels of story here and package it up in language that's comprehensible to people who aren't already obsessive about markup. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Sep 13 18:43:22 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:56 2004 Subject: confidentiality in W3C WGs Message-ID: <3.0.32.19990913094010.00c883d0@pop.intergate.bc.ca> At 12:49 PM 9/13/99 +0200, Oren Ben-Kiki wrote: >The more this thread continues, the more I'm getting convinced there's >something wrong with the W3C. Obviously there is a reason why proper process >documentation is not being provided. Well, there is http://www.w3.org/Consortium/Process/ which is a public document. And I can't find the documentation just now, but I know (as co-editor of multiple W3C specs) that we are required to produce a written "disposition of comments" on all public (not w3c, public) comments sent to the address on the published WDs and PRs. And there are lots of them. And sometimes they're good comments that change the draft. Not that I'm saying W3C process is perfect. Nor that this debate isn't 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 david at megginson.com Mon Sep 13 19:04:26 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:56 2004 Subject: Random thought In-Reply-To: <3.0.32.19990913094320.00c33940@pop.intergate.bc.ca> References: <3.0.32.19990913094320.00c33940@pop.intergate.bc.ca> Message-ID: <14301.11702.240691.205012@localhost.localdomain> Tim Bray writes: > It's an open secret that there's a journalist from C|Net who's been > tipped off that there's maybe a story here and has been sniffing around. > I pointed him at the archive when he contacted me. Mind you, I think it > would take Woodward & Bernstein combined to the power of 10 to dig out > the multiple levels of story here and package it up in language that's > comprehensible to people who aren't already obsessive about markup. -Tim The headline will likely be similar to one of the following: a. "W3C faces developer revolt" b. "XML torn by in-fighting" c. "Future of HTML in doubt" Sure, none of these fairly represents our discussions, but that's nothing new. I expect that (a) will win, because the issues around (b) and (c), such as the number and nature of Namespace URIs and the importance of schemas, will leave most readers snoozing. For the record, I support the People's Front of Judea over the Judean People's Front in all of this. 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 ann at webgeek.com Mon Sep 13 19:09:56 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:56 2004 Subject: Random thought In-Reply-To: <3.0.32.19990913094320.00c33940@pop.intergate.bc.ca> Message-ID: <4.1.19990913130103.02379400@mail.webgeek.com> At 09:45 AM 9/13/99 -0700, Tim Bray wrote: >At 09:16 AM 9/13/99 -0400, Ann Navarro wrote: >>ObCopyrightIssues --- however, even though it's a "public list" with >>"public archives" that doesn't mean anyone's free to go and republish >>pieces as they see fit, without gaining permission of participants. > >I disagree. I don't think you can stop republication of email that's >been sent to a known-to-be-public mailing list. I base this on the >fact that it is very nearly impossible for the sender of a private >email to stop the recipient from printing it. We are all recipients >of all this email. We are, just as we're all recipients of C|Net's digital dispatch (if you're subbed), any other email newsletter, the daily paper newspaper, and letters from your Aunt Sophie. Doesn't make them any less protectable under copyright law. -- That's akin to saying that anything posted on the Web (via the archives) loses copyright protection, which of course is not the case. >It's an open secret that there's a journalist from C|Net who's been >tipped off that there's maybe a story here and has been sniffing around. Yes, he was. In fact, I talked to him at length on the phone last week, and latest word, as of this morning, is that the story is probably too arcane for their audience (and not nearly as sensational as the "tip" he received made it out to be). No final decision made yet by the editorial folks. That said, I'll be very clear: my participation in this list, or any list, does not in any way equate to granting unending or irrevocable permission for someone to repackage and republish my words. Passing around emails via forward, or looking things up in the archive is one thing. *Publishing them* is entirely different. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From nzeng at microsoft.com Mon Sep 13 19:16:20 1999 From: nzeng at microsoft.com (Nanshan Zeng) Date: Mon Jun 7 17:14:56 2004 Subject: Encoding attribute in IE5/MSXML (Was: RE: MSXML for Java Ques tions) Message-ID: <3FF8121C9B6DD111812100805F31FC0D0F6E16C4@RED-MSG-59> On your encoding quesion: If you want to switch to an encoding, you have to make sure your xml document is indead in that encoding. If you specify the encoding of an ascii xml document as "UTF-16", you will surely get the error message you have seen... Best wishes, -Nanshan -----Original Message----- From: Nik O [mailto:niko@cmsplatform.com] Sent: Monday, September 13, 1999 9:00 AM To: - XML-Dev Subject: Encoding attribute in IE5/MSXML (Was: RE: MSXML for Java Questions) It has been my observation that IE5 (i'm using version "5.00.2014.0216IC") will only accept two values for the " declaration: 1) "UTF-8"; or 2) "ISO-8859-1". All other values that i've tried, including "UTF-16", cause the error message: "Switch from current encoding to specified encoding not supported.". This would seem to be yet another indication that IE is *not* a conformant XML 1.0 parser/application, as support of both UTF-8 and UTF-16 is a requirement, not merely an option (see section "2.2 Characters", wherein it is stated: "All XML processors must accept the UTF-8 and UTF-16 encodings of 10646.."). I hope someone from MS who is on this list can tell us when the encoding attribute will be fully-supported in IE5 ("5.00.2525.0666IC", IE6?), as well as when we might expect proper XSL support in IE5? Regards, -Nik O, Teton Data Systems, Jackson, Wyo. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 13 19:21:14 1999 From: spreitze at parc.xerox.com (Mike Spreitzer) Date: Mon Jun 7 17:14:56 2004 Subject: More chaos coming down the pike In-Reply-To: <000901beec7a$26d28a50$27d1000d@deimos.parc.xerox.com> Message-ID: <001a01befe0c$bec6b9f0$1776020d@phobos.parc.xerox.com> Those two trains are proceding down their independent tracks. Sun has approved the "XML Data Binding" JSR; for more info, see the Java Community Process web site at . The OMG has issued the "XML/Value RFP"; for more information, see . Neither explicitly requests coordination with the other. The OMG folks say that doesn't prevent a responder from making a coordinated response. The recent barrage of mail about "the grove paradigm" make me even more worried about coherency. I haven't actually studied it yet, but the mail makes me suspect "the grove paradigm" is a meta-model (or meta-meta-model). The OMG has their own modelling architecture, centered around the MOF (Meta-Object Facility) and XMI (Xml Metadata Interchange). If the XmlSchema->JavaType mapping is grounded in groves, and the XmlSchema->OmgIdl mapping is grounded in the MOF, getting coherency after the fact may involve some very deep problems. 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 Mon Sep 13 19:34:38 1999 From: oren at capella.co.il (Oren Ben-Kiki) Date: Mon Jun 7 17:14:56 2004 Subject: confidentiality in W3C WGs References: <3.0.32.19990913094010.00c883d0@pop.intergate.bc.ca> Message-ID: <042601befe0d$31337b40$4602a8c0@capella.co.il> Tim Bray wrote: > At 12:49 PM 9/13/99 +0200, Oren Ben-Kiki wrote: > >The more this thread continues, the more I'm getting convinced there's > >something wrong with the W3C. Obviously there is a reason why proper process > >documentation is not being provided. > > Well, there is http://www.w3.org/Consortium/Process/ > > which is a public document. The process is well known. In fact, it is pretty reasonable, with one significant exception that the archives of minority views and their dispositions are not available to the public. Unless I'm mistaken, these archives form most of what would be called "the rationale" of the final recommendation. The reason for not appending these archives in some form to the final recommendation are not given. For example, this form could be a formal issue/considerations/decision format, with identities of the parties involved removed. > And I can't find the documentation just now, but I know (as co-editor > of multiple W3C specs) that we are required to produce a written > "disposition of comments" on all public (not w3c, public) comments sent > to the address on the published WDs and PRs. And there are lots of them. > And sometimes they're good comments that change the draft. Are these "disposition of comments" documents available to the public? > Not that I'm saying W3C process is perfect. Nor that this debate > isn't useful. -Tim Actually, I don't think this debate is proving to be very useful. The W3C has a "Communication Team" whose purpose (amongst others) is to "Strengthen W3C's image in the Web community through good public relations". In almost two years that I've been reading this and other W3C related public mailing lists, I haven't seen a single official posting from such a group. Given the frequency that the W3C process itself was the subject of the discussion, I can only deduce that "the W3C" simply does not care. A bit more rationale documentation and some appropriate PR would have easily defused these feelings when they were first raised. The questions posted by people in these mailing lists could have been used as a guide to improve the rationale documentation so that the final recommendations would have been, if not different, at least easier to understand. For the record, I fully appreciate the effort invested by some W3C members in trying to make up for this lack in an informal manner. It is unfair that they should be the ones to bear the burden of all the anti W3C attacks. Maybe they should forward some of the traffic to the communication team :-) Share & Enjoy, Oren Ben-Kiki xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Sep 13 19:34:43 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:14:56 2004 Subject: On the record? (was Re: Random thought) In-Reply-To: <4.1.19990913130103.02379400@mail.webgeek.com> References: <3.0.32.19990913094320.00c33940@pop.intergate.bc.ca> <4.1.19990913130103.02379400@mail.webgeek.com> Message-ID: <14301.13167.299439.459637@localhost.localdomain> Ann Navarro writes: > Passing around emails via forward, or looking things up in the archive is > one thing. *Publishing them* is entirely different. What about running a news story in one frame, with your posting (directly from the XML-Dev archive) in the other? It's nasty business, really, and I simply operate on the assumption that anything I post to any public list can and will be reprinted, no matter how stupid. To give two examples, when I booted my Linux notebook a couple of months ago, this fortune appeared on the screen: "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." (By dmeggins@aix1.uottawa.ca) Wow! Yep, that's me back in grad school at Toronto in the late 80's or early 90's, and I had no idea that anyone had even read the message. Less to my credit, I'm immortalized in the famous "Linux is Obsolete" thread from '91 or '92 (gleefully archived at many Linux sites), where I argue that Linux is out-of-date because it uses a monolithic kernel instead of a microkernel. I do not remember giving permission for either of these uses, but these are statements that I made in a public forum, and in the U.S. (at least) I suspect that that fact makes them legally quotable whether I will or no. When you post to a public mailing list, you're *always* on the record. Furthermore, in the U.S., you could probably argue that many of us -- especially those who write books, speak at conferences, or are involved in the W3C -- qualify as "public figures", which (thanks to Larry Flynt) means that people can quote us and even viciously parody us with immunity. 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 dhunter at Mobility.com Mon Sep 13 19:33:48 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:56 2004 Subject: Encoding attribute in IE5/MSXML (Was: RE: MSXML for Java Ques tions) Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFEAB@cc20exch2.mobility.com> As stated in an email on the other thread, MSXML only takes Unicode strings for loadXML(), but will take strings in many encodings for load(). (It supports all of the encodings I've ever tried to throw at it.) David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com -----Original Message----- From: Nik O [mailto:niko@cmsplatform.com] Sent: Monday, September 13, 1999 12:00 PM To: - XML-Dev Subject: Encoding attribute in IE5/MSXML (Was: RE: MSXML for Java Questions) It has been my observation that IE5 (i'm using version "5.00.2014.0216IC") will only accept two values for the " declaration: 1) "UTF-8"; or 2) "ISO-8859-1". All other values that i've tried, including "UTF-16", cause the error message: "Switch from current encoding to specified encoding not supported.". This would seem to be yet another indication that IE is *not* a conformant XML 1.0 parser/application, as support of both UTF-8 and UTF-16 is a requirement, not merely an option (see section "2.2 Characters", wherein it is stated: "All XML processors must accept the UTF-8 and UTF-16 encodings of 10646.."). I hope someone from MS who is on this list can tell us when the encoding attribute will be fully-supported in IE5 ("5.00.2525.0666IC", IE6?), as well as when we might expect proper XSL support in IE5? Regards, -Nik O, Teton Data Systems, Jackson, Wyo. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Mon Sep 13 20:02:06 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:56 2004 Subject: On the record? (was Re: Random thought) In-Reply-To: <14301.13167.299439.459637@localhost.localdomain> References: <4.1.19990913130103.02379400@mail.webgeek.com> <3.0.32.19990913094320.00c33940@pop.intergate.bc.ca> <4.1.19990913130103.02379400@mail.webgeek.com> Message-ID: <4.1.19990913135236.02395240@mail.webgeek.com> At 01:36 PM 9/13/99 -0400, David Megginson wrote: This is another one of those situations where (as someone else said on the list) we must "read for comprehension". What *can be done* (technologically, amorally, etc) , and *what is legal to do without permission* differ. >Furthermore, in the U.S., you could probably argue that many of us -- >especially those who write books, speak at conferences, or are >involved in the W3C -- qualify as "public figures", which (thanks to >Larry Flynt) means that people can quote us and even viciously parody >us with immunity. There is no such thing as "quote us...with immunity". Fair use only goes so far, even with "public figures". There are limits to everything. That said, this really isn't the forum for an extended argument on copyright. If anyone is seriously expecting a titillating expose to come out of this "hot tip" that's going to "bring down XHTML" and those dastardly "rigid and unreasonable" W3C and HTML WG people , I dare say you're going to be deeply disappointed (based on current feedback from the reporter involved). Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken_north at compuserve.com Mon Sep 13 19:58:32 1999 From: ken_north at compuserve.com (Ken North) Date: Mon Jun 7 17:14:57 2004 Subject: Random thought References: <3.0.32.19990913094320.00c33940@pop.intergate.bc.ca> <14301.11702.240691.205012@localhost.localdomain> Message-ID: <00a201befe11$ffa8bc20$0b00a8c0@grissom> << The headline will likely be similar to one of the following: a. "W3C faces developer revolt" b. "XML torn by in-fighting" c. "Future of HTML in doubt" Here's my nomination: "Developers criticize XHTML and W3C standards process" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 13 20:07:45 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:57 2004 Subject: On the record? (was Re: Random thought) Message-ID: <01BEFE24.4FDF13D0@grappa.ito.tu-darmstadt.de> David Megginson wrote: > Furthermore, in the U.S., you could probably argue that many of us -- > especially those who write books, speak at conferences, or are > involved in the W3C -- qualify as "public figures", which (thanks to > Larry Flynt) means that people can quote us and even viciously parody > us with immunity. Oh, boy! I've always wanted to be a public figure! (I gave a presentation at an HL-7 user's group meeting once. Does that qualify me?) And how do I go about getting viciously parodied with immunity? Sounds exciting. -- 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 Mon Sep 13 20:13:21 1999 From: dave at userland.com (Dave Winer) Date: Mon Jun 7 17:14:57 2004 Subject: SOAP 0.9 Message-ID: <047e01befe14$7d928d30$1618ccce@pebbles> http://www.microsoft.com/presspass/press/1999/Sept99/XMLPr.htm "SOAP provides an open, extensible way for applications to communicate using XML-based messages over the Web, regardless of what operating system, object model or language particular applications may use. SOAP facilitates universal communication by defining a simple, extensible message format in standard XML and thereby providing a way to send that XML message over HTTP. Microsoft is soliciting industry feedback on version 0.9 of the SOAP specification." The spec is here: http://www.xmlrpc.com/soap/ My comments here: http://davenet.userland.com/1999/09/12/anEndToTheUberoperatingSystem 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 tbray at textuality.com Mon Sep 13 20:13:22 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:57 2004 Subject: On the record? (was Re: Random thought) Message-ID: <3.0.32.19990913111539.00b9e100@pop.intergate.bc.ca> At 02:02 PM 9/13/99 -0400, Ann Navarro wrote: >If anyone is seriously expecting a titillating expose to come out of this >"hot tip" that's going to "bring down XHTML" and those dastardly "rigid and >unreasonable" W3C and HTML WG people , I dare say you're going to be deeply >disappointed (based on current feedback from the reporter involved). Yeah, I hear the poor guy went and actually tried to read through the xml-dev archive, and has since been dragged away whimpering by burly men in white coats. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Sep 13 20:52:20 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:57 2004 Subject: xml-dev volume (was: On the record?) References: <3.0.32.19990913111539.00b9e100@pop.intergate.bc.ca> Message-ID: <37DD4848.43626179@pacbell.net> Tim Bray wrote: > > At 02:02 PM 9/13/99 -0400, Ann Navarro wrote: > >If anyone is seriously expecting a titillating expose to come out of this > >"hot tip" that's going to "bring down XHTML" and those dastardly "rigid and > >unreasonable" W3C and HTML WG people , I dare say you're going to be deeply > >disappointed (based on current feedback from the reporter involved). > > Yeah, I hear the poor guy went and actually tried to read through > the xml-dev archive, and has since been dragged away whimpering by burly > men in white coats. -T. Strikes me that XML-DEV has enough traffic to need some intelligent way to filter the wheat from the chaff ... that way folk like this reporter (and frankly, me :-) could get more of the benefit with less of the time. Some models for this come quickly to mind: - The Linux kernel developer's list gets lots of traffic; the digests for 1-Sept were 400 KB. There's a weekly web publication "kernel traffic", where one person does a reasonable job of summarizing and highlighting the main threads. Easier to read that than the list! - At slashdot.org there's a discussion system which has a group moderation system which often seems to work rather well in highlighting important comments. Such a system could be used on a "view" of the list archives. So I'm wondering whether doing something along these lines for xml-dev might not be useful to many folk. (Note: this really is a "random idea" ... the white coats may be necessary in part because of the type of content, but volume is surely also an issue!) - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mike.champion at sagus.com Mon Sep 13 21:49:23 1999 From: mike.champion at sagus.com (Michael Champion) Date: Mon Jun 7 17:14:57 2004 Subject: More chaos coming down the pike References: <001a01befe0c$bec6b9f0$1776020d@phobos.parc.xerox.com> Message-ID: <002d01befe20$c66e5280$16d88dce@mccdell> ----- Original Message ----- From: Mike Spreitzer To: Sent: Monday, September 13, 1999 1:23 PM Subject: RE: More chaos coming down the pike > Those two trains are proceding down their independent tracks. Sun has > approved the "XML Data Binding" JSR; for more info, see the Java > Community Process web site at > . The OMG > has issued the "XML/Value RFP"; for more information, see > . > Neither explicitly requests coordination with the other. The OMG folks > say that doesn't prevent a responder from making a coordinated response. > > The recent barrage of mail about "the grove paradigm" make me even more > worried about coherency. I haven't actually studied it yet, but the > mail makes me suspect "the grove paradigm" is a meta-model (or > meta-meta-model). The tracks may be independent, but there is much overlap of the people riding on them and a reasonable amount of communication between the trains. I'm personally torn between wanting to see all this rationalized and centralized and wanting to make sure that the space of possible APIs for XML is thoroughly explored before statis sets in. I guess I'd lean toward the later ... encourage innovation, let the marketplace of ideas sort out the relative value of various ideas, let the various groups cross-fertilize each other, and hope and pray that someone will come along later and rationalize the whole mess. Mike Champion xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 13 21:40:49 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:14:57 2004 Subject: Random thought References: <4.1.19990913130103.02379400@mail.webgeek.com> Message-ID: <37DD5333.ECCC27E8@infinet.com> Ann Navarro wrote: > At 09:45 AM 9/13/99 -0700, Tim Bray wrote: > >I disagree. I don't think you can stop republication of email that's > >been sent to a known-to-be-public mailing list. I base this on the > >fact that it is very nearly impossible for the sender of a private > >email to stop the recipient from printing it. We are all recipients > >of all this email. > > We are, just as we're all recipients of C|Net's digital dispatch (if you're > subbed), any other email newsletter, the daily paper newspaper, and letters > from your Aunt Sophie. Doesn't make them any less protectable under > copyright law. -- That's akin to saying that anything posted on the Web > (via the archives) loses copyright protection, which of course is not the > case. On an XML-Dev list talking about legal issues when few if any people here are qualified to answer them does nobody any good. I am not a lawyer and when I have specific issues that I am not completely aware of, then I call up our lawyer and get them resolved, for a fee of course )-: Maybe we should have a xml-legal list or something like that... > >It's an open secret that there's a journalist from C|Net who's been > >tipped off that there's maybe a story here and has been sniffing around. > > Yes, he was. In fact, I talked to him at length on the phone last week, and > latest word, as of this morning, is that the story is probably too arcane > for their audience (and not nearly as sensational as the "tip" he received > made it out to be). No final decision made yet by the editorial folks. > > That said, I'll be very clear: my participation in this list, or any list, > does not in any way equate to granting unending or irrevocable permission > for someone to repackage and republish my words. > > Passing around emails via forward, or looking things up in the archive is > one thing. *Publishing them* is entirely different. Well ethically I think you have a good point Ann, but in the legal sense from what I know (again I reiterate I have no law degree or experience in intellectual property law) I believe that Tim is correct and furthermore for something to be copyrightable it must be creative, original, and fixated. Someone's personal comments upon reflection on an issue they did not create I don't believe are copyrightable. Music lyrics are copyrightable, but someone's random comments that change from day to day on HTML or XML or whatever I really don't think would pass the test of being creative, original, and fixated. Of course I am only speaking with regard to copyright issues in the United States. In other lands, things may be an entirely different ballgame. 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 donpark at docuverse.com Mon Sep 13 21:49:10 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:57 2004 Subject: Random thought In-Reply-To: <14301.11702.240691.205012@localhost.localdomain> Message-ID: <000901befe21$59f11420$f21dfea9@w21tp> >a. "W3C faces developer revolt" >b. "XML torn by in-fighting" >c. "Future of HTML in doubt" My ideal headline would be "W3C announces Tower of Babel building standard". Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com "I hear the Guns of Navarone blasting away on the Rock of Gibralta." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Mon Sep 13 21:53:24 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:57 2004 Subject: Random thought In-Reply-To: <37DD5333.ECCC27E8@infinet.com> References: <4.1.19990913130103.02379400@mail.webgeek.com> Message-ID: <4.1.19990913155109.022d15e0@mail.webgeek.com> At 03:40 PM 9/13/99 -0400, Tyler Baker wrote: >pass the test of being creative, original, and fixated. Creative does not mean "artistic". Original is without a question true for every post. "Fixated" doesn't mean much. I "publish" this message the moment I hit send (just as I publish personal writings the moment I hit the Save As command). I don't claim authoritative knowledge worthy of an IP attorney, but I don't speak purely out of conjecture either. These are issues that I've dealt with as an author and as a board member of an organization that manages dozens of email lists (that has appropriate corporate counsel). Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Sep 13 21:58:52 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:57 2004 Subject: enumeration and defaults In-Reply-To: <3.0.32.19990910143224.0091b420@pop.intergate.bc.ca> Message-ID: <199909132001.QAA25108@hesketh.net> For the record, this does have an impact on XHTML (potentially significant, at that), but is not about namespaces or W3C process, and I'd like to keep it that way. However, I am using the XML-dev archives for reference, hoping to reduce the byte-volume of the list and see how well it works. I received two separate replies to my question regarding enumeration and defaulting, one from Tim Bray, and one from John Cowan, which he's graciously let me post publicly. They take opposite positions on an issue with XML 1.0 that has an impact on the current XHTML's formulation, at least in the transitional and frameset varieties. My original question: http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0606.html (basically, is it legit to use #IMPLIED on the declaration for an enumerated attribute type and NOT specify a value in the document.) At 05:22 PM 9/10/99 -0400, John Cowan wrote: http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0636.html (basically, yes. XHTML does it.) At 02:32 PM 9/10/99 -0700, Tim Bray wrote: http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0609.html (basically, no, but it would be nice to see in schemas.) The relevant references for XHTML, if anyone needs them, are at: http://www.w3.org/TR/xhtml1/DTD/transitional.dtd http://www.w3.org/TR/xhtml1/DTD/frameset.dtd (search for ATTLIST ul to get to a section where this matters) I think we have a use-case staring us in the face, in a DTD. Does this mean that XHTML is wrong, or that the more generous interpretation (John Cowan's) holds? Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Sep 13 22:08:32 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:57 2004 Subject: Random thought In-Reply-To: <37DD5333.ECCC27E8@infinet.com> from "Tyler Baker" at Sep 13, 99 03:40:35 pm Message-ID: <199909132047.QAA08406@locke.ccil.org> Tyler Baker scripsit: > Well ethically I think you have a good point Ann, but in the legal sense from what I know > (again I reiterate I have no law degree or experience in intellectual property law) I believe > that Tim is correct and furthermore for something to be copyrightable it must be creative, > original, and fixated. Right enough, but your view of what those words mean sets too high a threshold. "Creative" just means you did something more than alphabetize a list you got from someone else, and "original" just means you wrote it. "Fixed" (not "fixated") means there's a physical expression someplace: all the various hard disks that hold these messages (not just the archives) are sufficient --- anything not just in your head is "fixed". So Ann is right. Whether a particular publication counts as "fair use" is another question, the definition of which varies from country to country. ("Fair use" is called "fair dealing" outside the U.S.) The tests involve thigns like commercial intent, what fraction of the text is used, and so on: the law does not define the term exactly. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mnutter at fore.com Mon Sep 13 22:50:44 1999 From: mnutter at fore.com (Mark Nutter) Date: Mon Jun 7 17:14:57 2004 Subject: For official info on US copyright law... In-Reply-To: <37DD5333.ECCC27E8@infinet.com> References: <4.1.19990913130103.02379400@mail.webgeek.com> Message-ID: <4.2.0.58.19990913164226.00c6bca0@pophost1.fore.com> ...see http://www.loc.gov/copyright/circs/ and in particular http://lcweb.loc.gov/copyright/circs/circ01.pdf for a copy of a .pdf file explaining copyright basics. We now return you to your regularly-scheduled XML-related discussion (I hope). -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Mark Nutter, Internet Applications Developer FORE Systems Q: How many surrealists does it take to change a light bulb? A: Because fish do *not* wear bow-ties. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990913/54fc960a/attachment.htm From cthar2 at jcpenney.com Mon Sep 13 22:55:33 1999 From: cthar2 at jcpenney.com (Chris Tharpe) Date: Mon Jun 7 17:14:57 2004 Subject: (no subject) Message-ID: <37DD65ED.9CBA66F6@jcpenney.com> unsubscribe XMLDevlist -------------- next part -------------- A non-text attachment was scrubbed... Name: cthar2.vcf Type: text/x-vcard Size: 275 bytes Desc: Card for Chris Tharpe Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990913/09a40c52/cthar2.vcf From barclay at uwi.com Mon Sep 13 23:08:27 1999 From: barclay at uwi.com (Barclay T. Blair) Date: Mon Jun 7 17:14:57 2004 Subject: Random thought In-Reply-To: <37DD5333.ECCC27E8@infinet.com> Message-ID: Tyler Baker wrote: >On an XML-Dev list talking about legal issues when few if any people here are qualified to >answer them does nobody any good. I am not a lawyer and when I have specific issues that I am >not completely aware of, then I call up our lawyer and get them resolved, for a fee of course >)-: >Maybe we should have a xml-legal list or something like that... Not exactly what you are talking about, but there is an legal-xml list that you can find at: www.legalxml.org Barclay ============================================== Barclay Blair -- Industry Relations Advisor UWI.Com -- The InternetForms Company v: 250-479-8334 x161 f: 250-479-3772 barclay@uwi.com http://www.uwi.com ============================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sdr at camsoft.com Mon Sep 13 23:33:12 1999 From: sdr at camsoft.com (Stewart Rubenstein) Date: Mon Jun 7 17:14:57 2004 Subject: enumeration and defaults In-Reply-To: <199909132001.QAA25108@hesketh.net> Message-ID: <009301befe30$ab512620$a66d70c6@camsoft.com> It's important to distinguish between empty-value and not-present. Empty-value for enumerated types is simply not supported. You have to use a value like "none" or "unspecified" and use an extra layer of filtering if your application requires the empty string for these cases internally. I'd like to be able to say but AFAIK I can't express this in a DTD. I don't think it's what you were asking. However, not-present *is* supported as the default value, that's exactly what #IMPLIED gets you. Not-present is not supported as a non-default value. I don't know whether Tim was talking about empty-value support or not-present as a non-default value. I would find empty-value support helpful in making my documents and processing more natural, but I can work around that problem. I don't see a need for not-present as a non-default value, myself. -Stew CTO, CambridgeSoft Corp > -----Original Message----- > My original question: > http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0606.html > (basically, is it legit to use #IMPLIED on the declaration for an > enumerated attribute type and NOT specify a value in the document.) > > At 05:22 PM 9/10/99 -0400, John Cowan wrote: > http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0636.html > (basically, yes. XHTML does it.) > > At 02:32 PM 9/10/99 -0700, Tim Bray wrote: > http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0609.html > (basically, no, but it would be nice to see in schemas.) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 14 00:06:34 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:57 2004 Subject: enumeration and defaults In-Reply-To: <009301befe30$ab512620$a66d70c6@camsoft.com> References: <199909132001.QAA25108@hesketh.net> Message-ID: <199909132209.SAA31192@hesketh.net> At 05:40 PM 9/13/99 -0400, Stewart Rubenstein wrote: >It's important to distinguish between empty-value and not-present. Okay - that lets me re-read Tim's reply to suggest that the case I was proposing is in fact doable, though under a slightly different interpretation than I originally gave the spec. I don't need empty value, and can do what I need with not-present, so I think we're all right. When I hit a case where I need empty value but present, we may be stuck again and it'll be time for schemas to ride in as cavalry. Sounds good, sounds like XHTML is off the hook (for once). A nice way to end a day. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Sep 14 00:15:36 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:57 2004 Subject: enumeration and defaults Message-ID: <3.0.32.19990913151736.00cee360@pop.intergate.bc.ca> At 04:05 PM 9/13/99 -0400, Simon St.Laurent wrote: >I received two separate replies to my question regarding enumeration and >defaulting, one from Tim Bray, and one from John Cowan, which he's >graciously let me post publicly. They take opposite positions I just read both, and I think John's position and mine are completely coherent. In John's example: > compact (compact) #IMPLIED> >such as is found in the DTD for XHTML 1.0 Transitional, >means that either
    or
      is legal. if you have
        , that means the compact attribute is not specified. It does *not* mean that it's actually there but with a null value. I'm pretty sure John would agree. -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 Sanjeev.Goyal at usa.xerox.com Tue Sep 14 00:18:28 1999 From: Sanjeev.Goyal at usa.xerox.com (Goyal, Sanjeev) Date: Mon Jun 7 17:14:57 2004 Subject: Associating Element Node to Document Node Message-ID: <8B049D471C61D111847C00805FA67B1C03239CFF@usa0129ms1.ess.mc.xerox.com> Hi, I want to associate a ElementNode to a Document before I append the Element to DocumentNode. Basically, I am specializing the ElementNode and writing my own element nodes. I have a specific requirements to do that. Following is the code snippet: public class TestNode extends ElementNode { public TestNode(XmlDocument parentDoc) { super(); setTag("SIFNode"); setOwnerDocument(parentDoc); } } I am not able to use the setOwnerDocument() API. Please help me in this regard. Thanks, Sanjeev xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Sanjeev.Goyal at usa.xerox.com Tue Sep 14 00:23:17 1999 From: Sanjeev.Goyal at usa.xerox.com (Goyal, Sanjeev) Date: Mon Jun 7 17:14:57 2004 Subject: Associating Element Node to Document Node Message-ID: <8B049D471C61D111847C00805FA67B1C03239D00@usa0129ms1.ess.mc.xerox.com> I am using Sun's XML Parser and DOM implementation (Java Project X Core Library TR2) -----Original Message----- From: Goyal, Sanjeev Sent: Monday, September 13, 1999 6:20 PM To: 'xml-dev@ic.ac.uk'; 'xml-feedback@java.sun.com' Subject: Associating Element Node to Document Node Hi, I want to associate a ElementNode to a Document before I append the Element to DocumentNode. Basically, I am specializing the ElementNode and writing my own element nodes. I have a specific requirements to do that. Following is the code snippet: public class TestNode extends ElementNode { public TestNode(XmlDocument parentDoc) { super(); setTag("SIFNode"); setOwnerDocument(parentDoc); } } I am not able to use the setOwnerDocument() API. Please help me in this regard. Thanks, Sanjeev xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 14 01:15:08 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:57 2004 Subject: enumeration and defaults In-Reply-To: <3.0.32.19990913151736.00cee360@pop.intergate.bc.ca> Message-ID: <199909132318.TAA00930@hesketh.net> At 03:18 PM 9/13/99 -0700, Tim Bray wrote: >At 04:05 PM 9/13/99 -0400, Simon St.Laurent wrote: >>I received two separate replies to my question regarding enumeration and >>defaulting, one from Tim Bray, and one from John Cowan, which he's >>graciously let me post publicly. They take opposite positions > >I just read both, and I think John's position and mine are completely >coherent. On a read with the right spin, they are indeed coherent - they just read like they come to opposite conclusions regarding what I was trying to do, which may (of course) be the result of a flaw in my original presentation. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 mrc at allette.com.au Tue Sep 14 01:32:39 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:14:57 2004 Subject: Announcement: XML Asia Pacific Conference References: <37DD8311.8CD5879D@allette.com.au> <37DD8562.79145E92@allette.com.au> <37DD8698.5B23BA72@allette.com.au> <37DD884F.79EA85AE@allette.com.au> Message-ID: <37DD8A2F.DEA88EEF@allette.com.au> Please be advised that the XML/SGML Asia Pacific '99 Web site is now updated with the complete schedule and program for this year's conference. http://www.allette.com.au/xmlasia99 With international representatives from Sun, Oracle, Microsoft and IBM complementing our regional and local speakers, this year's conference will unquestionably be the largest in the event's six year history. Despite our larger venue at the new Mercure Hotel, Sydney, Australia, space is strictly limited so register now to avoid disappointment. -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Sep 14 01:35:41 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:57 2004 Subject: XML news outlets (was Re: Random thought) In-Reply-To: <3.0.32.19990913094320.00c33940@pop.intergate.bc.ca> Message-ID: <199909132338.TAA01494@hesketh.net> At 09:45 AM 9/13/99 -0700, Tim Bray wrote: >It's an open secret that there's a journalist from C|Net who's been >tipped off that there's maybe a story here and has been sniffing around. >I pointed him at the archive when he contacted me. Mind you, I think it >would take Woodward & Bernstein combined to the power of 10 to dig out >the multiple levels of story here and package it up in language that's >comprehensible to people who aren't already obsessive about markup. -Tim Hmmm... you'd think XML.com or another XML-specific outlet could report on it. XML.com did a very good job as a forum for the XSL discontent, though I don't know how they'd feel about the W3C gossip aspect of this story. Perhaps, given another level of processing, C|Net and other outlets could pick up XML stories with better context and less need for straitjackets. There's also a new 'XML Magazine' going up: http://news.excite.com/news/pr/990910/ca-xml-magazine Just a press release, no sign of an actual magazine yet. (www.fawcette.com does include reviews of Palo Alto restaurants in their resources area, however.) They might also be able to provide news for the markup-obsessed, eventually. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 andrewl at microsoft.com Tue Sep 14 02:29:48 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:14:57 2004 Subject: namespace of attributes? Message-ID: <5BF896CAFE8DD111812400805F1991F712E1726F@RED-MSG-08> Right. An unqualified attribute name is resolved against the per-element namespace, not against the "default" namespace, if any. -----Original Message----- From: Tim Bray [mailto:tbray@textuality.com] Sent: Sunday, September 12, 1999 6:56 PM To: Joe Lapp; xml-dev@ic.ac.uk Subject: Re: namespace of attributes? At 09:12 PM 9/12/99 -0400, Joe Lapp wrote: >I believe 5.3 and A.2 are both correct and consistent with each other, >although I have to admit that the spec originally gave me trouble too. My >conclusion was that it is *not* possible to put an attribute in the default >namespace. An attribute goes in the per-element namespace unless the >attribute explicity has a prefix that assigns it a namespace. I think Joe is correct. -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 robincover at hotmail.com Tue Sep 14 02:45:43 1999 From: robincover at hotmail.com (Robin Cover) Date: Mon Jun 7 17:14:58 2004 Subject: XML Announcements Message-ID: <19990914002833.48283.qmail@hotmail.com> There were two fairly significant sets of announcements on XML today. I posted news summaries on my Web site (http://www.oasis-open.org/cover/sgmlnew.html), but the server has apparently been taken the server down, so for those interested, I post the news items on this email channel. When the server is back up, some additional links will be alive: [September 13, 1999] XML Featured in Microsoft Announcements. XML is highlighted in a series of recent announcements from Microsoft Corporation in connection with Windows DNA (Distributed interNet Architecture) 2000 and the BizTalk Framework. The company "announced the availability of a freely downloadable BizTalk JumpStart Kit to aid developers in the immediate creation of BizTalk-compatible software applications. The Microsoft BizTalk JumpStart Kit makes it easier for developers to use XML schemas and the BizTalk Framework in current development projects and existing applications and to realize the benefits of industry-standard eXtensible Markup Language (XML) for electronic-commerce and application integration within and across organizations. In addition, a library for BizTalk-compatible schemas is now live on the BizTalk.Org Web site, with more than 100 freely available schemas submitted by 30 organizations." See "Microsoft Releases BizTalk JumpStart Kit for Developers. BizTalk.Org Library Open for Business Today With More Than 100 Schemas JumpStart Kit, Schema Library Allow Developers to Quickly Create BizTalk-Compatible Solutions Today With XML Schema, Tools, Services and Sample Applications." Press releases from several other companies (Ariba, Bentley, Clarus, Concur Technologies, HR-XML Consortium, Intelisys, KeyFile, Litefoot, Motiva DesignGroup, NetFish, PMSC, Prophet 21) are referenced in the "XML Industry News" section. XML features strongly in a related Microsoft announcement, "Windows DNA 2000 Provides Pervasive XML Support For Next-Generation Web Development Microsoft Deepens Commitment to XML as Industry- Standard Integration Mechanism." - "Microsoft Corp. today expanded its industry-leading commitment to eXtensible Markup Language (XML) with a series of announcements for far-reaching XML support in Windows. Distributed interNet Architecture (Windows DNA) 2000, the next generation of the Microsoft. platform for building distributed Web applications. XML, an industry-standard technology developed by the Worldwide Web Consortium (W3C), enables heterogeneous interoperability of data, components, business processes and applications over the Internet. The Microsoft Windows 2000 operating system, the cornerstone of Windows DNA 2000, is the first operating system with integrated, end-to-end XML support. Key products of the Windows DNA 2000 solution will offer new features and functionality based on XML, including Microsoft SQL Server, the 'Babylon' Integration Server, Microsoft Commerce Server and Microsoft BizTalk Server. The key enabler for Microsoft's vision of integrated, programmable Web services is XML. Through the exchange of XML messages, services can easily describe their capabilities and allow any other service, application or device on the Internet to easily invoke those capabilities. To help realize that vision, Microsoft today is submitting to the Internet Engineering Task Force (IETF) an Internet draft specification for the Simple Object Access Protocol (SOAP), an XML-based mechanism that bridges different object models over the Internet and provides an open mechanism for Web services to communicate with one another. Highlights: (1) SOAP provides an open, extensible way for applications to communicate using XML-based messages over the Web, regardless of what operating system, object model or language particular applications may use. SOAP facilitates universal communication by defining a simple, extensible message format in standard XML and thereby providing a way to send that XML message over HTTP. (2) Microsoft is tightly integrating XML into the SQL. The next version of SQL Server, code- code-named 'Shiloh,' will be fully XML-enabled and will include a superset of the features available in the technology preview for SQL Server 7.0. (3) Microsoft announces XML Transaction Integrator (XML-TI), a new feature of the forthcoming 'Babylon' integration server that enables customers to easily integrate and commerce-enable their existing enterprise applications via XML. XML-TI allows developers to easily invoke transactions on a host with XML without having to change any existing host code or write any new code. XML-TI consists of a runtime proxy and a component builder that generates an XML document interface for executing legacy CICS and IMS transactions." [September 13, 1999] OASIS Announces Expansion of XML.org as an XML Information Clearinghouse. A press release from OASIS (Organization for the Advancement of Structured Information Standards) announced "major enhancements to XML.org, the open, vendor-neutral industry portal for XML. New XML schemas from DataChannel and the HR-XML Consortium have been submitted to XML.org. Other content upgrades include the addition of the XML.org Specifications Catalog (www.xml.org/ xmlorg_catalog.htm), a comprehensive list of XML specifications currently under development including links for more information." This catalog is described as "the precursor to the fully functional XML.org Registry and Repository, coming in early 2000, the XML Catalog provides an overview of organizations producing XML specifications." The Web site now publicizes a document describing "XML.org Recommendations, Working Drafts, and Submissions; it provides detailed information on specifications submitted to XML.org. An XML.org Recommendation is an XML specification that was developed for one or more industries in a vendor-neutral manner and has broad industry acceptance. An XML.org Recommendation is suitable for widespread use within the industry or industries for which it was designed and has been given the OASIS Board of Directors stamp of approval. An XML.org Working Draft represents a work-in-progress by an OASIS working group or an industry consortium. The ultimate goal of the group producing the Working Draft must be to seek XML.org Recommendation status. To be accepted as an XML.org Working Draft, the development organization must demonstrate that the specification was developed in a vendor-neutral manner. An XML.org Submission has been given to XML.org for consideration as an XML.org Recommendation, for input to an OASIS XML.org working group, or as an announcement of the availability of a specification for review or application. A Submission can only be forwarded to XML.org by the organization that developed the specification." The XML.org Web site also now incorporates the XML.org Specification Submission Form to encourage and enable organizations to share their XML specifications with the community at large. The form allows one to submit XML DTDs, XML schemas, XSL stylesheets, and descriptive web pages, together with keyword assignments from the North American Industry Classification System (NAICS) codes and descriptions. "Data Channel's [recent] submission to XML.org is the Portal Markup Language (PML), which is designed to support inter-portal communication by providing an XML- based description of portal-related data and metadata. PML in corporates the basics of vocabularies such as Dublin Core, Directory Services Markup and WebDAV and will continue to closely track applicable standards of relevance to this arena." ______________________________________________________ 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 sunker at telkom.net Tue Sep 14 02:49:57 1999 From: sunker at telkom.net (sunker@telkom.net) Date: Mon Jun 7 17:14:58 2004 Subject: translator ? Message-ID: <61D3A6AB14FED211856500001C055D9633DFDE@FS01> Hi all, Did unicode just translate the coding in any language (such as chinese idiographic and English-latin) ?, could they translation in English into chinese without disctionary translator ?. Can XML do the latin translate to chinese or what ever language with their unicode ?. i think XML could be automatic translate the english into chinese, when i wrote the english first (for first page), couldn't i ?. Example: in English:    Hello, how are you ? in chinese:    ?, ????   http://www.geocities.com/researchtriangle/campus/7211 -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3632 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990914/8e72acaf/winmail.bin From cbullard at hiwaay.net Tue Sep 14 04:30:18 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:58 2004 Subject: On the record? (was Re: Random thought) References: <01BEFE24.4FDF13D0@grappa.ito.tu-darmstadt.de> Message-ID: <37DDB12C.3867@hiwaay.net> Ronald Bourret wrote: > Oh, boy! I've always wanted to be a public figure! (I gave a presentation > at an HL-7 user's group meeting once. Does that qualify me?) And how do I > go about getting viciously parodied with immunity? Sounds exciting. Was it Nirvana that said, "You know you've made it when Weird Al Yankovich parodies you?" I've seen quotes pulled from emails from years ago show up in signatures. Love it. Write for markupBytes and become NetHeros. If the reporter doesn't think a story is emerging, that reporter could be missing the wave. Seems to me a pretty interesting debate is taking place. 1. Is the XHTML modular draft seriously flawed? Committee says no; serious developers say yes. 2. Is the W3C directorship flawed? W3C says no. MCI says yes. 3. Could smart use of the very technology which the W3C claims is trademarked and copyright while actually invented some years earlier be useful to stop the hemmoraging of W3C authority? Experienced experts say yes. W3C can't be bothered to comment. Does all of this erode the credibility of the W3C to create standards for the single most important communication technologies of the millenium? Story at 11. So much opportunity; so few good reporters. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Tue Sep 14 04:27:10 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:14:58 2004 Subject: W3C's 'Moral Majesty' References: <003101befcde$f10d9110$52f96d8c@NT.JELLIFFE.COM.AU> <37DBF191.3045@hiwaay.net> <14300.18403.955077.363493@localhost.localdomain> Message-ID: <37DDAC3E.2B3B@hiwaay.net> David Megginson wrote: > > [offline] > > Len Bullard writes: > > > Rick Jelliffe wrote: > > > > > This seems to be turning into "why T.B-L is bad for the WWW" > > > which is completely against the point I was trying to put forward: > > > personally, I think the idea of someone (or body) at the top whose > > > primary job is to unblock logjams is good (indeed, my countries > > > political constitution is based on this, very successfully). > > > > The idea in ours is that in a deadlock vote, one man or woman, > > can break a tie. Otherwise, the executive branch can propose > > and lobby for legislation and acts as top cop. It cannot > > thwart majority rule. > > I don't know a lot about the U.S. constitution, but as I understood > it, it takes a two-thirds majority to override a presidential veto, > not 50% + 1. > > The problem in the W3C is that even a 100% majority cannot override a > directorial veto; the benefit is that it's relatively easy for the > members to vote with their feet. It was the Senate to which I was referring. It is true that it requires a 2/3 majority to override a presidential veto. It is not relatively easy to vote with their feet any longer. Unless it is shown to be directly contrary to their business interests and enough powerful blocs walk, they are simply eliminated from play. Some, such as MCI can. I think it possible others will if there are workable alternatives. That is why it is imperative for the W3C to address the evolution of the leadership to ensure that such never becomes necessary. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cgfield at email.msn.com Tue Sep 14 05:57:48 1999 From: cgfield at email.msn.com (C. Field) Date: Mon Jun 7 17:14:58 2004 Subject: Wrong list? Message-ID: <00ac01befe64$1eb02e80$532ffcd0@oemcomputer> I was wondering if there is a more basic list about xml. I posted a simple question that has not even gotten a mention. It must not be up to the level of this mailing list. Can anybody let me know about another list that helps out beginners in the xml field? Thanks in advance, C. Field xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Tue Sep 14 07:18:52 1999 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:14:58 2004 Subject: Wrong list? References: <00ac01befe64$1eb02e80$532ffcd0@oemcomputer> Message-ID: <37DDDB77.36B8074E@allette.com.au> Hello C, "C. Field" wrote: > I was wondering if there is a more basic list about xml. I posted a simple > question that has not even gotten a mention. It must not be up to the level > of this mailing list. Can anybody let me know about another list that helps > out beginners in the xml field? There is indeed another list - General discussion of Extensible Markup Language . I hope the lack of response doesn't leave you with the impression that the developers list is snobby or elitist, as neither is true. Many people are on both lists and would gladly assist you in the other forum, but this one is unquestionably focussed differently. Good luck with your problem! -- Regards, Marcus Carr email: mrc@allette.com.au ___________________________________________________________________ Allette Systems (Australia) www: http://www.allette.com.au ___________________________________________________________________ "Everything should be made as simple as possible, but not simpler." - Einstein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From marko.zerdin at ixtlan-team.si Tue Sep 14 09:36:32 1999 From: marko.zerdin at ixtlan-team.si (Marko Zerdin) Date: Mon Jun 7 17:14:58 2004 Subject: MSXML for Java Questions Message-ID: Thank you all. I got the idea now. Since String in Java is already in Unicode (and not in ISO-8859-2), parser doesn't simply ignore the encoding setting (simply put it in DOM tree without any consequences), but complains about it. I wanted to use this setting in order to preserve original and final encoding in the overall structure of XML document, but it seems that I'll have to find some way aroun (most probably use load()). Thank you all again. I wish you all the best, Marko. -----Original Message----- From: Hunter, David [mailto:dhunter@Mobility.com] Sent: Monday, September 13, 1999 5:47 PM To: 'Marko Zerdin'; 'Chris Lovett' Cc: 'xml-dev@ic.ac.uk' Subject: RE: MSXML for Java Questions The problem is that loadXML() in MSXML takes only Unicode strings, whereas load() will take strings in any character set (as long as it's specified). If you take that same XML and load it into MSXML using the load() method, you should find that it will work fine. The trick is that you have to either a) make sure any text you pass to loadXML is Unicode. This is easier if you use a language like Visual Basic, which uses all Unicode strings internally; this means that any text you generate using VB can be passed to load() no problem, without specifying the encoding. OR b) pass any XML which isn't Unicode to load() instead of loadXML(), and specify the encoding explicitly. It can sometimes take a bit of planning to get these issues straight. David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com -----Original Message----- From: Marko Zerdin [mailto:marko.zerdin@ixtlan-team.si] Sent: Monday, September 13, 1999 11:17 AM To: 'Chris Lovett' Cc: 'xml-dev@ic.ac.uk' Subject: RE: MSXML for Java Questions OK. Here is XML that I sent in my first mail at the beginning of the thread: value value value value value value value value value value When I pass this as an argument into the method DOMDocument.loadXML(String), I get following error: line 1, column 44: Switch from current encoding to specified encoding not supported. That's it. This is actually the only problem I had with this parser. I didn't really work with some very complicated XML, and I didn't even touch XSL yet, so I don't know what's waiting for me in the future. If anybody knows for other "features" of IE5 parser, I would appreciate any information. Wish you all the best, Marko. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe 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 Tue Sep 14 15:26:46 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:58 2004 Subject: enumeration and defaults In-Reply-To: <3.0.32.19990913151736.00cee360@pop.intergate.bc.ca> from "Tim Bray" at Sep 13, 99 03:18:16 pm Message-ID: <199909141406.KAA01785@locke.ccil.org> Tim Bray scripsit: > I'm pretty sure John would agree. -Tim And so I do. I must say that I can see no possible reason for distinguishing, in an enumeration context, among not-present and null-string. In a CDATA context, yes, because the zero-length string is a perfectly legitimate string distinct from logical null. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 14 15:37:28 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:58 2004 Subject: XML Announcements In-Reply-To: <19990914002833.48283.qmail@hotmail.com> from "Robin Cover" at Sep 13, 99 07:28:31 pm Message-ID: <199909141417.KAA02148@locke.ccil.org> Robin Cover scripsit: > > There were two fairly significant sets of announcements on XML today. > I posted news summaries on my Web site > (http://www.oasis-open.org/cover/sgmlnew.html), but the server > has apparently been taken the server down [...]. Obviously the work of a disgruntled minority among the ABMs. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 14 16:22:46 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:58 2004 Subject: Unicode 3.0 is no longer beta Message-ID: <199909141501.LAA04138@locke.ccil.org> The Unicode 3.0 data files are now in final form at the Unicode FTP site (ftp://ftp.unicode.org/Public/3.0-Update), although the Unicode 3.0 *book* won't be available until January. There are no changes to my XML/Unicode 3.0 proposal as a result. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Tue Sep 14 16:48:23 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:58 2004 Subject: MSXML for Java Questions Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFEB1@cc20exch2.mobility.com> If I read your post right, that might not work either. :-( You want to take text which is in ISO-8859-2 and put it into MSXML using load(), and then get it back at some point, still in ISO-8859-2. MSXML always translates all text to Unicode internally; that is, when you pass your ISO-8859-2 text to load(), MSXML first translates the text to Unicode, and then parses it. Any text that MSXML passes back to you will also be in Unicode, regardless of the initial encoding used. So if my assumption is correct, you won't be able to do what you want and get the text back from MSXML in ISO-8859-2; only in Unicode. David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com -----Original Message----- From: Marko Zerdin [mailto:marko.zerdin@ixtlan-team.si] Sent: Tuesday, September 14, 1999 3:40 AM To: 'xml-dev@ic.ac.uk' Subject: RE: MSXML for Java Questions Thank you all. I got the idea now. Since String in Java is already in Unicode (and not in ISO-8859-2), parser doesn't simply ignore the encoding setting (simply put it in DOM tree without any consequences), but complains about it. I wanted to use this setting in order to preserve original and final encoding in the overall structure of XML document, but it seems that I'll have to find some way aroun (most probably use load()). Thank you all again. I wish you all the best, Marko. -----Original Message----- From: Hunter, David [mailto:dhunter@Mobility.com] Sent: Monday, September 13, 1999 5:47 PM To: 'Marko Zerdin'; 'Chris Lovett' Cc: 'xml-dev@ic.ac.uk' Subject: RE: MSXML for Java Questions The problem is that loadXML() in MSXML takes only Unicode strings, whereas load() will take strings in any character set (as long as it's specified). If you take that same XML and load it into MSXML using the load() method, you should find that it will work fine. The trick is that you have to either a) make sure any text you pass to loadXML is Unicode. This is easier if you use a language like Visual Basic, which uses all Unicode strings internally; this means that any text you generate using VB can be passed to load() no problem, without specifying the encoding. OR b) pass any XML which isn't Unicode to load() instead of loadXML(), and specify the encoding explicitly. It can sometimes take a bit of planning to get these issues straight. David Hunter david.hunter@mediaserv.com MediaServ Information Architects http://www.MediaServ.com -----Original Message----- From: Marko Zerdin [mailto:marko.zerdin@ixtlan-team.si] Sent: Monday, September 13, 1999 11:17 AM To: 'Chris Lovett' Cc: 'xml-dev@ic.ac.uk' Subject: RE: MSXML for Java Questions OK. Here is XML that I sent in my first mail at the beginning of the thread: value value value value value value value value value value When I pass this as an argument into the method DOMDocument.loadXML(String), I get following error: line 1, column 44: Switch from current encoding to specified encoding not supported. That's it. This is actually the only problem I had with this parser. I didn't really work with some very complicated XML, and I didn't even touch XSL yet, so I don't know what's waiting for me in the future. If anybody knows for other "features" of IE5 parser, I would appreciate any information. Wish you all the best, Marko. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Sep 14 17:17:39 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:14:58 2004 Subject: enumeration and defaults Message-ID: <3.0.32.19990914081458.00c99580@pop.intergate.bc.ca> At 10:06 AM 9/14/99 -0400, John Cowan wrote: >And so I do. I must say that I can see no possible reason for >distinguishing, in an enumeration context, among not-present and >null-string. In a CDATA context, yes, because the zero-length >string is a perfectly legitimate string distinct from logical null. Well, except for detecting the not-present condition requires that your software carry around the knowledge that this element foo could have had a bar attribute but didn't, and treating that as equivalent to null-string. Which is significant extra work. Which leads me to think that legalizing declarations like would make a real difference. Mind you, I don't hear mobs with pitchforks in the streets crying for this... -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Tue Sep 14 17:25:24 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:58 2004 Subject: MSXML for Java Questions References: <805C62F55FFAD1118D0800805FBB428D02BBFEB1@cc20exch2.mobility.com> Message-ID: <37DE6979.A8B5929@pacbell.net> "Hunter, David" wrote: > > So if my assumption is correct, you won't be able to do what you want and > get the text back from MSXML in ISO-8859-2; only in Unicode. That'd be true of any XML parser in Java ... however, one can always write the java.lang.String (or character array) data into an appropriate OutputStreamWriter: Writer out = new OutputStreamWriter ( System.out, "8859_2"); Most Java Virtual Machines don't accept the "ISO-8859-2" encoding name, but they should accept "8859_2" instead (sigh). - Dave p.s. That doesn't mean that there aren't other reasons to avoid using the MSXML parser; it's not very conformant. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at ito.tu-darmstadt.de Tue Sep 14 17:37:40 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:58 2004 Subject: Wrong list? References: <00ac01befe64$1eb02e80$532ffcd0@oemcomputer> <37DDDB77.36B8074E@allette.com.au> Message-ID: <37DE6CC8.E37E3736@ito.tu-darmstadt.de> Marcus Carr wrote: > I hope the lack of response doesn't leave you with the impression that the developers list is > snobby or elitist, as neither is true. Many people are on both lists and would gladly assist > you in the other forum, but this one is unquestionably focussed differently. It's also pretty random which basic questions get answered. I've often watched the same question be posted twice in a month, answered one time and not the other, so hang in there and hope for the best. -- 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 cowan at locke.ccil.org Tue Sep 14 17:53:30 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:58 2004 Subject: Extenders (BNF rule 89) Message-ID: <199909141632.MAA08445@locke.ccil.org> I have been investigating the class of Extenders with a view to a second part to my XML/Unicoded-3.0 proposal. I find that three characters which Unicode classifies as extenders were mysteriously omitted from the XML category: U+0640 ARABIC TATWEEL U+0E46 THAI CHARACTER MAIYAMOK U+0EC6 LAO KO LA Can anyone comment on why this was done? Unless there is a compelling reason not to, I would like to bring Unicode and XML in sync here by adding these as name characters, plus the new character U+1843 MONGOLIAN LETTER TODO LONG VOWEL SIGN. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Tue Sep 14 18:04:21 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:14:58 2004 Subject: CNET on XHTML Message-ID: <37DE7281.AA54DE@pacbell.net> http://news.cnet.com/news/0-1005-200-118105.html?tag=st.ne.1005.thed.1005-200-118105 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 14 18:28:09 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:58 2004 Subject: CNET on XHTML In-Reply-To: <37DE7281.AA54DE@pacbell.net> from "David Brownell" at Sep 14, 99 09:06:25 am Message-ID: <199909141707.NAA09949@locke.ccil.org> Looks like a good, to-the-point, details-correct, non-sensationalist job to me. Well done, Paul Festa. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Tue Sep 14 18:43:18 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:14:58 2004 Subject: CNET on XHTML In-Reply-To: <199909141707.NAA09949@locke.ccil.org> References: <37DE7281.AA54DE@pacbell.net> Message-ID: <4.1.19990914124210.023d85d0@mail.webgeek.com> At 01:07 PM 9/14/99 -0400, John Cowan wrote: >Looks like a good, to-the-point, details-correct, non-sensationalist >job to me. Slight inaccuracies (namespace mapping is not the ONLY reason the group has provided), but other than that, it is a level look at it. The histrionics for the "Tower of Babel" are a bit much. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Tue Sep 14 18:47:38 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:58 2004 Subject: CNET on XHTML In-Reply-To: <37DE7281.AA54DE@pacbell.net> Message-ID: <199909141649.MAA02772@hesketh.net> At 09:06 AM 9/14/99 -0700, David Brownell wrote: >http://news.cnet.com/news/0-1005-200-118105.html?tag=st.ne.1005.thed.1005-2 00-118105 A remarkable story, indeed, and generally excellent. My favorite line has to be: >W3C representatives characterized the contentious debate over >XHTML namespaces as a normal part of the W3C review process. Very nice bit of spin, that is, thereby avoiding the unexplored political end of the story. XHTML is controversial, but the W3C is still happily in charge. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Sep 14 18:50:09 1999 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:14:59 2004 Subject: Extenders (BNF rule 89) Message-ID: <199909141729.NAA10523@locke.ccil.org> Blunderingly I wrote: > I have been investigating the class of Extenders with a view to a > second part to my XML/Unicoded-3.0 proposal. I find that three > characters which Unicode classifies as extenders were mysteriously > omitted from the XML category: Please ignore this whole posting: it was the result of a bug in my investigative scripts. The upshot is that I have now looked at the Unicode 3.0 property lists, and they don't add anything new. My previous proposal stands. However, the rationale for the fifth rule in Appendix B has now gone away, and these characters should be treated as backward-compatibility exceptions: they are of type Lm but are considered name-start characters. -- John Cowan cowan@ccil.org I am a member of a civilization. --David Brin xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mscardin at us.oracle.com Tue Sep 14 22:08:35 1999 From: mscardin at us.oracle.com (Mark Scardina) Date: Mon Jun 7 17:14:59 2004 Subject: ANN: Oracle XML Parser for Java v2.0.2 - Production Release Message-ID: <02f901befeec$f24f41d0$47be1990@us.oracle.com> The first production release of the Oracle XML Parser for Java v2 is available for download at http://technet.oracle.com/tech/xml. The following are included features and specs: New high performance architecture including DTD cache Integrated support for W3C XSLT Working Draft (Aug99) Supports validation and non-validation modes Built-in Error Recovery until fatal error. Supports W3C XML 1.0 Recommendation. Intergrated Document Object Model (DOM) Level 1.0 API Integrated SAX 1.0 API Supports W3C Proposed Recomendation for XML Namespaces Supports documents in the following encodings: UTF-8 BIG 5 UTF-16 GB2312 ISO-10646-UCS-2 EUC-JP ISO-10646-UCS-4 EUC-KR US-ASCII KOI8-R EBCDIC-CP-* ISO-2022-JP ISO-8859-1to -9 ISO-2022-KR Shift_JIS Support is available in the XML Forum on OTN to provide a collaborative area for bug reporting, technical support, and discussing other Oracle/XML issues. This forum will be used for external as well as internal beta testers. Mark V. Scardina Sr. Product Mgr & XML Evangelist Core and XML Development Server Technologies - Oracle Corporation Oracle XML News http://www.oracle.com/xml OTN http://technet.oracle.com/tech/xml xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at docuverse.com Tue Sep 14 22:32:52 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:14:59 2004 Subject: CNET on XHTML In-Reply-To: <37DE7281.AA54DE@pacbell.net> Message-ID: <000001befef0$b7c37a00$f21dfea9@w21tp> The article was updated with Ann's comment added so it is more balanced now although the result is the same: there is trouble brewing for W3C. Since I am fairly certain that W3C will ignore all the arguments and concerns raised against three namespaces, I believe the divide between W3C and XML-DEV will continue to widen. I wonder why the SOAP spec was submitted to IETF rather than W3C? A new trend of sort? Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From xml at searchtools.com Wed Sep 15 00:10:03 1999 From: xml at searchtools.com (Avi Rappoport) Date: Mon Jun 7 17:14:59 2004 Subject: Open Forum on Metadata Registries: CFParticipation In-Reply-To: <37FF5306.ADB5D501@prescod.net> References: <872567E5.0077E475.00@d53mta03h.boulder.ibm.com> <37FF5306.ADB5D501@prescod.net> Message-ID: Perhaps some of you may find this useful. Avi >Open Forum on Metadata Registries: CFParticipation > >Call for Participation >Open Forum on Metadata Registries >January 2000 > >This is a call for participation in the SC 32/WG 2 Open Forum on Metadata >Registries, which will be held January 17-21, 2000 in Santa Fe, New Mexico, >USA. You are invited to register to attend. You may also participate by >contributing relevant papers or web links. > >This is the fourth in a series of international conferences on this topic. >Participants from private enterprise, government, academe and standards >organizations will explore the capabilities, uses, content, development and >operation of metadata registries, particularly those based on ISO/IEC >11179. Emphasis is on managing the content (semantics) of data that is >shared within and between organizations or disseminated via the World Wide Web > >This Open Forum will highlight ongoing metadata registry efforts with >"tracks" that describe metadata management activities in the fields of >health care, environmental protection/cleanup, statistics & demographics >(e.g., census and labor/economic statistics), transportation, aeronautics & >space, geographic information, electronic commerce and emerging >technologies (e.g., XML, common business objects and object query interfaces). > >In addition to a focus on managing metadata about data elements and >structures containing data elements (e.g., data models, data bases, EDI >messages, queries, reports, regulations, standards, etc.), special >attention will be given to managing basic semantics -- concepts and concept >structures: controlled vocabularies, dictionaries, thesauri, ontologies and >data element components such as value domains. Presentations will range >from use of metadata registries for data standardization/data documentation >to advanced uses including a demonstration of Intelligent Information >Services--an ontology-based agent system for accessing environmental data >in systems dispersed between US and European organizations. > >For complete information, see: >http://www.nist.gov/openforum2000 > >The Open Forum is Organized by: >International Organization for Standardization / International >Electrotechnical Commission (ISO/IEC) > Joint Technical Committee 1 (JTC 1) > Subcommittee 32 - Data Management and Interchange (SC 32) > Working Group 2 - Metadata (WG 2) > >Please feel free to circulate this call for participation to any >distribution lists that you think appropriate. > >Bruce Bargmeyer >U.S. Environmental Protection Agency >401 "M" Street, S.W., Mail Code 3408 >Washington, DC 20460 >Tel:202-260-5306, FAX: 202-401-8390 _______________________________________________________ Guide to Local Site, Intranet, and Portal Search Engines: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bosak at boethius.eng.sun.com Wed Sep 15 05:29:15 1999 From: bosak at boethius.eng.sun.com (Jon Bosak) Date: Mon Jun 7 17:14:59 2004 Subject: XML Phase III begins Message-ID: <199909150331.UAA12378@boethius.eng.sun.com> The World Wide Web Consortium has just announced Phase III of the W3C XML Activity. Phase I of the activity, from June 1996 to August 1998, defined XML 1.0 and XML Namespaces. Phase II, from August 1998 to August 1999, created XML information set and XML fragment specifications, corrected errors in the XML 1.0 Recommendation, and began work on XML linking, XML schemas, and XML stylesheets (the last of these being moved into the W3C User Interface Domain under the name "XSL"). Phase III, which officially began 13 September 1999, continues the XML Linking and XML Schema Working Groups and creates an XML Core Working Group to continue the work of the former XML Infoset, Syntax, and Fragments WGs and provide a forum for further work on XML namespaces. It also adds an XML Query Working Group tasked with the development of an XML query language and provides for the creation of an XML Packaging WG when work on the other specifications reaches a point where resources can be devoted to it. As in Phase II, the XML Activity is managed by an XML Coordination Group, consisting of the chairs of the XML WGs, and an XML Plenary, which consists of the participants in the XML WGs and provides a forum for the discussion of requirements and architectural issues. Jon Bosak Chair, W3C XML Coordination Group and XML Plenary xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Wed Sep 15 11:11:42 1999 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:14:59 2004 Subject: CNET on XHTML In-Reply-To: <000001befef0$b7c37a00$f21dfea9@w21tp> References: <37DE7281.AA54DE@pacbell.net> <000001befef0$b7c37a00$f21dfea9@w21tp> Message-ID: <19990915051422.A16564@w3.org> On Tue, Sep 14, 1999 at 01:35:37PM -0700, Don Park wrote: > The article was updated with Ann's comment added so it is more balanced now > although the result is the same: there is trouble brewing for W3C. Since I > am fairly certain that W3C will ignore all the arguments and concerns raised > against three namespaces, I believe the divide between W3C and XML-DEV will > continue to widen. > > I wonder why the SOAP spec was submitted to IETF rather than W3C? A new > trend of sort? Don, you seem to have a hard time accepting the fact that W3C simply exists. Having a serious debate on technical facts about a specification is useful it occurs at various level within W3C, in the working groups, outside of the group like in xml-dev, and basically this refinement process is the best gard against flawed design. Taking into account public feedback is part of our process, all public drafts have public, archived mailing-lists for that exact purpose, and the Working Group has to provide feedback on points raised there. If they don't, they are at fault. I guess Ann and other members of that working group did explain the reasons of their technical decision. W3C staff didn't ignore the issues raised. Members of the Working Group didn't either, and I guess a large number of people generally involved in the XML activity took part ot the debate so the awareness is high withing the W3C member organization. A specification which would get fairly negative feedback from member won't get Recommendation status. The feedback loop exists, and from what I see, it is active. Daniel -- 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, XML, http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 15 14:18:35 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:59 2004 Subject: CNET on XHTML In-Reply-To: <19990915051422.A16564@w3.org> References: <000001befef0$b7c37a00$f21dfea9@w21tp> <37DE7281.AA54DE@pacbell.net> <000001befef0$b7c37a00$f21dfea9@w21tp> Message-ID: <199909151221.IAA11984@hesketh.net> At 05:14 AM 9/15/99 -0400, Daniel Veillard wrote: >Having a serious debate on technical facts about a specification is useful >it occurs at various level within W3C, in the working groups, outside of >the group like in xml-dev, and basically this refinement process is the >best gard against flawed design. Taking into account public feedback is >part of our process, all public drafts have public, archived mailing-lists >for that exact purpose, and the Working Group has to provide feedback >on points raised there. If they don't, they are at fault. I guess Ann >and other members of that working group did explain the reasons of >their technical decision. Er - a large part of the problem is that the working group did _not_ explain the 'reasons of their technical decision' - all we've gotten in any even vaguely 'official' sense is that the W3C HTML WG reached consensus on the 3-namespace draft. No rationale from the WG, no explanation of how it happened or why it changed from the previous 1-namespace draft. Without that rationale, 'public feedback' doesn't have a whole lot to work on. We've made up some pretty good technical (and other) stories to explain it, but have no real rationale. Perhaps we non-members should demand that rationale on the W3C's own lists, but it doesn't sound like we'd have any better luck there than we have had on XML-dev. > W3C staff didn't ignore the issues raised. Members of the Working Group >didn't either, and I guess a large number of people generally involved >in the XML activity took part ot the debate so the awareness is high >withing the W3C member organization. A specification which would get >fairly negative feedback from member won't get Recommendation status. >The feedback loop exists, and from what I see, it is active. >From here, all I see is dead silence. That may mean that the W3C is percolating internally, but there is no return loop for public feedback other than whether or not the document progresses to recommendation status. An informed public would likely be a happier public. As it stands now, I think discouraged is about the friendliest word I can find to describe my own feelings about W3C process and communication with non-members. While everything said above sounds good, I'd much rather see action from the W3C - provision of rationales for decisions, especially when they come into question, and response to public feedback that actively tells non-members that their concerns are in fact being addressed. Writing to the W3C comment lists is currently like writing to a black hole, in most cases, with no official response of any sort and only rarely even an unofficial response. Perhaps the W3C needs some sort of public information auditor, an employee without access to the member areas. That might help get through to the W3C how little the public actually sees. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Wed Sep 15 14:40:09 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:14:59 2004 Subject: admin:more odd filtering In-Reply-To: <199909151221.IAA11984@hesketh.net> References: <19990915051422.A16564@w3.org> <000001befef0$b7c37a00$f21dfea9@w21tp> <37DE7281.AA54DE@pacbell.net> <000001befef0$b7c37a00$f21dfea9@w21tp> Message-ID: <199909151242.IAA12655@hesketh.net> David Megginson wrote last week that he was getting odd characters in some messages. I hadn't seen it until this morning, when one of my own messages suddenly sported an extra ">", thereby making one of my lines look like a quote. In the archives, the whole line that got quoted is just missing. (http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0738.html) Any ideas why this is happening? Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 nwoh at software-ag.de Wed Sep 15 15:34:19 1999 From: nwoh at software-ag.de (Hutchison, Nigel) Date: Mon Jun 7 17:14:59 2004 Subject: C/C++ DOM implementation using expat Message-ID: <005355AD0596D211B4F30000F81B0D320182E342@daemsg01.software-ag.de> Is anyone working on a C/C++ DOM implementation using expat? regards Nigel Hutchison Nigel W.O Hutchison Chief Architect Software AG Uhlandstr 12, D-64279 Darmstadt, Germany +49 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 DuCharmR at moodys.com Wed Sep 15 16:11:22 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:14:59 2004 Subject: xml-dev volume (was: On the record?) Message-ID: <01BA10F0CD20D3119B2400805FD40F9F277D91@MDYNYCMSX1> >Strikes me that XML-DEV has enough traffic to need some >intelligent way to filter the wheat from the chaff Well, there's Peter M-R's "xml-dev" jewels at http://www.vsms.nottingham.ac.uk/vsms/xml/jewels.html, and I often find that a tasty quote from some xml-dev thread that I'm not following makes Elliote R-H's Cafe Con Leche "Quote of the Day" (http://metalab.unc.edu/xml/). >[on the Linux kernel developer's list] one person does a >reasonable job of summarizing and highlighting the main >threads Sounds like a pretty heroic effort. Someone looking to save time is certainly not going to volunteer for such a job; he or she can only sit back (or rather, work on more pressing projects) and wait for someone else to do so. I can't, myself, but I'll buy two drinks at the next conference for whoever does... Bob DuCharme www.snee.com/bob "The elements be kind to thee, and make thy spirits all of comfort!" Anthony and Cleopatra, III ii xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From heikki at citec.fi Wed Sep 15 16:32:57 1999 From: heikki at citec.fi (Heikki Toivonen) Date: Mon Jun 7 17:14:59 2004 Subject: C/C++ DOM implementation using expat In-Reply-To: <005355AD0596D211B4F30000F81B0D320182E342@daemsg01.software-ag.de> Message-ID: <000301beff87$11d93cf0$2500a8c0@hto.citec.fi> > Is anyone working on a C/C++ DOM implementation using expat? One obvious answer is Mozilla (http://www.mozilla.org). It uses Expat and has DOM and is mostly written in C++. -- Heikki Toivonen http://www.doczilla.com http://www.citec.fi xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From praf1 at cam.ac.uk Wed Sep 15 16:33:10 1999 From: praf1 at cam.ac.uk (Paul Fidler) Date: Mon Jun 7 17:14:59 2004 Subject: admin:more odd filtering In-Reply-To: <199909151242.IAA12655@hesketh.net> Message-ID: On Wed, 15 Sep 1999, Simon St.Laurent wrote: > David Megginson wrote last week that he was getting odd characters in some > messages. I hadn't seen it until this morning, when one of my own messages > suddenly sported an extra ">", thereby making one of my lines look like a > quote. ... > Any ideas why this is happening? Unix mailboxes generally consist of a concatenation of a whole lot of mail messages separated by lines that start "From ". Unfortunately this means it isn't possible to have a line beginning "From " in the body of the message, so MTAs and things using unix format mail folders change it to ">From ". Nothing ever converts it back to "From " since it isn't possible to tell the difference between a ">From " that should be a "From " and a genuine quoted ">From ". eg. The next line starts "From ". The line after it starts ">From ": >From here I can see the sea. >From here I can see the sea. But they will probably look identical by the time this message leaves the machine I'm writing this on. Paul Fidler -- Cambridge University Engineering Department Trumpington Street, Cambridge, CB2 1PZ, 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 kenn at bluetree.ie Wed Sep 15 16:42:27 1999 From: kenn at bluetree.ie (Kenn Humborg) Date: Mon Jun 7 17:14:59 2004 Subject: COM XML parser Message-ID: <01BEFF91.4230FC80@beowulf.bluetree.ie> We've used the MSXML redistributable parser from Microsoft in our VB application. This application will be distributed as shrink-wrap. However, the license for MSXML requires that IE4.0sp1 be installed on the user's machine. We don't want to make IE4 a requirement of our app. Does anyone know of a similar parser? I like the interface to the MSXML parser (a COM object hierarchy that is very easy to use in VB) so a similar interface would be a major plus. We don't mind paying for it (as long as it is good...) Thanks in advance, Kenn xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Wed Sep 15 16:56:25 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:14:59 2004 Subject: CNET on XHTML Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFEBE@cc20exch2.mobility.com> From: Daniel Veillard [mailto:Daniel.Veillard@w3.org] Sent: Wednesday, September 15, 1999 5:14 AM > I guess Ann > and other members of that working group did explain the reasons of > their technical decision. Let me just echo Simon St. Laurent: No. We have no reason. We have nothing. This "debate" has been going on since August 28th. I get dozens of emails every day from the mailing list on this subject. (Actually the numbers have died down recently; perhaps xml-dev has come to a bit of a consensus.) But we have no "reason for the technical decision". Nobody officially came forward from the WG and said "Oh, I see you're debating our namespace decision. We made it because..." Even worse, there is no explanation on the XHTML spec. (Because not everyone subscribes to xml-dev.) The CLOSEST I can find are some emails from a single WG member, Ann Navarro, from way back at the beginning of the debate, where she says that there are three flavours of XHTML, so there should be three namespaces. (Obviously paraphrased.) But she could never say "we made the decision because..."; in fact, she couldn't speak on behalf of the group at all (which is understandable). (Apologies to Ann for singling her out once again. I realize she's taken a lot of heat on the group over this debate, since she's the closest thing we've had to an actual "official response".) If the working group wants to explain their decision, I'd suggest putting up a page on the W3C site somewhere with the explanation, so the whole world can see it and not just xml-dev, and then post the URL to the group (and any other groups which may be interested). Or modify the XHTML draft itself, although I'm betting this is more complicated than just adding the changes. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 15 17:02:30 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:14:59 2004 Subject: Sybase and XML? Message-ID: <01BEFF9C.A8896430@grappa.ito.tu-darmstadt.de> DuCharme, Robert wrote: > Have any Sybase users read the PDF whitepapers about the new Adaptive > Server's XML capabilities? The longer one is called "Using XML with the > Sybase Adaptive Server SQL Databases" and the shorter one is "Increasing > Developer Productivity with Java and XML in Sybase Adaptive Server > Enterprise." (I don't have a URL, because they were passed to me at work, > but they're probably at www.sybase.com somewhere.) Here's the URL. The first is by far the most technical: http://www.sybase.com/products/databaseservers/ase/whitepapers/L01067.pdf http://www.sybase.com/products/databaseservers/ase/whitepapers/L01064.pdf > It looks to me like the majority of their XML "support" is the fact that ASE > is tightly integrated with Java and Java goes well with XML. Sybase provide > you with a few classes to inherit from, but you still have a ton of Java > coding to do. If they only advertised Java integration with no XML support, > there wouldn't be much difference. > > Maybe I'm missing something. Any opinions? I'm not a Sybase user, but I did read the papers and would have to agree. In particular, one of the papers said: "Most tools for working with XML documents are written in Java. The support for Java in SQL provided by the Adaptive Server Anywhere 6.0 and Adaptive Server Enterprise 12.0 database servers therefore provide a good base for supporting XML in SQL..." Not much of a story there. To be fair, there are hints of something more, although my marketing filter and the other paper make me read this as do-it-yourself: "Sybase provides an XML parser that converts XML data into a form that can be easily understood by the Adaptive Server Enterprise database. In addition, data stored in the database can be retrieved as XML data, allowing easy integration of existing information to Web applications." On a similar vein, do any relational database companies besides Oracle even have an XML story? I've seen some press releases about DB2, but these are so vague as to be meaningless. -- 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 greynolds at datalogics.com Wed Sep 15 17:18:10 1999 From: greynolds at datalogics.com (Reynolds, Gregg) Date: Mon Jun 7 17:14:59 2004 Subject: W3C Process - suggestions Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16DBB@martinique> Here's a few ideas for specific things the W3C could do to improve communication with the outside world. I'm rather pressed for time these days, so I don't have time to write up a formal proposal, but maybe somebody on the list will pursue something like it. - Add an "Issues List" or the like as an official required work product, along with a required publishing schedule of, say, every two weeks. To accurately record the topics of discussion at the least, with WGs free to include debating points, comments, etc. as they see fit. - Provide a required format for said issues list, designed to facilitate clarity and communication by including such things as a numbering scheme, an annotation mechanism, a means of identifying and referencing revisions/annotations/comments/etc, a means of relating items on the issues list and parts of a working draft; etc. - Provide administrative support for the production of such work products; that is, people whose job it is to see to administrative issues like just editing the Issues List, putting it in the required form, putting it up on the required web page, publicizing its release, etc. Where the WG's wishes are contrary to the required publication schedule, such administrative staff should be empowered to publish anyway. There are probably lots of other concrete steps the W3C could take to improve communication, but those three strike me as reasonable for a start. Confidential discussions are still protected, for those members that feel it important, but the public feedback loop would be improved considerably, and WGs would be held more strictly accountable to a publishing schedule. I think such mechanisms might have prevented some of the unhappiness we now see w/r/t XHTML, or at least reduced the surprise factor. Unfortunately, the last item, administrative support, is the most important and the least likely to be adopted, since it involves real money and makes the WGs a little less autonomous. Surely somebody on xml-dev could come up with an issues-list dtd or the like. (I guess I should say I haven't been able to follow the list closely for some time, so if somebody already made these suggestions, uh, please pretend that they didn't.) Gregg Reynolds these are my personal opinions only, and do not reflect the views of etc. (you know the drill). xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From pandeng at telepath.com Wed Sep 15 17:27:03 1999 From: pandeng at telepath.com (Steve Schafer) Date: Mon Jun 7 17:15:00 2004 Subject: COM XML parser In-Reply-To: <01BEFF91.4230FC80@beowulf.bluetree.ie> References: <01BEFF91.4230FC80@beowulf.bluetree.ie> Message-ID: <37e0baf2.125278601@90.0.0.40> On Wed, 15 Sep 1999 15:44:54 +0100, you wrote: >However, the license for MSXML requires that IE4.0sp1 >be installed on the user's machine. We don't want to >make IE4 a requirement of our app. It's not really a license agreement, per se. MSXML.DLL simply won't work properly on a pre-IE4 machine, because it uses functionality in SHLWAPI.DLL that isn't present in pre-IE4 versions of that DLL. -Steve xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Wed Sep 15 17:27:44 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:00 2004 Subject: CNET on XHTML References: <805C62F55FFAD1118D0800805FBB428D02BBFEBE@cc20exch2.mobility.com> Message-ID: <37DFBB3B.1138141F@pacbell.net> "Hunter, David" wrote: > > From: Daniel Veillard [mailto:Daniel.Veillard@w3.org] > Sent: Wednesday, September 15, 1999 5:14 AM > > > > I guess Ann > > and other members of that working group did explain the reasons of > > their technical decision. > > > Let me just echo Simon St. Laurent: > > No. We have no reason. We have nothing. Aye -- nothing. An "official" W3C rationale is still lacking; odd since this decision seems to fly in the face of the clear intent of the XML namespaces spec. "A html:rose is a strict:rose is a frameset:rose ... " - 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 jadams at touchpointsw.com Wed Sep 15 18:00:43 1999 From: jadams at touchpointsw.com (jadams@touchpointsw.com) Date: Mon Jun 7 17:15:00 2004 Subject: Element Tags vs Attributes Message-ID: <852567ED.0053C036.00@postal.imagedata.com> A while back there was a brief discussion of using element tags vs attribute list to identify values. Briefly: One benefit of sticking with element tags is that all PCDATA values are collected and application variables set "on one page". When using both element tags and attributes, values are collected "on two different pages". Maintenance and debugging is easier when all input XML values are collected/set in one place. qed xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken_north at compuserve.com Wed Sep 15 18:41:08 1999 From: ken_north at compuserve.com (Ken North) Date: Mon Jun 7 17:15:00 2004 Subject: Sybase and XML? References: <01BEFF9C.A8896430@grappa.ito.tu-darmstadt.de> Message-ID: <004501beff99$8a466160$0b00a8c0@grissom> Ronald Bourret wrote: > On a similar vein, do any relational database companies besides Oracle even > have an XML story? Yesterday I posted information (below) about this to another list. The short answer is yes. "Object Design eXcelon and Software AG Tamino are XML data servers, as opposed to universal servers from Oracle, IBM, and Informix. Sybase and Microsoft are also jumping into the universal server competition by extending their SQL servers to support XML." Microsoft announced their plans just this week. SQL Server 7.0 does not include the Java VM for running Java classes installed in the database. Sybase, Oracle, and IBM have been shipping servers that integrate a Java VM (Sybase Adaptive Server Anywhere 6.0 and newer, IBM DB2 UDB 5.0 and newer, and Oracle 8.1.4 and newer). Informix and IBM are in beta test with new releases having XML extensions. Ditto Oracle 8.1.6 and Sybase ASE. At a conference this summer, Informix demonstrated its new version by showing a Web server running inside a database -- it served up XML and HTML. ================================= XML One Europe, London, England October 6-8, 1999 http://www.xmlconference.com/xmleuro/index.shtml Java Developer's Conference, San Jose, California, October 17-21, 1999 http://javadevcon.com XML One USA, Santa Clara, California November 8-11, 1999 http://www.xmlconference.com/xmlusa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schen at falconwing.com Wed Sep 15 20:56:45 1999 From: schen at falconwing.com (schen@falconwing.com) Date: Mon Jun 7 17:15:00 2004 Subject: More chaos coming down the pike In-Reply-To: <001a01befe0c$bec6b9f0$1776020d@phobos.parc.xerox.com> Message-ID: Hi Mike, everyone, On Mon, 13 Sep 1999, Mike Spreitzer wrote: > Those two trains are proceding down their independent tracks. Sun has > approved the "XML Data Binding" JSR; for more info, see the Java > Community Process web site at > . The OMG > has issued the "XML/Value RFP"; for more information, see > . > Neither explicitly requests coordination with the other. The OMG folks > say that doesn't prevent a responder from making a coordinated response. > > The recent barrage of mail about "the grove paradigm" make me even more > worried about coherency. I haven't actually studied it yet, but the > mail makes me suspect "the grove paradigm" is a meta-model (or > meta-meta-model). The OMG has their own modelling architecture, > centered around the MOF (Meta-Object Facility) and XMI (Xml Metadata > Interchange). If the XmlSchema->JavaType mapping is grounded in groves, > and the XmlSchema->OmgIdl mapping is grounded in the MOF, getting > coherency after the fact may involve some very deep problems. Although I'm not an expert in the grove paradigm or in MOF, I don't think that things are as bad as you may fear, since you can represent groves in MOF too. See the thread on the XSL mailing list about representing DTDs in UML. . . . Sean. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From timbl at w3.org Wed Sep 15 22:39:00 1999 From: timbl at w3.org (Tim Berners-Lee) Date: Mon Jun 7 17:15:00 2004 Subject: Another look at namespaces Message-ID: <006101beffba$a2984280$a60a1712@col.w3.org> Paul Prescod (paul@prescod.net) on Mon, 30 Aug 1999 08:29:53 -0400 said, > There are two separate issues here. Yes. > #1. In 1999 xHTML can either have three namespaces or one. If it has > three then there will be a one-to-one relationship between namespaces > and grammars so that a programmer can know the grammar of the input > data. Programmers that want to treat the three as one will have to do so > by issuing some command to their namespace processor or (better) by > using a namespace processor that recognizes an embedded instruction. [...] > I think that people are really concerned more about the precedent than > today's issue. Yes. It is a question of how namespaces are used. I have no passionate personal concern as to whether XHTML spec defines 3 languages or one, but the HTML 4.0 spec defined three, and XHTML was required to be as direct a mapping from HTML 4.0 to XML as possible. You can dispute (and many do) whether defining both "strict""and "transitional" is useful. (where by "strict" read 'http://www.w3.org/TR/.../strict" or whatever the URI for strict namespace is) Aside from that discussion, let's just use Strict and Transitional as examples if one does have two languages. It is important to realize that these are *different* languages. If you take a Transition document and re-label it as a strict document it can be invalid. Invalid by specification, whether represented by English or DTD or schema. But equally important is what folks are getting at I think when they say they are the "same" language: that Strict is a *subset* language of Traditional. That means, that if you take any valid Strict document, and transform is by changing nothing except the namespace URI from Strict to Transitional, then it *will* always be a valid document in every sense. This applies whether you define validity using just a spec or with the help of a DTD or schema. > #2. In 2000, 2001, 2002, etc. there will be new versions of XHTML. Some > (probably all) of these will be backwards incompatible as every version > of HTML has been backwards incompatible: a document conforming to the > new vocabulary/grammar can break code expecting the old > vocabulary/grammar. Yes, absolutely - leaving aside again the question of XHTML itself and treating it as an example. > It is *vital* that a) there be a way to announce this > backwards-incompatibility and b) there be an infrastructure that allows > a mapping from new to old. The namespace is the obvious way to do the > former. We have no good mechanism for the latter. > > As I've said, this is also necessary for e-commerce and every other XML > application. Yes. > If we develop this mechanism now then the first wave of XHTML software > will be automatically ready for XHTML 2.0 (not to mention e-commerce). I > can understand the wish to delay the problem but it just means that we > cause a train wreck later on. I am deathly afraid, however, that if we > set a precedent of pretending that these three variants are "one > language" we will continue down that path as we develop more and more > incompatible new versions. Yes. We cannot afford to be fuzzy. We must be able to use compatibility where it exists (easily and simply) but absolutely not assume it where we have no reason to. This principle of mandatory extension is something which we tried for years to get into HTTP because we needed it for putting in new mandatory features. In HTML originally I specifically stated that any unknown tag must be processed as though it was replaced by its content. In other words, For all x not in HTML, abc --> a b c (1) preserved HTML-validity. That was a good thing and a bad thing: it allowed experiments galore. It also alas allowed total ambiguity to arise when e.g. was introduced by Raggett and Netscape and others at the same time. Namespaces fix that directly. It allowed, equally seriously, no way of saying "If you don't understand this feature then you cannot process this document. This is a very important requirement for any language IMHO. In this case, the only information which a Transitional-capable receiver of information needs to be able to process a Strict document is "Strict is-a-subset-of Transition" This gem could be - programmed into a xHTML-specific application or - picked up from a schema or - picked up from the document itself The latter case is useful where you have an in-house subset of a language but you want generic browsers to know that the language can be processed as xHTML. As you say, this is really important for version change. "v2 is a subset of v1" is a rare case which any v2 document can be interpreted as a v1 document. What happens when a version one program meets a version 2 document? a). Halt. "Don't understand". This happens with typical word processors. sometimes this is the behavior you need. b) Know that it is a subset of what you know, and process it. c). Parse it and ignore new features. This can be done by using a separate namespace for the new features, and by saying in some way (which we really need) that it is ok to ignore (replace with contents, or remove: state which) elements in that namespace for the purposes of that document. d) Convert it into a v1 document. [(b) and (c) are actually a special cases of (d)]. In the last case, the application only innately "understands" the v1 language, but the schema includes [pointers to] rules which allow a valid v1 document to be deduced from the valid v2 document. These are rules e.g. of the form (1), or a set of "Optional/mandatory" flags for the elements. Or maybe an XSLT mapping. Or a set of inference rules for RDF. (d) requires that the application-specific processor have at its disposal a nonspecific translation processor of some sort. I would like to see a simple way of defining subset languages introduced with all speed, to allow (a) and (b) for all XML applications. I'd like to see experiments with (c) and (d) too, in particular an early way to define optionalness of namespaces in XML in a particular document. Underlying this is a philosophy about the meaning of a document. As I see it, a document is from the author to the reader, and its job is to convey the intent of the author. When an author uses a defined language, then the author refers to the language-author's definition of terms in the language. When I write you an XML document, then what I mean is what I say, interpreted according to the specifications of the language - the namespace - I use. Of course on the web we don't expect machines to "understand" information in an AI way. We use a version of "understand" which means to be able to translate it into something which it has innately been programmed to process, while preserving in that translation the intent of the author. This may seem a heavy way of defining HTML but think about the international exchange of invoices. The web of meaning between languages is defined by the set of these transformations. The namespaces spec was adamant that you could use namespaces without having to dereference the namespace URI. However, as we define languages for talking about languages (XML and RDF schemas for example, even style sheets) the document corresponding to the namespace URI becomes the place where the namespace-author can put *definitive* information about the intent of the namespace. And this is not mandatory - but is very useful! For example, you can run an xHTML document though any DTD you like if it suits your purposes, but if you want to check whether it is valid xHTML then you should use the xHTML schema which corresponds to the namespace URI. You might of course have a local copy and not actually need to go onto the net to us live HTTP. The exciting use of namespaces in schemas will be when we have schema documents which contain the syntactic constraints in xml-schema language, but themselves use other namespaces to come to express the entity-relationship model of data (rdf-schema), legally appropriate presentation (link to style sheet), financial implication (link to mapping to FSTC echecks or whatever). The functionality which we will be able to build into new languages will grow as the richness of languages to which we can map. > Paul Prescod Tim Berners-Lee not in any official capacity. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rja at arpsolutions.demon.co.uk Thu Sep 16 00:04:30 1999 From: rja at arpsolutions.demon.co.uk (Richard Anderson) Date: Mon Jun 7 17:15:00 2004 Subject: COM XML parser References: <01BEFF91.4230FC80@beowulf.bluetree.ie> Message-ID: <00b801beffc6$bcd36290$4a5eedc1@arp01> Our ActiveDOM is almost a directly replacement: http://www.vivid-creations.com Free version coming soon.... ----- Original Message ----- From: Kenn Humborg To: Sent: Wednesday, September 15, 1999 3:44 PM Subject: COM XML parser > > We've used the MSXML redistributable parser from > Microsoft in our VB application. This application will be > distributed as shrink-wrap. > > However, the license for MSXML requires that IE4.0sp1 > be installed on the user's machine. We don't want to > make IE4 a requirement of our app. > > Does anyone know of a similar parser? I like the interface > to the MSXML parser (a COM object hierarchy that is very > easy to use in VB) so a similar interface would be a major > plus. > > We don't mind paying for it (as long as it is good...) > > Thanks in advance, > Kenn > > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Sep 16 01:29:09 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:00 2004 Subject: Another look at namespaces In-Reply-To: <006101beffba$a2984280$a60a1712@col.w3.org> References: <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <14304.11288.712453.705292@localhost.localdomain> [I'd like to start by thanking Tim for making his personal views known in a public forum.] Tim Berners-Lee writes: > What happens when a version one program meets a version 2 document? As Tim points out, this is (or at least, should be) application-specific. I have omitted his summary, but I agree with its broad outlines. Unfortunately, I think that Tim B-L and Paul Prescod are wasting a little of their typing preaching to the converted; we all (or at least, most of us) agree and always have agreed that the following are basic requirements for dealing with Namespaces: 1. An application must be able to determine the general language used by (part of) a document. 2. An application must be able to determine the specific dialect used by (part of) a document. 3. An application must be able to locate schemas, stylesheets, and other materials related to a language (or dialect). What is contentious is not whether these three requirements are real, but rather, what mechanisms for satisfying them will be most likely to gain acceptance and what mechanisms will work best in Web environment. The guiding design principle should be to make the most commonly-needed information the most accessible. I believe that a. the vast majority of applications will be most concerned with #1; and b. the applications concerned only with #1 will tend to be the lightest-weight ones. If my guesses are correct, then it is essential that the answer to #1 be trivially obtainable -- in the document, through the Namespace URI itself -- while the answers to #2 and #3 can be made available through secondary mechanisms such as conventional Namespace attributes (such as 'version') or packaging manifests. We mustn't make easy tasks difficult for the sake of theoretical purity -- I know, because we tried to do that over and over again in the SGML world, and, well, we're not debating SGML any more, are we? 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 cbullard at HiWAAY.net Thu Sep 16 05:18:10 1999 From: cbullard at HiWAAY.net (Len Bullard) Date: Mon Jun 7 17:15:00 2004 Subject: Another look at namespaces References: <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <37E04409.2AED@hiwaay.net> Tim Berners-Lee wrote: Excellent, Becket. Bravo. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Thu Sep 16 05:20:24 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:15:00 2004 Subject: Another look at namespaces Message-ID: <5BF896CAFE8DD111812400805F1991F712E172B6@RED-MSG-08> I would like to comment on one of the several issues in this thread. 1. If indeed there are separate languages, where the elements in one require different processing (such as different validation) from elements in another, then the distinct elements of each should be distinguished by different namespaces. 2. If one of the languages is a superset of the other, as Traditional is apparently a superset of Strict, then there is nothing in the namespaces spec per se that prevents a document instance from combining elements from both namespaces. There is nothing in the namespaces specification that requires that all the elements in a document come from the same namespace. One consequence of this is that the superset language (e.g. Traditional) does not need to define its own equivalent of each term in the subset language. The difficulties in doing this today are limitations of the language definition facilties in DTDs. There is not anything that prevents a future schema language from defining validation and schema composition in such a way that use of items from one language within another is convenient, and use of elements and attributes from several namespaces in an instance document is both simple and unobtrusive. -----Original Message----- From: Tim Berners-Lee [mailto:timbl@w3.org] Sent: Wednesday, September 15, 1999 1:41 PM To: Paul Prescod Cc: XML-DEV Subject: Re: Another look at namespaces Paul Prescod (paul@prescod.net) on Mon, 30 Aug 1999 08:29:53 -0400 said, > There are two separate issues here. Yes. > #1. In 1999 xHTML can either have three namespaces or one. If it has > three then there will be a one-to-one relationship between namespaces > and grammars so that a programmer can know the grammar of the input > data. Programmers that want to treat the three as one will have to do so > by issuing some command to their namespace processor or (better) by > using a namespace processor that recognizes an embedded instruction. [...] > I think that people are really concerned more about the precedent than > today's issue. Yes. It is a question of how namespaces are used. I have no passionate personal concern as to whether XHTML spec defines 3 languages or one, but the HTML 4.0 spec defined three, and XHTML was required to be as direct a mapping from HTML 4.0 to XML as possible. You can dispute (and many do) whether defining both "strict""and "transitional" is useful. (where by "strict" read 'http://www.w3.org/TR/.../strict" or whatever the URI for strict namespace is) Aside from that discussion, let's just use Strict and Transitional as examples if one does have two languages. It is important to realize that these are *different* languages. If you take a Transition document and re-label it as a strict document it can be invalid. Invalid by specification, whether represented by English or DTD or schema. But equally important is what folks are getting at I think when they say they are the "same" language: that Strict is a *subset* language of Traditional. That means, that if you take any valid Strict document, and transform is by changing nothing except the namespace URI from Strict to Transitional, then it *will* always be a valid document in every sense. This applies whether you define validity using just a spec or with the help of a DTD or schema. > #2. In 2000, 2001, 2002, etc. there will be new versions of XHTML. Some > (probably all) of these will be backwards incompatible as every version > of HTML has been backwards incompatible: a document conforming to the > new vocabulary/grammar can break code expecting the old > vocabulary/grammar. Yes, absolutely - leaving aside again the question of XHTML itself and treating it as an example. > It is *vital* that a) there be a way to announce this > backwards-incompatibility and b) there be an infrastructure that allows > a mapping from new to old. The namespace is the obvious way to do the > former. We have no good mechanism for the latter. > > As I've said, this is also necessary for e-commerce and every other XML > application. Yes. > If we develop this mechanism now then the first wave of XHTML software > will be automatically ready for XHTML 2.0 (not to mention e-commerce). I > can understand the wish to delay the problem but it just means that we > cause a train wreck later on. I am deathly afraid, however, that if we > set a precedent of pretending that these three variants are "one > language" we will continue down that path as we develop more and more > incompatible new versions. Yes. We cannot afford to be fuzzy. We must be able to use compatibility where it exists (easily and simply) but absolutely not assume it where we have no reason to. This principle of mandatory extension is something which we tried for years to get into HTTP because we needed it for putting in new mandatory features. In HTML originally I specifically stated that any unknown tag must be processed as though it was replaced by its content. In other words, For all x not in HTML, abc --> a b c (1) preserved HTML-validity. That was a good thing and a bad thing: it allowed experiments galore. It also alas allowed total ambiguity to arise when e.g.
        was introduced by Raggett and Netscape and others at the same time. Namespaces fix that directly. It allowed, equally seriously, no way of saying "If you don't understand this feature then you cannot process this document. This is a very important requirement for any language IMHO. In this case, the only information which a Transitional-capable receiver of information needs to be able to process a Strict document is "Strict is-a-subset-of Transition" This gem could be - programmed into a xHTML-specific application or - picked up from a schema or - picked up from the document itself The latter case is useful where you have an in-house subset of a language but you want generic browsers to know that the language can be processed as xHTML. As you say, this is really important for version change. "v2 is a subset of v1" is a rare case which any v2 document can be interpreted as a v1 document. What happens when a version one program meets a version 2 document? a). Halt. "Don't understand". This happens with typical word processors. sometimes this is the behavior you need. b) Know that it is a subset of what you know, and process it. c). Parse it and ignore new features. This can be done by using a separate namespace for the new features, and by saying in some way (which we really need) that it is ok to ignore (replace with contents, or remove: state which) elements in that namespace for the purposes of that document. d) Convert it into a v1 document. [(b) and (c) are actually a special cases of (d)]. In the last case, the application only innately "understands" the v1 language, but the schema includes [pointers to] rules which allow a valid v1 document to be deduced from the valid v2 document. These are rules e.g. of the form (1), or a set of "Optional/mandatory" flags for the elements. Or maybe an XSLT mapping. Or a set of inference rules for RDF. (d) requires that the application-specific processor have at its disposal a nonspecific translation processor of some sort. I would like to see a simple way of defining subset languages introduced with all speed, to allow (a) and (b) for all XML applications. I'd like to see experiments with (c) and (d) too, in particular an early way to define optionalness of namespaces in XML in a particular document. Underlying this is a philosophy about the meaning of a document. As I see it, a document is from the author to the reader, and its job is to convey the intent of the author. When an author uses a defined language, then the author refers to the language-author's definition of terms in the language. When I write you an XML document, then what I mean is what I say, interpreted according to the specifications of the language - the namespace - I use. Of course on the web we don't expect machines to "understand" information in an AI way. We use a version of "understand" which means to be able to translate it into something which it has innately been programmed to process, while preserving in that translation the intent of the author. This may seem a heavy way of defining HTML but think about the international exchange of invoices. The web of meaning between languages is defined by the set of these transformations. The namespaces spec was adamant that you could use namespaces without having to dereference the namespace URI. However, as we define languages for talking about languages (XML and RDF schemas for example, even style sheets) the document corresponding to the namespace URI becomes the place where the namespace-author can put *definitive* information about the intent of the namespace. And this is not mandatory - but is very useful! For example, you can run an xHTML document though any DTD you like if it suits your purposes, but if you want to check whether it is valid xHTML then you should use the xHTML schema which corresponds to the namespace URI. You might of course have a local copy and not actually need to go onto the net to us live HTTP. The exciting use of namespaces in schemas will be when we have schema documents which contain the syntactic constraints in xml-schema language, but themselves use other namespaces to come to express the entity-relationship model of data (rdf-schema), legally appropriate presentation (link to style sheet), financial implication (link to mapping to FSTC echecks or whatever). The functionality which we will be able to build into new languages will grow as the richness of languages to which we can map. > Paul Prescod Tim Berners-Lee not in any official capacity. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 16 05:53:20 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:01 2004 Subject: XML parser conformance (Java) Message-ID: <37E06066.86EA0F4F@pacbell.net> On XML.com is an article that digests the results of running the current draft of the OASIS XML Conformance Test Suite against a dozen SAX parsers. Comparison tables are there to summarize everything in easily digested form. Check them for any surprises about parsers you use! I'll be looking for improvements from some parsers ... ;-) - 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 timbl at w3.org Thu Sep 16 06:08:41 1999 From: timbl at w3.org (Tim Berners-Lee) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces Message-ID: <00f501befff9$9426c160$a60a1712@col.w3.org> -----Original Message----- From: David Megginson >Tim Berners-Lee writes: > > > What happens when a version one program meets a version 2 document? > >As Tim points out, this is (or at least, should be) >application-specific. I have omitted his summary, but I agree with >its broad outlines. I'm not sure what you mean by "application -specific". If you mean that one is entitled to do feed a document into any app program and depending on what the program does anything can happen, and be taken as a valid interpretation of the document, then no! My point was that the combination of the document and the definition of the language it is written in have a certain meaning and that nothing must be allowed to produce a different (contradictory or superset) meaning ostensibly from the original document. >Unfortunately, I think that Tim B-L and Paul Prescod are wasting a >little of their typing preaching to the converted; Good. Then my message can be consided a summary I guess. > we all (or at >least, most of us) agree and always have agreed that the following are >basic requirements for dealing with Namespaces: > >1. An application must be able to determine the general language used > by (part of) a document. >2. An application must be able to determine the specific dialect used > by (part of) a document. >3. An application must be able to locate schemas, stylesheets, and > other materials related to a language (or dialect). Here you introduce a distinction between a "general language" and a "dialect". I am not convinced that this is a well-defined concept. I feel that language subsets are completely well defined, by the change of namsespace preserving validity. What is the definition of a "dialect"? To me, nesting a level of naming of "version" inside a "general" language suggets that nothing at all is really known about the general langauge. >What is contentious is not whether these three requirements are real, I'm not currently accepting the concepts on which they are based. [...] If as I fear, the "general language" refers to some approximate similarity then I would not want one single ecommerce application or data-in-xml application to use the concept. A langauge is a language IMHO. I think that you can in fact crystalize the concept of "general language" by specifying a set of languages which are all subsets of a given language L. So for example if you define xHTML-all as a language whose document content model accepts any strict or transitional or frameset document, then you can use that namespace for refering any xHTML document. You now have a clean definition of validity, and well-defined compatability rules. >b. the applications concerned only with #1 will tend to be the > lightest-weight ones. I do not believe that lightweight applications will just be fuzzy. You can imagine them for simplicity just advertizing a few superset languages as things they accept. I would not be in favor of anything which made the precise definition of the language in which a document was written anything other than a URI. You can introduce more metadata about a namespace and enrich the world, but let's keep a namepsace a namepsace as identified by the namespace URI. >We mustn't make easy tasks difficult for the sake of theoretical >purity -- I know, because we tried to do that over and over again in >the SGML world, and, well, we're not debating SGML any more, are we? I hope not. But in general simplicity tends to make easy tasks easier. If it didn't happen in the SGML design I who was not there cannot comment. You can in general optimze things which are well defined cleanly. Tim BL xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From smith at interlog.com Thu Sep 16 07:06:20 1999 From: smith at interlog.com (Chris Smith) Date: Mon Jun 7 17:15:01 2004 Subject: COM XML parser In-Reply-To: <01BEFF91.4230FC80@beowulf.bluetree.ie> Message-ID: Just a pointer, without plus or minus comments: http://www.cuesoft.com/ I believe they have both parser and DOM. Works in VB. ---------------------------------------------------------------------- Chris Smith On Wed, 15 Sep 1999, Kenn Humborg wrote: > We've used the MSXML redistributable parser from > Microsoft in our VB application. This application will be > distributed as shrink-wrap. > > However, the license for MSXML requires that IE4.0sp1 > be installed on the user's machine. We don't want to > make IE4 a requirement of our app. > > Does anyone know of a similar parser? I like the interface > to the MSXML parser (a COM object hierarchy that is very > easy to use in VB) so a similar interface would be a major > plus. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Thu Sep 16 08:11:11 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:15:01 2004 Subject: FOP 0.10.0 released Message-ID: <005f01bf0009$df4c79e0$0300000a@cygnus.uwa.edu.au> http://www.jtauber.com/fop/ This version is much faster. A 100-page test document that used to take 50 seconds in 0.9.x now takes 15 seconds. Some important bugs have been fixed. This version is approaching actually being usable for real work. Very simple support for a tiny bit of SVG. break-before and break-after implemented. Justification bug fixed. text-indent implemented. font-weight as number implemented. line-height as number implemented. Java source for properties now generated from XML document via XSLT. Added support for emdash, copyright, non-breaking-space and section Detects inline-sequence directly under flow. Display rules can go in blocks. List item labels now obey start-indent. Page breaks mid-list now (appear to) work. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net Ceci n'est pas une pipe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Thu Sep 16 08:52:14 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:15:01 2004 Subject: code generation from XML datatype definitions: anyone interested? Message-ID: <00ad01bf000e$99339560$0300000a@cygnus.uwa.edu.au> One of the things that's new in FOP 0.10.0 is that the Java source code for the classes for each XSL property is generated by applying an XSLT transform to an XML representation of the properties. This XML representation of the properties is a bit like the datatype definitions being worked on in the XML Schema WG. This got be thinking about turning what I've done into a more general solution. If anyone is interested in working with me on further developing this, please let me know. What I'm interested in developing is a tool or tools that take an augmented[*] datatype definition and produces a Java class or classes that are capable of representing the datatypes and parse string representations. [*] I say augmented because I would like to include, in the definition, code for how different lexical representations of a value get translated into a "canonical" datatype (for example, different units). I would like XSL properties to drive the requirements but would like to make it a general solution. Note that part of what the work I've begun covers is defaulting, inheritence and the computation of properties from other properties. I would like to include all this in the scope of this project. Any takers? I'm going to do it for FOP anyway, but it would be great if people could work with me to make it a generic solution. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net Ceci n'est pas une pipe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 docuverse.com Thu Sep 16 09:35:09 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces In-Reply-To: <00f501befff9$9426c160$a60a1712@col.w3.org> Message-ID: <001201bf0016$6de3f640$49e1fea9@w21tp> Mr. Tim Berners-Lee, Perhaps I am slow or something but, frankly, I am having a difficult time understanding the contents of your messages. Hoping that I'll have better luck with specific questions, here are two: 1. If XHTML had only one namespace, will it make your future plans for XHTML impossible to achieve? 2.1 If you answered yes to #1, what other mechanisms have you considered as alternatives and why do you think they will not work for the problems you are trying to solve? 2.2 If you answered no to #1, would you defer using the namespace in the new and exciting ways, at least not for XHTML, and use some other means? I have not asked my questions in terms of difficulty because difficulty exists one way or another. In other words, what is 'best' for you is not necessarily 'best' for us. The question of who is right can not be answered because we have wide differences in value. Only remaining question is who has the right of way? The cave-man version of the question is: will you go around us or through us? The priestly version of the question is: will you choose mercy or faith? I applogize if the tone of this message offends you. I have a habit of taking the offensive in all situations, probably stemming from my Patton-worship. It is nothing personal, General MacArthur. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Thu Sep 16 11:11:02 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces References: <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <37E0B481.E5CA7803@pacbell.net> Tim, thanks for sharing your perspective ... there's been a certain feeling that it has been both missing and necessary! :-) Tim Berners-Lee (timbl@w3.org) wrote: > > I have no passionate personal concern as to whether XHTML spec defines 3 > languages or one, but the HTML 4.0 spec defined three, In HTML 4.01, section 2.2 "What is HTML?" talks about "a language" and "the language", never "three languages". There are three DTDs, yes; but they're never explained as different languages. One language, three DTDs (feature deprecation issues) -- from the HTML 4.0[1] spec, I searched a dozen sections and found no "three languages" comments. Was something hidden away? In short, what you wrote is confusing to me since its use of "language" seems like it isn't the one currently used by W3C. When you wrote "language" here it seems like the correct terminology is "DTD"; that has significant implications. New terminology here would be especially troublesome as it eradicates a fundamental notion. Namely, that a language is a vocabulary, as distinct from the grammar rules constraining differents sorts of usage. If that's intentional, I think it's an issue deserving some discussion in its own right. Not to get sidetracked on "what is language"; but just to maintain that basic separation between the notions of vocabulary and grammar. And in your second post: > I feel that language subsets are completely well defined, by the change > of namsespace preserving validity. That's not quite clear to me. Why would I change the namespace URI when the information (and even structure) is unchanged? Why wouldn't I just swap some validity rules and leave the namespace(s) alone? After all, the elements and attributes haven't changed meaning, only something about the manner in which they're validated. Keep the simple stuff simple: vocabulary != grammar. > It is important to realize that these are *different* languages. > If you take a Transition document and re-label it as a strict document > it can be invalid. Invalid by specification, whether represented by English > or DTD or schema. If some particular document doesn't validate against the strict DTD, that seems to me like it's _just_ a validity issue. Doesn't affect the language at all; "say it ain't so!" is English, albeit not what a grammar teacher would applaud. That is: the "rules" (validity as checked by DTD, schema, app) are distinct from the "language" (vocabulary). Rules that only permit a subset ("strict" etc) don't create a new language. Rules that combine different vocabularies are clearly going to be an interesting game to play ... and unfortunately I don't see how an XHTML spec constrained by HTML 4.0 compatibility can afford to have separate namespaces for the non-strict chunks of vocabulary:

        An emphatic objection.

        A big toy.

        Any HTML browser would be upset at seeing the latter, and of course it's not possible to validate it without freezing the prefixes (bad). But with one XHTML namespace, everything's fine -- use validity checking for its job (help phase out those deprecated tags, , and so on), and most existing HTML agents will work fine. > the document corresponding to the namespace URI becomes > the place where the namespace-author can put *definitive* > information about the intent of the namespace. > And this is not mandatory - but is very useful! Not "the place" as in one-and-only-possible. One can easily define elements to hold such associations without needing to overload usage of the namespace identifier (URI). By the way -- which types of information? And what about information describing the way namespaces may combine, rather than information about some individual namespace? Or information that's part of _my_ intent, additional to that of the various namespace authors I'm leveraging? It's likely I may want to constrain some legal usage. If one uses separate elements to hold the associations, one gets flexibility to represent many such types of information. > The exciting use of namespaces in schemas will be when ... That's all quite true! But it doesn't require any inflexible one-to-one association of namespace URIs and schemas (or DTDs). - 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 philipnye at freenet.co.uk Thu Sep 16 11:47:19 1999 From: philipnye at freenet.co.uk (Philip Nye) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces References: <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <37E0BFB1.9CBC3018@freenet.co.uk> Tim Berners-Lee wrote: > ... > In this case, the only information which a Transitional-capable receiver > of information needs to be able to process a Strict document is > > "Strict is-a-subset-of Transition" > > This gem could be - picked up from the document itself > > The latter case is useful where you have an in-house subset of > a language but you want generic browsers to know that the > language can be processed as xHTML. and then in another post: ... > I feel that language subsets are completely well defined, by the change > of namsespace preserving validity. ... > I think that you can in fact crystalize the concept of "general language" > by specifying a set of languages which are all subsets of a given > language L. So for example if you define xHTML-all as a > language whose document content model accepts any strict or > transitional or frameset document, then you can use that > namespace for refering any xHTML document. You now have a clean > definition of validity, and well-defined compatability rules. I get the strong sense that your view is that subsetting is "good" and useful (my own feelings exactly). What I don't understand is why this obvious point is not reflected in the namespace spec. A namespace URI is the ONLY place a processor can reliably determine what language a document is using. What magic tells that processor that the unknown URI is actually a subset of a known one? Currently adding one single element type to language L creates a completely new and unrelated language. There is no reliable way for a processor to know that L is a subset of L+ other than having that knowlege hard coded into the application. Now substitute XHTML-strict, XHTML-transitional for L and L+ in the above statement then add XHTML-all and move forward a few versions and you have a mess. This is not really the fault of the XHTML group at all - it is an early manifestation of the weakness in the current namespace and schema spec. However, it is a high profile manifestation which will directly affect many people and the solution or workaround is not at all clear. This seems to be at the root of much of the controversy on this issue. Namespaces have no structure whatever. Schemata have lots of structure but no guaranteed recognition and access mechanism. Proposals for hierarchichal namespaces don't seem to meet much interest. Processing instructions are deprecated. So are external entity references. So how should we do it? regards, Philip Nye Engineering Arts 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 salvatore.usai at cgi.it Thu Sep 16 12:31:55 1999 From: salvatore.usai at cgi.it (Salvatore Usai) Date: Mon Jun 7 17:15:01 2004 Subject: importing xml document in another Message-ID: <000c01bf0037$7ced21e0$ae4db842@mi.cgi.it> Hello everyone. I hope my questions are not silly. 1) Is it possible to import a xml document from another? I verified the xml grammar, but I didn't see nothing of this...(and I wouldn't use XML Schema) 2) Is it possible for an XSL document to refer to two separate xml files (and so tags, attributes...)? Thanks for any help. Salvatore Usai -------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 16 12:30:06 1999 From: rbourret at ito.tu-darmstadt.de (Ronald Bourret) Date: Mon Jun 7 17:15:01 2004 Subject: Sybase and XML? Message-ID: <01BF003F.C86030B0@grappa.ito.tu-darmstadt.de> Ken North wrote: > Microsoft announced their plans just this week. SQL Server 7.0 does not > include the Java VM for running Java classes installed in the database. > > Sybase, Oracle, and IBM have been shipping servers that integrate a Java VM > (Sybase Adaptive Server Anywhere 6.0 and newer, IBM DB2 UDB 5.0 and newer, > and Oracle 8.1.4 and newer). Informix and IBM are in beta test with new > releases having XML extensions. Ditto Oracle 8.1.6 and Sybase ASE. Do you know of any URLs with technical details? I've poked around the IBM, Microsoft, Sybase, and Informix web sites, but can't find anything specific -- for example, a search on the Informix site turns up exactly for instances of the word XML. I'm also interested in information about ADO and XML, if you know of any. -- 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 shinichiro.hamada at toshiba.co.jp Thu Sep 16 13:22:41 1999 From: shinichiro.hamada at toshiba.co.jp (Shinichiro HAMADA) Date: Mon Jun 7 17:15:01 2004 Subject: Binary-encoding of XML for communication References: <805C62F55FFAD1118D0800805FBB428D02BBFEAB@cc20exch2.mobility.com> Message-ID: <002f01bf0036$4e6a8160$85247385@ssel.toshiba.co.jp> Hello, all. We are trying to develop a Server/Clients network system with XML. In this system, Clients read structured data and send them as XML data to a server. We estimate too heavy to communicate text-based XML and to decode/encode it to/from XML object tree. So we think it's desiable to communicate XML data as binary serialized object tree. And it's better that the binary code is open format. If I remeber correctly, such a open binary XML format are discussed among a starndard XML community. Is it true? If anyone knew anything about that, please tell me. Thank you in advance. -- Shinichiro HAMADA TOSHIBA Corp. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 16 15:13:20 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces In-Reply-To: <00f501befff9$9426c160$a60a1712@col.w3.org> References: <00f501befff9$9426c160$a60a1712@col.w3.org> Message-ID: <14304.46329.14260.551752@localhost.localdomain> Tim Berners-Lee writes: > >Tim Berners-Lee writes: > > > > > What happens when a version one program meets a version 2 document? > > > >As Tim points out, this is (or at least, should be) > >application-specific. I have omitted his summary, but I agree > >with its broad outlines. > > I'm not sure what you mean by "application -specific". If you mean > that one is entitled to do feed a document into any app program and > depending on what the program does anything can happen, and be > taken as a valid interpretation of the document, then no! No, that's not quite what I mean -- I mean a combination of "application" in the SGML sense (i.e. the XHTML Namespace or document type) and "application" in the marketing sense (i.e. a Web browser). It's difficult for a designer to anticipate all of the expected uses of a Namespace -- for example, it's quite reasonable to specify what *browsers* should do when the find an unknown element type in an HTML document, but should the same behaviour apply to (for example) to search engines and text repositories? I'd be very upset if an XML repository automatically stripped out unrecognized element boundaries when I checked in an XHTML document. > My point was that the combination of the document and the > definition of the language it is written in have a certain meaning > and that nothing must be allowed to produce a different > (contradictory or superset) meaning ostensibly from the original > document. Yes, but unless the Namespace is irrevocably tied to a very specific processing model, its definition (human-readable or otherwise) will necessarily provide only partial information. The Namespace definition says *what*, but it cannot usually say *how*. [snip] > Here you introduce a distinction between a "general language" and > a "dialect". I am not convinced that this is a well-defined concept. > I feel that language subsets are completely well defined, by the change > of namsespace preserving validity. > What is the definition of a "dialect"? The boundary between dialect and language is not crisp. I am absolutely certain that C++ and HTML are different languages, and I am fairly certain that HTML 4.0 transitional and HTML 4.0 strict are different dialects of the same language, but I don't know where to draw the line in the middle: are C and C++ (for example) different dialects or different languages? As with natural language, the best test is interoperability, even if the results are not always conclusive (as in my C/C++ example). My Web browser works more-or-less properly with HTML 2.0, HTML 3.2, HTML 4.0, and XHTML, without knowing in advance which of those it's going to see (all it gets is the MIME type text/html) -- for me, that's proof that they are all dialects of the same language. Certainly, a multi-billion dollar industry is based on that assumption. > To me, nesting a level of naming of "version" inside a "general" > language suggets that nothing at all is really known about the > general langauge. That's obviously a deliberate overstatement -- Netscape and MSIE work most of the time, even though they work at what I'm calling the language level; we're simply dealing with a 20,000-foot view rather than a 2,000-foot view. It's not a perfect analogy, but take a look at a MIME type like text/html or image/jpeg -- it is often possible to perform useful sorts of processing on all image/* or text/* resources. Two-level hierarchies are well-proven and well-deployed, and in the case of a language (Namespace URI) and dialect (version) pair, the two levels will provide much more precise information than a MIME type. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at docuverse.com Thu Sep 16 15:10:40 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:01 2004 Subject: Binary-encoding of XML for communication In-Reply-To: <002f01bf0036$4e6a8160$85247385@ssel.toshiba.co.jp> Message-ID: <000001bf0045$664f9c20$15a8fea9@w21tp> Shinichiro, Take a look at WAP at www.wapforum.org. It contains a spec for binary XML. I am not sure if it has been updated to support namespaces but it looks fairly good although I don't think it is widely supported outside of WAP. Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 16 15:26:53 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces In-Reply-To: <37E0B481.E5CA7803@pacbell.net> References: <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <4.1.19990916092628.02454100@mail.webgeek.com> At 02:12 AM 9/16/99 -0700, David Brownell wrote: >> The exciting use of namespaces in schemas will be when ... > >That's all quite true! But it doesn't require any inflexible >one-to-one association of namespace URIs and schemas (or DTDs). I've yet to see anyone assert that it must. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Sep 16 15:37:18 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces In-Reply-To: <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <4.0.1.19990915193718.00f854e0@216.27.10.33> At 04:41 PM 9/15/99 -0400, Tim Berners-Lee wrote: >The namespaces spec was adamant that you could use namespaces >without having to dereference the namespace URI. >However, as we define languages for talking about languages >(XML and RDF schemas for example, even style sheets) >the document corresponding to the namespace URI becomes >the place where the namespace-author can put *definitive* >information about the intent of the namespace. >And this is not mandatory - but is very useful! To me at least, this is at the heart of the technical aspects of this issue. In some cases, 'not dereferencing the namespace URI' is good - not every processor is going to care what, if anything, is there. If we start to treat this as "You don't have to dereference it, but you might find something interesting there", then we have to start talking about what goes there. The list of options, presented above, includes two types of schemas plus style sheets, and there are _many_ more possibilities. This approach is certainly plausible - it might match up with Jon Bosak's earlier "provides for the creation of an XML Packaging WG when work on the other specifications reaches a point where resources can be devoted to it" - but it would help a lot to know what will be involved in that project and how those dependencies affect current work. Based on what's currently published, there aren't enough resources to make this approach believeable, mostly because namespaces are described only as identifiers. If namespace URIs are only identifiers, the approach described above doesn't make sense. If in fact namespace URIs will point to something, preferably something machine-readable, it begins to make more sense. >For example, you can run an xHTML document though any >DTD you like if it suits your purposes, but if you want to >check whether it is valid xHTML then you should use >the xHTML schema which corresponds to the namespace URI. >You might of course have a local copy and not actually >need to go onto the net to us live HTTP. That sounds fine, but the DOCTYPE declaration already provides that functionality, and XHTML 1.0 doesn't make clear any need for functionality beyond that type of validation. Namespaces and XML 1.0 validation, as I've been reminded repeatedly on this list, have no necessary connection. Future schema validation might make more sense, but we're missing some key mechanisms.... >The exciting use of namespaces in schemas will be when we >have schema documents which contain the syntactic >constraints in xml-schema language, but themselves >use other namespaces to come to express the >entity-relationship model of data (rdf-schema), >legally appropriate presentation (link to style sheet), >financial implication (link to mapping to FSTC >echecks or whatever). The functionality which we >will be able to build into new languages will grow >as the richness of languages to which we can map. Is this all going into the schemas? Or are we going to be building more complete tools for describing document types by assembling lots of parts? I hope (and it sounds like) the latter, but it isn't clear how we're going to get there. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 shinichiro.hamada at toshiba.co.jp Thu Sep 16 16:00:15 1999 From: shinichiro.hamada at toshiba.co.jp (Shinichiro HAMADA) Date: Mon Jun 7 17:15:01 2004 Subject: Binary-encoding of XML for communication References: <000001bf0045$664f9c20$15a8fea9@w21tp> Message-ID: <004601bf004c$47284840$85247385@ssel.toshiba.co.jp> Thanks, Mr. Don Park and Mr. BlackBurn. I will check out WAP. If there are any other standards, please advice them me. I will compare them. | I had a project where we needed to send 50MB of data per second | between systems. We decided to use RIFF as this was very simple and | very quick to parse. Microsoft uses RIFF in WAV and AVI files. In our project, communication traffic won't be so heavy as yours. We seek system openness and easiness to change data structure with open data format, XML. | Converting XML to binary negates the advantage of XML. And, as Mr.BlackBum say, such an approach to binarize XML may make the openness XML has. I think It depends on the saturation and standard level of the coding. I will care about it. -- Shinichiro HAMADA TOSHIBA Corp. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shinichiro.hamada at toshiba.co.jp Thu Sep 16 16:33:17 1999 From: shinichiro.hamada at toshiba.co.jp (Shinichiro HAMADA) Date: Mon Jun 7 17:15:01 2004 Subject: Binary-encoding of XML for communication References: <000001bf0045$664f9c20$15a8fea9@w21tp> <004601bf004c$47284840$85247385@ssel.toshiba.co.jp> Message-ID: <00a601bf0050$df3d8d80$85247385@ssel.toshiba.co.jp> I'm sorry. I had mistaken to write. In my mail: | | Converting XML to binary negates the advantage of XML. | | And, as Mr.BlackBum say, such an approach to binarize XML may make the | openness XML has. I think It depends on the saturation and standard level of | the coding. I will care about it. (What I wanted to write is..) And, as Mr.BlackBum say, such an approach to binarize XML may make lose the openness from XML. I think It depends on the saturation and standard level of the coding. I will care about it. -- Shinichiro HAMADA TOSHIBA Corp. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Thu Sep 16 17:28:14 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces Message-ID: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> With all due respect to Simon St. Laurent, I believe that Tim Berners-Lee was correctly precise when he wrote "the document corresponding to the namespace URI becomes the place where the namespace-author can put *definitive* information about the intent of the namespace." (Emphasis in the original). While there are many processes that can be applied to a document, and correspondingly many specifications of those processes, there can be, for a given term in a namespace, at most one correct *definition*. ... As background, and to help make clear some of the thinking on this subject, the following is the text of a message I posted a few weeks ago to the XML Plenary: [Someone] wrote that, although a schema may be somehow associated with a namespace, the "meaning" of markup will be determined in a number of ways such as style sheets, or procedural code, or maybe the schema. I believe this understates the importance of the schema. A schema makes a contribution to the Infoset. It does this by providing default values and -- under some recent proposals -- by indicating type information, which may be considered also a form of default value. Elements defined by a schema, when used in an instance document in a validating processor, will have these default values available, and this fact is pertinent to the author of the document. This means that an element is incompletely read if the schema for it is not read. Unlike the various processings that may or may not be applied to a document, a cited schema is part of the information conveyed by the document. When a namespace has an associated schema, that schema is part of the input to any further complete processing of the referencing document. A schema is not on par with other forms of processing that might be specified, say by style sheets or procedural code. It is prior to other processing. Further, I expect that one can argue that a namespace is an abstract concept denoting a set of names, and this argument is true, so far as it goes, but it does not go far enough: For specific processing, to make use of a namespace one needs to know what names are in it, which are not, and what the meaning is for each name. Such information may be obtained by various means such a by reading a schema, by reading a text document, or from conversations with other people, but in all cases the meaning is not created by the processing code, the meaning informed the programmer who wrote the code. For a namespace to be reliably useful, there must be a document defining its contents and their meaning. A schema is, for many namespaces, that 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 ricko at allette.com.au Thu Sep 16 17:36:01 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:01 2004 Subject: C/C++ DOM implementation using expat Message-ID: <001801bf005a$0c4c3200$1ff96d8c@NT.JELLIFFE.COM.AU> From: Hutchison, Nigel >Is anyone working on a C/C++ DOM implementation using expat? If anyone is working on a C DOM implementation using expat, there is a C interface definition for DOM (.h) available at http://www.ascc.net/~ricko/src/dom_interface.h which they might find convenient to use (contributions and suggestions welcome). 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 dhunter at Mobility.com Thu Sep 16 17:45:10 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFEC5@cc20exch2.mobility.com> From: Tim Berners-Lee [mailto:timbl@w3.org] Sent: Wednesday, September 15, 1999 4:41 PM > It is important to realize that these are *different* languages. > If you take a Transition document and re-label it as a strict document > it can be invalid. Invalid by specification, whether > represented by English > or DTD or schema. In these kinds of debates I've noticed a tendency for people to say "I think this is the heart of the matter", so I'll give it a shot too. ;-) Right now, the vast majority of people in the world consider HTML to be one language. Even though HTML 4 defines three variants of the language, ask anyone on the street, or anyone in web development, and they'll tell you that HTML is HTML is HTML. Even though there is an HTML 3 and an HTML 2 and an HTML 4, people still consider it one language. (When I say "vast majority", I mean that I'm betting the number of people who don't consider HTML to be one language would be statistically insignificant.) If the W3C is going to consider XHTML not to be an XML vocabulary, but a "family" of XML vocabularies, then preconceived notions will have to be changed. Drastically. That is, the world will have to be told "No, you're mistaken, HTML is not one language". Just look at the reactions on this mailing list: declaring that XHTML is [going to be] three languages is producing a considerable stir, with reactions ranging from surprise to indignation to anger. > The namespaces spec was adamant that you could use namespaces > without having to dereference the namespace URI. > However, as we define languages for talking about languages > (XML and RDF schemas for example, even style sheets) > the document corresponding to the namespace URI becomes > the place where the namespace-author can put *definitive* > information about the intent of the namespace. > And this is not mandatory - but is very useful! To say that this is "not mandatory" may be a bit of an understatement. As Jon Bosak stated in an earlier email (archived at http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0385.html): >The URI in a namespace declaration may or may not refer >to an actual resource that can be retrieved by a computer; >if it does, the resource so identified may or may not have >useful things to tell us about things labeled with the names >associated with the URI. The statement in the Namespaces >Recommendation that "It is not a goal that it [the namespace >URI] be directly usable for retrieval of a schema (if any >exists)" is not mere rhetorical fluff but rather represents >a concrete position taken by the XML Working Group after months >of debate and in direct opposition to an equally concrete point >of view to the contrary. I agree with Mr. Bosak's position very strongly. As soon as you start putting "things" at the location specified by a namespace URI, you're going to have to start defining what kinds of "things" to put there. (Schemas? DTDs? Stylesheets? (XSL, CSS...) ReadMe documents? (text? HTML? XHTML?) All of these have been suggested on this list.) (Not to mention that the namespace URI can no longer be a URN, but must be a URL. Which also caused quite the debate of its own on this list a few months ago...) If the W3C does decide that they want to start putting "things" there, it also has to be optional as to whether or not the application involved goes to retrieve it. (If I develop an Intranet application, I want to be able to use XHTML without clients having to run out to the W3C site regularly. Ditto for any other XML vocabularies which are defined going forward, from the W3C or anyone else.) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 16 17:59:53 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:01 2004 Subject: Another look at namespaces In-Reply-To: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> Message-ID: <199909161602.MAA09307@hesketh.net> At 08:30 AM 9/16/99 -0700, Andrew Layman wrote: >[Someone] wrote that, although a schema may be somehow associated with a >namespace, the "meaning" of markup will be determined in a number of ways >such as style sheets, or procedural code, or maybe the schema. I believe >this understates the importance of the schema. A schema makes a >contribution to the Infoset. It does this by providing default values and -- >under some recent proposals -- by indicating type information, which may be >considered also a form of default value. Elements defined by a schema, when >used in an instance document in a validating processor, will have these >default values available, and this fact is pertinent to the author of the >document. This means that an element is incompletely read if the schema for >it is not read. With all due respect to Andrew Layman, I find this to be a gross overvaluation of schemas, and a substantial contrast with both the XML 1.0 approach (which doesn't require validation) and with Tim Berners-Lee's comments, which included: >However, as we define languages for talking about languages >(XML and RDF schemas for example, even style sheets) >the document corresponding to the namespace URI becomes >the place where the namespace-author can put *definitive* >information about the intent of the namespace. This seems to leave the possibility _wide_ open that something other than a schema is lurking at the URI identified by the namespace. At the very least, there are multiple schema possibilities - XML and RDF, as noted above, and possibly even DTDs. Schema information should be an important _component_ of that information, certainly, but I see no reason why it should be the only, or indeed primary, component. For an example of a different possibility, you might explore my XPDL proposal at http://purl.oclc.org/NET/xpdl. Schema information, style information, and documentation are combined to provide a description of a document class. >For a namespace to be reliably useful, there must be a document >defining its contents and their meaning. A schema is, for many namespaces, >that document. An interesting opinion, to be sure, but not a claim made directly by the Namespaces in XML recommendation, and not necessarily a hard-and-fast rule. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 16 18:08:01 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:02 2004 Subject: Another look at namespaces In-Reply-To: <805C62F55FFAD1118D0800805FBB428D02BBFEC5@cc20exch2.mobilit y.com> Message-ID: <4.1.19990916120701.0249cb80@mail.webgeek.com> At 11:43 AM 9/16/99 -0400, Hunter, David wrote: >If the W3C does decide that they want to start putting "things" there, it >also has to be optional as to whether or not the application involved goes >to retrieve it. And that's what he said: > And this is not mandatory - but is very useful! >(If I develop an Intranet application, I want to be able to >use XHTML without clients having to run out to the W3C site regularly. >Ditto for any other XML vocabularies which are defined going forward, from >the W3C or anyone else.) It also should be noted that there's nothing precluding a cache'd copy of that "thing" for that Intranet application. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From spreitze at parc.xerox.com Thu Sep 16 18:11:56 1999 From: spreitze at parc.xerox.com (Mike Spreitzer) Date: Mon Jun 7 17:15:02 2004 Subject: code generation from XML datatype definitions: anyone interested? In-Reply-To: <00ad01bf000e$99339560$0300000a@cygnus.uwa.edu.au> Message-ID: <001101bf005e$8295bb80$27d1000d@deimos.parc.xerox.com> Are you asking for something more/different than the "XML Data Binding" spec (JSR-000031) that's just getting started in the Java Community Process (http://java.sun.com/aboutJava/communityprocess/index.html)? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wunder at infoseek.com Thu Sep 16 18:14:20 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:15:02 2004 Subject: Another look at namespaces In-Reply-To: <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com> At 04:41 PM 9/15/99 -0400, Tim Berners-Lee wrote: > > [...] the HTML 4.0 spec defined three, and XHTML was required to be >as direct a mapping from HTML 4.0 to XML as possible. This is a rationale. Including this with the recent draft would have saved us all a lot of e-mail traffic. Rationales are critically important in specs. I read them first. wunder -- Walter R. Underwood Staff Engineer, Infoseek Corp. wunder@infoseek.com http://software.infoseek.com/cce/ (my product) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From DuCharmR at moodys.com Thu Sep 16 18:16:00 1999 From: DuCharmR at moodys.com (DuCharme, Robert) Date: Mon Jun 7 17:15:02 2004 Subject: importing xml document in another Message-ID: <01BA10F0CD20D3119B2400805FD40F9F277DB7@MDYNYCMSX1> >1) Is it possible to import a xml document from another? The use of external general entities allows one document to "include" the contents of another as if it were part of the including document. >2) Is it possible for an XSL document to refer to two >separate xml files (and so tags, attributes...)? In general, an XSL document is designed to be applied to all the documents conforming to a particular document type, i.e. to a class of documents. (By the way, the xml-l list is better for basic XML issues; xml-dev concentrates on more advanced and theoretical stuff. See http://www.oasis-open.org/cover/lists.html#XML-L for more on xml-l.) Bob DuCharme www.snee.com/bob see www.snee.com/bob/xmlann for "XML: The Annotated Specification" from Prentice Hall. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dhunter at Mobility.com Thu Sep 16 18:17:21 1999 From: dhunter at Mobility.com (Hunter, David) Date: Mon Jun 7 17:15:02 2004 Subject: Another look at namespaces Message-ID: <805C62F55FFAD1118D0800805FBB428D02BBFEC6@cc20exch2.mobility.com> From: Ann Navarro [mailto:ann@webgeek.com] Sent: Thursday, September 16, 1999 12:08 PM > >If the W3C does decide that they want to start putting > "things" there, it > >also has to be optional as to whether or not the application > involved goes > >to retrieve it. > > And that's what he said: > > > And this is not mandatory - but is very useful! This requires some clarification, then. When I read Mr. Berners-Lee's first post, I read him to be saying that "this is not mandatory from the namespaces spec, but could be used by specific XML vocabularies such as XHTML". That is, "not every XML vocabulary has to put something at the namespace URI, but the XHTML vocabulary could decide that it will". In which case, I would still state that it should not be mandatory to retrieve that "thing". But, if it's not mandatory to retrieve it, then it's up to the application to decide how to process that vocabulary. This could be by a cached copy of the Schema/DTD, or by a hard-coded copy. (I assume that the latter is what most web browsers do today.) And if the application is already deciding how to process the vocabulary, then it's not much of a stretch to have the application decide how to deal with strict vs. frameset vs...... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 16 18:27:01 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:02 2004 Subject: Another look at namespaces In-Reply-To: <199909161602.MAA09307@hesketh.net> References: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> Message-ID: <4.1.19990916122123.0248fbf0@mail.webgeek.com> At 12:06 PM 9/16/99 -0400, Simon St.Laurent wrote: >At 08:30 AM 9/16/99 -0700, Andrew Layman wrote: >>[Someone] wrote that, although a schema may be somehow associated with a >>namespace, the "meaning" of markup will be determined in a number of ways >>such as style sheets, or procedural code, or maybe the schema. I believe >>this understates the importance of the schema. A schema makes a >>contribution to the Infoset. It does this by providing default values and -- >>under some recent proposals -- by indicating type information, which may be >>considered also a form of default value. Elements defined by a schema, when >>used in an instance document in a validating processor, will have these >>default values available, and this fact is pertinent to the author of the >>document. This means that an element is incompletely read if the schema for >>it is not read. > >With all due respect to Andrew Layman, I find this to be a gross >overvaluation of schemas, and a substantial contrast with both the XML 1.0 >approach (which doesn't require validation) and with Tim Berners-Lee's >comments, which included: > >>However, as we define languages for talking about languages >>(XML and RDF schemas for example, even style sheets) >>the document corresponding to the namespace URI becomes >>the place where the namespace-author can put *definitive* >>information about the intent of the namespace. > >This seems to leave the possibility _wide_ open that something other than a >schema is lurking at the URI identified by the namespace. At the very >least, there are multiple schema possibilities - XML and RDF, as noted >above, and possibly even DTDs. Perhaps we need to step back and take off some of the "black and white" blinders that seem to be on here (no personal slight to Simon intended). I don't read Andrew's comments as saying "schemas and only schemas" can do what he proposes. Therefore nothing in that conflicts with Tim's assertions. It's very clear that additional functionality is desired and needed (as I suggested some weeks ago now (an unfilled need)), just how that may come about is yet to be determined. Nothing in the current proposals being debated sets functionality. Instead, it provides granularity in namespaces making a nod toward the possibility of additional functionality. It may turn out to be unnecessary, but as I've said before, I believe it easier to remove that granularity later (or simply ignore it), than it will be to put it back in at some later date. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Thu Sep 16 18:37:10 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:15:02 2004 Subject: Another look at namespaces Message-ID: <3.0.32.19990916093902.00c52780@pop.intergate.bc.ca> At 08:30 AM 9/16/99 -0700, Andrew Layman wrote: >With all due respect to Simon St. Laurent, I believe that Tim Berners-Lee >was correctly precise when he wrote "the document corresponding to the >namespace URI becomes >the place where the namespace-author can put *definitive* >information about the intent of the namespace." I and many others disagree, for reasons best expressed in Jon Bosak's summary of the issues. Among other things, I don't believe that most interesting namespaces *have* definitive information, but have semantics that are communicated via some messy combination of schemas, stylesheets, prose documentation, and running code. >While there are many processes that can be applied to a document, and >correspondingly many specifications of those processes, there can be, for a >given term in a namespace, at most one correct *definition*. I disagree, I think this is a strong and surprising claim, and I would like to see some real-world supporting evidence. >As background, and to help make clear some of the thinking on this subject, >the following is the text of a message I posted a few weeks ago to the XML >Plenary: As further background, here is my follow-up, from the plenary: At 04:01 PM 9/8/99 -0700, Andrew Layman wrote: >Tim Bray wrote that, although a schema may be somehow associated with a >namespace, the "meaning" of markup will be determined in a number of ways >such as style sheets, or procedural code, or maybe the schema. I believe >this understates the importance of the schema. A schema makes a >contribution to the Infoset. It does this by providing default values and -- >under some recent proposals -- by indicating type information, which may be >considered also a form of default value. Elements defined by a schema, when >used in an instance document in a validating processor, will have these >default values available, and this fact is pertinent to the author of the >document. This means that an element is incompletely read if the schema for >it is not read. Well, to some extent both Andrew and I are guilty of guessing-the-future, because this discussion is only meaningful in the context of the existence of a new, more ambitious, kind of schema. Andrew's claim (I suspect he'd agree) is certainly not true in the context of DTD's. Now, let us remember that one of the big selling points of XML is that it allows you to process a document standalone without recourse to *any* external resources, and I suspect that this style of processing will remain very important regardless of how ambitious schemas get. In particular, the class of XML apps that need to consult the DTD to do what they do is vanishingly small - the only ones I know of are authoring facilities. So, the prediction here that "an element is incompletely read if the schema for it is not read" represents a HUGE shift in the central XML processing paradigm. Not that I'm claiming it's wrong - but it's also not self- evidently true on the basis of the evidence before us. >Unlike the various processings that may or may not be applied to a document, >a cited schema is part of the information conveyed by the document. When a >namespace has an associated schema, that schema is part of the input to any >further complete processing of the referencing document. This is an assertion with which I completely disagree, and which really needs some supporting evidence. Right at the moment the overwhelming paradigm is that once an application *recognizes* which tag-set is in play, most of the business logic is then more or less hard-wired into the software. I think we can all agree that less hardwiring and more rule-driven processing is a good thing, but getting there from here is a huge task, and one in which the IT professions have been engaged throughout my embarrassingly lengthy career in this profession, and we're not there yet. "Any further complete processing?" Wow. That's a different universe. Unless you mean something very strong by the word "complete" here that would not be expected to apply in the majority of application scenarios. >A schema is not on >par with other forms of processing that might be specified, say by style >sheets or procedural code. It is prior to other processing. Once again, that's an assertion that is empirically not true in the context of today's technology. I accept the possibility that it might become increasingly true a couple of technology generations from now - but it is certainly not a foregone conclusion. And I remain convinced that there will be a hugely important class of lightweight performance-critical applications that just do not have bandwidth to do schema processing at run-time. >For specific processing, to make use of a >namespace one needs to know what names are in it, which are not, and what >the meaning is for each name. Such information may be obtained by various >means such a by reading a schema, by reading a text document, or from >conversations with other people, but in all cases the meaning is not created >by the processing code, the meaning informed the programmer who wrote the >code. For a namespace to be reliably useful, there must be a document >defining its contents and their meaning. A schema is, for many namespaces, >that document. Agreed absolutely. But the current flow is that the *programmer* comes to understand the meaning, by reading the prose documentation and the schema, and then encodes that knowledge, along with a bunch of contextually dependent business rules, in software. This paradigm actually works reasonably well at the moment. So concretely, what are we arguing over? I *think* we're arguing whether or not it's a good idea to declare that schemas are special enough that it's a good idea to use a namespace URI to fetch them. My position is that it would indeed be desirable to be able to use the namespace URI to fetch schemas, but that there are many other things the fetching of which is of at least comparable importance: human-readable documentation, stylesheets, java classes, schemas in a different dialect. (For example, once XML schemas become available, will Microsoft tell all its customers that are now using the variant-XML-data-schemas that come with IE5 to discard them, and instantly drop support in the software? I doubt it. What then does the namespace URI point at?) To do these things effectively, we need a level of indirection and a place to put some metadata concerning what associated resources are available. Which is why I keep coming back to the desirability of a packaging framework for all these things. The development of which is in the continued-XML-work package currently before the W3C membership. Hmm, is it being proposed that the schema should do double duty as a packaging document as well? This is conceivable, we'd need to think whether it represents optimal design, but there's nothing impossible on the face of 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 simonstl at simonstl.com Thu Sep 16 18:35:59 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:02 2004 Subject: Another look at namespaces In-Reply-To: <4.1.19990916122123.0248fbf0@mail.webgeek.com> References: <199909161602.MAA09307@hesketh.net> <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> Message-ID: <199909161638.MAA10671@hesketh.net> At 12:27 PM 9/16/99 -0400, Ann Navarro wrote: >I don't read Andrew's comments as saying "schemas and only schemas" can do >what he proposes. Therefore nothing in that conflicts with Tim's assertions. Er... no. Perhaps this needs a clarification from Andrew, as that (on an additional re-reading) still sounds exactly like what he was saying. Schemas are 'prior to all other processing'. While the last paragraph at least opens the term 'schema' up to include more than just XML Schemas per the latest W3C proposals, it remains incredibly schema-centric in a way that I don't believe harmonizes well with Tim's original assertion. >It's very clear that additional functionality is desired and needed (as I >suggested some weeks ago now (an unfilled need)), just how that may come >about is yet to be determined. This conversation is illustrating quite nicely just how many 'unfilled needs' there are, and how many differing opinions there are on how to fill them. >Nothing in the current proposals being debated sets functionality. Instead, >it provides granularity in namespaces making a nod toward the possibility >of additional functionality. >It may turn out to be unnecessary, but as I've said before, I believe it >easier to remove that granularity later (or simply ignore it), than it will >be to put it back in at some later date. I still find this argument unconvincing. One schema per namespace appears to be what you're arguing for here, and I don't see that as a fundamental characteristic of either schemas or namespaces, much less the fairly weak differentiation between the different 'brands' of HTML. It may be that the tools we have are inadequate. I don't think, however, that we've yet reached the conclusion that three namespaces will let us do better with either the tools we have today or the tools we may have tomorrow. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 Thu Sep 16 18:37:18 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:15:02 2004 Subject: Another look at namespaces References: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> Message-ID: <37E11D53.FC67553B@mecomnet.de> Andrew Layman wrote: > > With all due respect to Simon St. Laurent, I believe that Tim Berners-Lee > was correctly precise when he wrote "the document corresponding to the > namespace URI becomes > the place where the namespace-author can put *definitive* > information about the intent of the namespace." (Emphasis in the original). > These remarks broadened the intent of "namespaces" to an extent where that are no longer useful. It states and implies that they are to be used for things for which they are, and will remain, ill suited. The initial, cited, statement begs the question. If, as soon as one identifies a set of names, one is required to commit to an intent, then one is not referring to a namespace - neither in general usage nor in the specifics of the xml-related recommendation. One is no longer concerned with an infinite set of potential names, but with a finite set of specific names and their associated meanings. Which is not a namespace. > While there are many processes that can be applied to a document, and > correspondingly many specifications of those processes, there can be, for a > given term in a namespace, at most one correct *definition*. > This claim bears further explanation. I had, until now, understood that the definition for a namespace was, in effect, an injection function which maps local parts to universal names, which means the definiton for the name is the argument to the function, but I don't think this is what "*definition*" was intended to mean here. > ... > > As background, and to help make clear some of the thinking on this subject, > the following is the text of a message I posted a few weeks ago to the XML > Plenary: > > ... > > Further, I expect that one can argue that a namespace is an abstract concept > denoting a set of names, and this argument is true, so far as it goes, but > it does not go far enough: For specific processing, to make use of a > namespace one needs to know what names are in it, which are not, and what > the meaning is for each name. In the environment for which namespaces are intended, this formulation is backwards. One needs to know which namespace a name is in, and, with respect to a given process - or even just with respect to a given document, which meaning is associated with that name-in-that-namespace. The original phrasing imputes a singular, all-encompassing meaning to any given name. This is short-sighted. It is also not what namespaces are specified to do. The modified phrasing restricts the interpretation to uniquely identifying an encoded entity. Which is the end which namespaces are specified to serve. Despite that, as my previous contributions to this list well demonstrate, I'm certainly not the most reliable just of the recommendations authors' intent, no matter how often i reread section 1 of the recommendation, I can't impute an intent to encompass "what the meaning is for each name." "Allow a process to reliably determine the meaning for a given name", yes. THose are not the same thing. > Such information may be obtained by various > means such a by reading a schema, by reading a text document, or from > conversations with other people, but in all cases the meaning is not created > by the processing code, the meaning informed the programmer who wrote the > code. For a namespace to be reliably useful, there must be a document > defining its contents and their meaning. A schema is, for many namespaces, > that document. This does not concern the reliability of the namespace, but of the schema. As above it is more correct if reversed: For a schema to be reliably useful, it must define its namespaces. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Thu Sep 16 18:39:39 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:15:02 2004 Subject: code generation from XML datatype definitions: anyone interested? References: <001101bf005e$8295bb80$27d1000d@deimos.parc.xerox.com> Message-ID: <022d01bf0060$d9a828c0$0300000a@cygnus.uwa.edu.au> ----- Original Message ----- From: Mike Spreitzer > Are you asking for something more/different than the "XML Data Binding" > spec (JSR-000031) that's just getting started in the Java Community Process > (http://java.sun.com/aboutJava/communityprocess/index.html)? I suspect more. Does the XML Data Binding spec address calculation of attributes on the basic of other (possibly inherited) attributes? I would imagine building on that spec. Thanks for reminding me of it. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net Ceci n'est pas une pipe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 16 18:43:09 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:02 2004 Subject: Another look at namespaces In-Reply-To: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com> References: <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <4.1.19990916123524.024ab640@mail.webgeek.com> At 09:16 AM 9/16/99 -0700, Walter Underwood wrote: >At 04:41 PM 9/15/99 -0400, Tim Berners-Lee wrote: >> >> [...] the HTML 4.0 spec defined three, and XHTML was required to be >>as direct a mapping from HTML 4.0 to XML as possible. > >This is a rationale. Including this with the recent draft >would have saved us all a lot of e-mail traffic. This was said way back at the beginning (August 29) http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Aug-1999/0370.html Quoting myself "No, we've not confused them. We happen to have three 'flavors' of XHTML 1.0 (the first deliverable from the XHTML project, not the end sum of our work), that essentially map to the three flavors of HTML 4.0." But apparently nobody wanted to hear it. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 16 18:47:44 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:02 2004 Subject: Another look at namespaces In-Reply-To: <199909161638.MAA10671@hesketh.net> References: <4.1.19990916122123.0248fbf0@mail.webgeek.com> <199909161602.MAA09307@hesketh.net> <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> Message-ID: <4.1.19990916124455.024a9eb0@mail.webgeek.com> At 12:42 PM 9/16/99 -0400, Simon St.Laurent wrote: >At 12:27 PM 9/16/99 -0400, Ann Navarro wrote: >>Nothing in the current proposals being debated sets functionality. Instead, >>it provides granularity in namespaces making a nod toward the possibility >>of additional functionality. >>It may turn out to be unnecessary, but as I've said before, I believe it >>easier to remove that granularity later (or simply ignore it), than it will >>be to put it back in at some later date. > >I still find this argument unconvincing. One schema per namespace appears >to be what you're arguing for here No. I'm arguing that each flavor of XHTML is sufficiently different (idiom, dialect, what have you) that it deserves a different namespace. Information about those namespaces may, if the W3C chooses to follow this path, be obtained from a schema, DTD, or other data source at the end of that URI. >It may be that the tools we have are inadequate. I don't think, however, >that we've yet reached the conclusion that three namespaces will let us do >better with either the tools we have today or the tools we may have tomorrow. Nor have we reached the conclusion that they won't. I'd rather provide the ability now than have to try and add it back in. It should also be noted that these is not the *only* use case being considered (see Steven's summary). Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Sep 16 18:57:16 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:03 2004 Subject: Another look at namespaces In-Reply-To: <4.1.19990916124455.024a9eb0@mail.webgeek.com> References: <199909161638.MAA10671@hesketh.net> <4.1.19990916122123.0248fbf0@mail.webgeek.com> <199909161602.MAA09307@hesketh.net> <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> Message-ID: <199909161659.MAA11511@hesketh.net> At 12:48 PM 9/16/99 -0400, Ann Navarro wrote: >At 12:42 PM 9/16/99 -0400, Simon St.Laurent wrote: >>I still find this argument unconvincing. One schema per namespace appears >>to be what you're arguing for here > >No. > >I'm arguing that each flavor of XHTML is sufficiently different (idiom, >dialect, what have you) that it deserves a different namespace. And I'm arguing that those flavors are overlapping, insufficiently different, and that the _only_ thing that distinguishes them is a schema. That brings us back to one namespace per schema. Is there _anything_ else besides their names that distinguishes these flavors? >Information about those namespaces may, if the W3C chooses to follow this >path, be obtained from a schema, DTD, or other data source at the end of >that URI. Or, since this is an XML 1.0 application, you could just read the DOCTYPE declaration and not try to map namespace URIs to places where the W3C might (but won't comment on publicly at present) want to go someday. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Sep 16 18:59:25 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:03 2004 Subject: Another look at namespaces In-Reply-To: <4.1.19990916123524.024ab640@mail.webgeek.com> References: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com> <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <199909161702.NAA11855@hesketh.net> At 12:44 PM 9/16/99 -0400, Ann Navarro wrote: >At 09:16 AM 9/16/99 -0700, Walter Underwood wrote: >>At 04:41 PM 9/15/99 -0400, Tim Berners-Lee wrote: >>> >>> [...] the HTML 4.0 spec defined three, and XHTML was required to be >>>as direct a mapping from HTML 4.0 to XML as possible. >> >>This is a rationale. Including this with the recent draft >>would have saved us all a lot of e-mail traffic. > >This was said way back at the beginning (August 29) > >http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Aug-1999/0370.html > >Quoting myself "No, we've not confused them. We happen to have three >'flavors' of XHTML 1.0 >(the first deliverable from the XHTML project, not the end sum of our >work), that essentially map to the three flavors of HTML 4.0." > >But apparently nobody wanted to hear it. Actually, I think what was missing was the rationale for: Three flavors of XHTML -> Three namespaces for XHTML I don't think anyone's argued hard that three flavors of DTDs was a horrible thing, though I know many of us (including, perhaps even Ann) would just as soon reduce it to one. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 elm at arbortext.com Thu Sep 16 19:03:05 1999 From: elm at arbortext.com (Eve L. Maler) Date: Mon Jun 7 17:15:03 2004 Subject: Another look at namespaces In-Reply-To: <4.1.19990916123524.024ab640@mail.webgeek.com> References: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com> <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <4.2.0.58.19990916125508.00b3d550@pophost.arbortext.com> Not to pick nits, but the August 29 statement just observed a correlation; when I first read it, I didn't take it to be providing an actual reason for the decision. The "as direct a mapping as possible" language does indeed give insight into the decision to go with a one-to-one DTD/NS mapping, though I think that the confusion reigning about the purpose of NSs puts the rationale on shaky foundations not of the WG's making. Back to lurking, Eve At 12:44 PM 9/16/99 -0400, Ann Navarro wrote: >At 09:16 AM 9/16/99 -0700, Walter Underwood wrote: > >At 04:41 PM 9/15/99 -0400, Tim Berners-Lee wrote: > >> > >> [...] the HTML 4.0 spec defined three, and XHTML was required to be > >>as direct a mapping from HTML 4.0 to XML as possible. > > > >This is a rationale. Including this with the recent draft > >would have saved us all a lot of e-mail traffic. > >This was said way back at the beginning (August 29) > >http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Aug-1999/0370.html > >Quoting myself "No, we've not confused them. We happen to have three >'flavors' of XHTML 1.0 >(the first deliverable from the XHTML project, not the end sum of our >work), that essentially map to the three flavors of HTML 4.0." > > >But apparently nobody wanted to hear it. > >Ann > >--- > >Author of Effective Web Design: Master the Essentials >Coming in September --- Mastering XML > >Founder, WebGeek Communications http://www.webgeek.com >Vice President-Finance, HTML Writers Guild http://www.hwg.org >Director, HWG Online Education http://www.hwg.org/services/classes > > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on >CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Sep 16 19:06:08 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:03 2004 Subject: Another look at namespaces Message-ID: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU> From: Andrew Layman With all due respect to Simon St. Laurent, I believe that Tim Berners-Lee >was correctly precise when he wrote "the document corresponding to the >namespace URI becomes >the place where the namespace-author can put *definitive* >information about the intent of the namespace." (Emphasis in the original). The only information that properly belongs in a namespace is a list of names. All other information, however convenient, is not namespace information but something else: what is this "intent" business? There is no mention of "intent" in the namespaces spec that I recall, quite the opposite. The fundamental justification for namespace is to be free from intent. There is no W3C method to define a namespace as list of names. There is no W3C method to declare which schema should be used, akin to the stylesheet declaration. In the absense of these, of course people will try to turn namespaces URIs into schema declaration URLS. The W3C should provide a proper way to define namespaces (as simple lists) and a way to declare schemas. (Furthermore, the idea of a namespace-author being in some way the controller of the resource for a schema is bad; a schema identifier (or a namespace list) should be identified using the URI equivalent of a Formal Public Identifier: I can ask some service to provide me that schema (or that namespace list) in any format that anyone has chosen to make available.) >While there are many processes that can be applied to a document, and >correspondingly many specifications of those processes, there can be, for a >given term in a namespace, at most one correct *definition*. Again, the only declaration information that is proper to a namespace is a list of names. A content model is a schema, and nothing to do with names in a namespace, in particular. >[Someone] wrote that, although a schema may be somehow associated with a Me among others >namespace, the "meaning" of markup will be determined in a number of ways >such as style sheets, or procedural code, or maybe the schema. I believe >this understates the importance of the schema. A schema makes a >contribution to the Infoset. It does this by providing default values and -- >under some recent proposals -- by indicating type information, which may be >considered also a form of default value. Elements defined by a schema, when >used in an instance document in a validating processor, will have these >default values available, and this fact is pertinent to the author of the >document. This means that an element is incompletely read if the schema for >it is not read. This assumes that default values are not conditional or parameterized, which in turn assumes a particular form for schemas. But the current Infoset draft only has "the information available in a well-formed XML document". So there are levels of Infoset depending on which data is considered, in progressive fashion. In s. 7 "What is not in the information set": 1. The information in the XML declaration and text declarations. 2. Element content models from ELEMENT declarations. 3. The grouping and ordering of attribute declarations in ATTLIST declarations. So Andrews view seems novel. In DOM level 1 also there is no access to content model information, which suggests that the incompleteness of an element without a content model is minimal for basic use of that element. Canonical XML does not include DTD or schema. (Furthermore, some people have reservations that default values are in fact part of a schema at all. ) >Unlike the various processings that may or may not be applied to a document, >a cited schema is part of the information conveyed by the document. When a >namespace has an associated schema, that schema is part of the input to any >further complete processing of the referencing document. A schema is not on >par with other forms of processing that might be specified, say by style >sheets or procedural code. It is prior to other processing. Again, Andrew is simply conflating schema and namespace. The idea that he and Tim are putting forward is that a language is defined by a single set of content models; this confuses "language" with "grammar" and is disproved by long-standing SGML practise, in which variants of a language can be defined in the same DTD (selected by marked sections, or by simply overriding parameter entity declarations). I think the problem is the bad idea that content models *define* a language rather than simply *describe* or *declare* it. The "blink" element is not strict HTML; it is only an artifact of the formalism used to describe HTML (content models on the child axis) that using a blink attribute should require the child element to be transitional HTML. There have been so much criticism of DTDs and their particular limitations of expressiveness, yet this namespace issue utterly is dependent on a DTD-based understanding of what a schema should be. An element is not defined by its content model, unless it and its content model are highly coupled semantically, such as tables and rows. But frames and the root html element are not highly coupled semantically. DTDs and content models (on the child axis) provide no way to model this: we either have ANY or a highly coupled content model. Take the example of

        and : these are not semantically coupled element types-- the element type adheres to running text and the

        element uses running text. If the element is removed, it is the declarations for running text that should be changed, not the declarations for

        . DTDs only provide parameter entities for this, which disguises this basic modeling truth. The XML Schema draft got it more right by providing archetypes as a first-class object. >Further, I expect that one can argue that a namespace is an abstract concept >denoting a set of names, and this argument is true, so far as it goes, but >it does not go far enough: For specific processing, to make use of a >namespace one needs to know what names are in it, which are not, and what >the meaning is for each name Here is the crux: Andrew is saying a namespace mechanism should provide more than just a space of names! He says it should also provide meanings. If it does so, it is not a namespace, but a schema. Andrew is saying that we should not have namespaces but schemas. This is a legitimate view, but it utterly flies in the face of the current spec and all previous pronouncements on it. If W3C says a namespace is a schema, they should withdraw the XML Namespaces Spec immediately. As I emailed a month ago, Namespaces is dead. Not by neglect but by abuse. 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 ann at webgeek.com Thu Sep 16 19:14:47 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:03 2004 Subject: Another look at namespaces In-Reply-To: <4.2.0.58.19990916125508.00b3d550@pophost.arbortext.com> References: <4.1.19990916123524.024ab640@mail.webgeek.com> <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com> <006101beffba$a2984280$a60a1712@col.w3.org> Message-ID: <4.1.19990916130806.0249d1a0@mail.webgeek.com> At 01:03 PM 9/16/99 -0400, Eve L. Maler wrote: >Not to pick nits, but the August 29 statement just observed a correlation; >when I first read it, I didn't take it to be providing an actual reason for >the decision. The "as direct a mapping as possible" language does indeed >give insight into the decision to go with a one-to-one DTD/NS mapping, >though I think that the confusion reigning about the purpose of NSs puts >the rationale on shaky foundations not of the WG's making. I can see where that observation may have occured. However, I do feel that a relatively cursory glance at the actual documents and Activity statement further solidify the charge to the WG of transforming all of HTML 4.0 (three versions) into XML, which is what we did. I think it's a rather spurious suggestion that the entire discussion would have been avoided > >This is a rationale. Including this with the recent draft > >would have saved us all a lot of e-mail traffic. had the statement been made in the manner that Tim did, only 3-4 weeks ago. The abstract seems to me to be very self explanatory: This specification defines XHTML 1.0, a reformulation of HTML 4.0 as an XML 1.0 application, and three DTDs corresponding to the ones defined by HTML 4.0. It still, however, doesn't definitely answer the namespace issue, though I personally believe it supports it. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wunder at infoseek.com Thu Sep 16 19:16:13 1999 From: wunder at infoseek.com (Walter Underwood) Date: Mon Jun 7 17:15:03 2004 Subject: Binary-encoding of XML for communication In-Reply-To: <002f01bf0036$4e6a8160$85247385@ssel.toshiba.co.jp> References: <805C62F55FFAD1118D0800805FBB428D02BBFEAB@cc20exch2.mobility.com> Message-ID: <3.0.5.32.19990916101657.00a6de40@corp.infoseek.com> At 08:26 PM 9/16/99 +0900, Shinichiro HAMADA wrote: >Hello, all. > >We are trying to develop a Server/Clients network system with XML. In this >system, Clients read structured data and send them as XML data to a server. > >We estimate too heavy to communicate text-based XML and to decode/encode it >to/from XML object tree. So we think it's desiable to communicate XML data >as binary serialized object tree. And it's better that the binary code is >open format. Do you need to optimize communication (bytes sent/received) or CPU (time spent parsing)? If it is communication, try compressing the XML with a standard algorithm. See the "content-coding" part of HTTP 1.1 for some samples. If it is CPU, benchmark XML parsers. Also, use an event-based parser (SAX) to build your data structures directly. With a DOM-based parser, you will build objects twice -- once for the DOM and once for your application. wunder -- Walter R. Underwood wunder@infoseek.com wunder@best.com (home) http://software.infoseek.com/cce/ (my product) http://www.best.com/~wunder/ 1-408-543-6946 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at docuverse.com Thu Sep 16 19:22:03 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:03 2004 Subject: Another look at namespaces In-Reply-To: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> Message-ID: <000001bf0068$8d5f6020$15a8fea9@w21tp> >With all due respect to Simon St. Laurent, I believe that Tim >Berners-Lee >was correctly precise when he wrote "the document corresponding to the >namespace URI becomes >the place where the namespace-author can put *definitive* >information about the intent of the namespace." (Emphasis in >the original). Andrew, Allow me to observe that: 1. 'Can' does not make 'Must' nor 'Should'. 2. 'Intent' of a namespace is not necessarily same as 'Schema'. I believe that: 1. A namespace is empty of meaning beyond being distinguishable from other namespaces. 2. A name within a namespace is also meaningless beyond being distinguishable from other names in the namespace. 3. Meaning of a name requires a frame of reference. While a schema can be a frame of reference for the meaning of a name, a family of schemas can be used as well. I believe this is precisely what should happen with the 'family' of XHTML schemas. Everything you stated depends on the assumption that a direct relationship exists between a namespace and a schema. I believe you can state the same if there was a direct relationship between a namespace and a family of schemas. We currently do not have a formal mechanism to define a family of schemas, but if there was, we should be able to define relationships between the member schemas as well the membership requirements. One happy family afterall. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Sep 16 19:22:57 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:03 2004 Subject: Another look at namespaces Message-ID: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU> From: Ann Navarro >At 09:16 AM 9/16/99 -0700, Walter Underwood wrote: >>At 04:41 PM 9/15/99 -0400, Tim Berners-Lee wrote: >>> >>> [...] the HTML 4.0 spec defined three, and XHTML was required to be >>>as direct a mapping from HTML 4.0 to XML as possible. >> >>This is a rationale. Including this with the recent draft >>would have saved us all a lot of e-mail traffic. > >This was said way back at the beginning (August 29) > >http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Aug-1999/0370.html > >Quoting myself "No, we've not confused them. We happen to have three >'flavors' of XHTML 1.0 >(the first deliverable from the XHTML project, not the end sum of our >work), that essentially map to the three flavors of HTML 4.0." But HTML 4.0 does not define three namespaces. The term namespace or its concept is never even used in it, that I can see. It specifies three DTDs, but since a schema is not a namespace, so what? T.B-L's argument is not that HTML 4 has three namespaces, but that HTML 4 has three DTDs, and so does is not an adequate rationale. In any case, since HTML 4.0 was finished before the namespace spec (1997-12-18 v. 1999-01-14) , how could it specify three namespaces? Does the HTML WG have some spirit guide :-) It seems clear that the HTML team have some mental concept of namespaces which exists independently of what the W3C specification actually allows. If a W3C specs can be utterly overturned in such a way, what is their value? 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 spreitze at parc.xerox.com Thu Sep 16 19:26:42 1999 From: spreitze at parc.xerox.com (Mike Spreitzer) Date: Mon Jun 7 17:15:03 2004 Subject: code generation from XML datatype definitions: anyone interested? In-Reply-To: <022d01bf0060$d9a828c0$0300000a@cygnus.uwa.edu.au> Message-ID: <001401bf0068$37db7030$27d1000d@deimos.parc.xerox.com> > ... Does the XML Data Binding spec address calculation of > attributes on the basic of other (possibly inherited) attributes? I would be surprised to see that, based on the requirements discussion available so far. > I would imagine building on that spec. If you mean "building" as in "layering", that would probably be ideal. If you mean "building" as in "modifying", it might be better to explain now (to the JCP) why you have additional requirements. 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 ricko at allette.com.au Thu Sep 16 19:33:24 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:03 2004 Subject: (minor correction) Re: Another look at namespaces Message-ID: <007f01bf006a$7574de70$1ff96d8c@NT.JELLIFFE.COM.AU> From: Rick Jelliffe >I think the problem is the bad idea that content models *define* a > language rather than simply *describe* or *declare* it. The "blink" > element is not strict HTML; it is only an artifact of the formalism > used to describe HTML (content models on the child axis) that using > a blink attribute should require the child element to be transitional HTML. "child element" should be "containing element" 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 ann at webgeek.com Thu Sep 16 19:42:46 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:03 2004 Subject: Another look at namespaces In-Reply-To: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <4.1.19990916133951.024af920@mail.webgeek.com> At 01:29 AM 9/17/99 +0800, Rick Jelliffe wrote: >But HTML 4.0 does not define three namespaces. T >In any case, since HTML 4.0 was finished before the namespace spec >(1997-12-18 v. 1999-01-14) You've answered your own question there. >It seems clear that the HTML team have some mental concept of namespaces >which exists independently of what the W3C specification actually >allows. There's no basis for that other than assumption. The HTML WG doesn't live in a cave, nor an alternate reality. By the conversations *here* it's clear that the community at large doesn't agree on the value and application of namespaces. That doesn't follow then, that the HTML WG simply can't read a spec or understand the obvious. :) Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shane at aptest.com Thu Sep 16 19:48:04 1999 From: shane at aptest.com (Shane P. McCarron) Date: Mon Jun 7 17:15:03 2004 Subject: Another look at namespaces References: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com> <006101beffba$a2984280$a60a1712@col.w3.org> <4.2.0.58.19990916125508.00b3d550@pophost.arbortext.com> Message-ID: <37E12DE0.8991665F@aptest.com> The XHTML 1.0 Proposed Recommendation (http://www.w3.org/TR/1999/PR-xhtml1-19990824) states in its Abstract and in Section 1.0 (What is XHTML?) that the specification is a reformulation of the three HTML 4.0 DTDs into three XML applications. We absolutely meant this to say that there are three distinct XML applications corresponding to the three distinct SGML applications of HTML 4.0. I will add a comment to the issue database that this was unclear and try to make an editorial change to the document to clarify it during the transition from PR to Recommendation (assuming we ever get that far ;-). Shane McCarron Speaking as editor of the XHTML 1.0 Proposed Recommendation "Eve L. Maler" wrote: > > Not to pick nits, but the August 29 statement just observed a correlation; > when I first read it, I didn't take it to be providing an actual reason for > the decision. The "as direct a mapping as possible" language does indeed > give insight into the decision to go with a one-to-one DTD/NS mapping, > though I think that the confusion reigning about the purpose of NSs puts > the rationale on shaky foundations not of the WG's making. > > Back to lurking, > > Eve > > At 12:44 PM 9/16/99 -0400, Ann Navarro wrote: > >At 09:16 AM 9/16/99 -0700, Walter Underwood wrote: > > >At 04:41 PM 9/15/99 -0400, Tim Berners-Lee wrote: > > >> > > >> [...] the HTML 4.0 spec defined three, and XHTML was required to be > > >>as direct a mapping from HTML 4.0 to XML as possible. > > > > > >This is a rationale. Including this with the recent draft > > >would have saved us all a lot of e-mail traffic. > > > >This was said way back at the beginning (August 29) > > > >http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Aug-1999/0370.html > > > >Quoting myself "No, we've not confused them. We happen to have three > >'flavors' of XHTML 1.0 > >(the first deliverable from the XHTML project, not the end sum of our > >work), that essentially map to the three flavors of HTML 4.0." > > > > > >But apparently nobody wanted to hear it. > > > >Ann > > > >--- > > > >Author of Effective Web Design: Master the Essentials > >Coming in September --- Mastering XML > > > >Founder, WebGeek Communications http://www.webgeek.com > >Vice President-Finance, HTML Writers Guild http://www.hwg.org > >Director, HWG Online Education http://www.hwg.org/services/classes > > > > > > > > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > >CD-ROM/ISBN 981-02-3594-1 > >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > >(un)subscribe xml-dev > >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > >subscribe xml-dev-digest > >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) -- Shane P. McCarron phone: +1 612 434-4431 ApTest fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@aptest.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Sep 16 19:54:19 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:03 2004 Subject: What XHTML should do with namespaces Message-ID: <009a01bf006d$67f97460$1ff96d8c@NT.JELLIFFE.COM.AU> 1) There should be three namespaces: base slack frames 2) These namespace should be formally defined by means of a simple list in each case, so that every HTML 4 element is allocated to one only namespace each. 3) There should be a EXTENSIBLE XHTML DTD created, in which all relevant attributes are declared for elements, but all element types them selves have no definitions or definitions of ANY. It is this DTD that documents should be transmitted with. It allows attribute defaulting and is open for extensibility, but provides weak type checking by recipient validators. 4) There should be 3 other DTDs created: strict (includes only elements from the base namespace) transitional (includes only elements from the base and slack namespace) frameset (includes elements from all namespaces) These three DTDs can be used for server/generator/tidier programs but are not for usual publically-distributed documents. This is the correct use of namespaces IMHO. Also, it makes XHTML documents extensible without DTD rewriting, which the current XHTML specification does not allow. In a sense, "strictly conforming XHTML documents" should be called non-extensible HTML! XHTML should start off mandating this kind of weakly typed DTD to allow extensibility: the strong typing should be provided by future XML Schema languages, with the DTD becoming merely a way to declare entities, transport comments, define attributes and defaults tersely, and for providing some kinds of document-specific restrictions to schemas. XHTML' approach to namespace is wrong because the whole thing is mistaken: lets not enshrine closed content models any more! XHTML should support extensibility! 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 shane at aptest.com Thu Sep 16 20:03:12 1999 From: shane at aptest.com (Shane P. McCarron) Date: Mon Jun 7 17:15:04 2004 Subject: Another look at namespaces References: <199909161638.MAA10671@hesketh.net> <4.1.19990916122123.0248fbf0@mail.webgeek.com> <199909161602.MAA09307@hesketh.net> <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <199909161659.MAA11511@hesketh.net> Message-ID: <37E13172.9FF0174A@aptest.com> "Simon St.Laurent" wrote: > Is there _anything_ else besides their names that distinguishes these flavors? Sure. XHTML Frameset has a completely different content model than the other two. Its root element is html, but that html element may NOT contain a body element. Instead, it contains a frameset element that defines the collection of frames. These frames have some weird inherent behaviour that cannot be described by existing schema technology (various panels are defined in the window, one per defined frame). To be clear, an XHTML Frameset document as NO CONTENT. Instead, it refers to content. Is this stupid? Sure. However, it is a faithful representation of HTML 4.0. XHTML Transitional has a different content model than Strict in that it is more permissive. XHTML Transitional may be a superset of XHTML Strict, but I have never done the evaluation to be certain. I am certain that they are significantly different. In particular, XHTML Transitional contains all sorts of stuff that is eliminated in XHTML 1.1. XHTML Strict only has a few items that are removed in XHTML 1.1 (e.g. the name attribute on the a element is eliminated in favor of the id attribute). > >Information about those namespaces may, if the W3C chooses to follow this > >path, be obtained from a schema, DTD, or other data source at the end of > >that URI. > > Or, since this is an XML 1.0 application, you could just read the DOCTYPE > declaration and not try to map namespace URIs to places where the W3C might > (but won't comment on publicly at present) want to go someday. Absolutely. And, since XHTML 1.0 requires a DOCTYPE declaration, you can be confident that one will be present in XHTML 1.0-conforming documents. Moving forward, as the HTML Working Group completes its work on Document and Client profiles (which might just be requirements to CC/PP, who knows), I expect that the group will define elements that allow document authors specify: a pointer to a document profile a complete, embedded document profile information about the schema information about how the schema is based upon other, well known schema (like XHTML) etc. However, that is a future problem. The current problem is finding a way through this morass so that we can publish the first baby step toward a better, more interoperable web. That is XHTML 1.0. What do we need to do to get on with it? -- Shane P. McCarron phone: +1 612 434-4431 ApTest fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@aptest.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Sep 16 20:11:24 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:04 2004 Subject: Another look at namespaces Message-ID: <00a101bf006f$c4ba8070$1ff96d8c@NT.JELLIFFE.COM.AU> From: Ann Navarro >At 01:29 AM 9/17/99 +0800, Rick Jelliffe wrote: >>It seems clear that the HTML team have some mental concept of namespaces >>which exists independently of what the W3C specification actually >>allows. > >There's no basis for that other than assumption. No, my basis is the emails on this subject, my involvement in the XML IG at the time the namespaces spec was developed, and subsequent comments by many people. >The HTML WG doesn't live in a cave, nor an alternate reality. By the >conversations *here* it's clear that the community at large doesn't agree >on the value and application of namespaces. That doesn't follow then, that >the HTML WG simply can't read a spec or understand the obvious. :) My point is not that they cannot, but that they have not in this case. To suggest that a WG can try to fit a square peg into a round hole does not mean that they live in an "alterate reality", merely that they have lost the plot on one particular issue, perhaps simply because of youthful enthusiasm. B.t.w., I think your reaction about "caves and alternate reality" is a bit too strong on this; if we say that this use of namespaces is novel and has not been justified or even attempted to have been justified in the past, that does not mean we are accusing the HTML WG of being a conspiracy. 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 simonstl at simonstl.com Thu Sep 16 20:20:10 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:04 2004 Subject: Applications, DTDs, Namespaces (was Re: Another look at namespaces) In-Reply-To: <37E12DE0.8991665F@aptest.com> References: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com> <006101beffba$a2984280$a60a1712@col.w3.org> <4.2.0.58.19990916125508.00b3d550@pophost.arbortext.com> Message-ID: <199909161822.OAA15351@hesketh.net> At 12:50 PM 9/16/99 -0500, Shane P. McCarron wrote: >The XHTML 1.0 Proposed Recommendation >(http://www.w3.org/TR/1999/PR-xhtml1-19990824) states in its Abstract >and in Section 1.0 (What is XHTML?) that the specification is a >reformulation of the three HTML 4.0 DTDs into three XML applications. We >absolutely meant this to say that there are three distinct XML >applications corresponding to the three distinct SGML applications of >HTML 4.0. I will add a comment to the issue database that this was >unclear and try to make an editorial change to the document to clarify >it during the transition from PR to Recommendation (assuming we ever get >that far ;-). > >Shane McCarron >Speaking as editor of the XHTML 1.0 Proposed Recommendation I'm not sure that this actually clarifies the genuinely contentious issues. 'Three distinct XML applications' still doesn't imply 'three distinct XML namespaces'. The Namespaces in XML Recommendation only describes software applications, not 'XML applications'. There doesn't appear to be any correlation between applications and namespaces, and I think that issue (also described as DTDs/schemas and namespaces) is what's keeping this discussion grinding along, going nowhere quickly. 'Vocabularies' might be a better word to use (more in keeping with the NiX rec), though there the overlap between the three vocabularies makes it hard to justify. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Thu Sep 16 20:21:05 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:04 2004 Subject: Another look at namespaces In-Reply-To: <37E13172.9FF0174A@aptest.com> References: <199909161638.MAA10671@hesketh.net> <4.1.19990916122123.0248fbf0@mail.webgeek.com> <199909161602.MAA09307@hesketh.net> <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <199909161659.MAA11511@hesketh.net> Message-ID: <199909161823.OAA15376@hesketh.net> At 01:05 PM 9/16/99 -0500, Shane P. McCarron wrote (a better answer than I hoped to receive): >"Simon St.Laurent" wrote: >> Is there _anything_ else besides their names that distinguishes these flavors? > >Sure. > >XHTML Frameset has a completely different content model than the other >two. Its root element is html, but that html element may NOT contain a >body element. Instead, it contains a frameset element that defines the >collection of frames. These frames have some weird inherent behaviour >that cannot be described by existing schema technology (various panels >are defined in the window, one per defined frame). To be clear, an XHTML >Frameset document as NO CONTENT. Instead, it refers to content. Is >this stupid? Sure. However, it is a faithful representation of HTML >4.0. The question in full was 'Is there anything else besides [the DTDs - from prev para - and ] their names that distinguishes these flavors. 'Completely different content model' is still well within the realm of DTDs/schemas. 'Weird inherent behavior' at least moves beyond that, but I'm not sure it justifies an additional namespace. >XHTML Transitional has a different content model than Strict in that it >is more permissive. XHTML Transitional may be a superset of XHTML >Strict, but I have never done the evaluation to be certain. I am certain >that they are significantly different. In particular, XHTML Transitional >contains all sorts of stuff that is eliminated in XHTML 1.1. XHTML >Strict only has a few items that are removed in XHTML 1.1 (e.g. the name >attribute on the a element is eliminated in favor of the id attribute). This is all represented by the DTD, however - I don't think there's any need to go beyond that and distinguish strict from transitional as far as identifiers are concerned. >> >Information about those namespaces may, if the W3C chooses to follow this >> >path, be obtained from a schema, DTD, or other data source at the end of >> >that URI. >> >> Or, since this is an XML 1.0 application, you could just read the DOCTYPE >> declaration and not try to map namespace URIs to places where the W3C might >> (but won't comment on publicly at present) want to go someday. > >Absolutely. And, since XHTML 1.0 requires a DOCTYPE declaration, you can >be confident that one will be present in XHTML 1.0-conforming documents. >Moving forward, as the HTML Working Group completes its work on Document >and Client profiles (which might just be requirements to CC/PP, who >knows), I expect that the group will define elements that allow document >authors specify: > > a pointer to a document profile > a complete, embedded document profile > information about the schema > information about how the schema is based upon other, well known > schema (like XHTML) > etc. > >However, that is a future problem. The current problem is finding a way >through this morass so that we can publish the first baby step toward a >better, more interoperable web. That is XHTML 1.0. What do we need to >do to get on with it? Simplify would be a good first step. Give XHTML 1.0 a single namespace for this version, and then get on with the more exciting work that follows. Don't complicate matters by adding namespaces on top of the DOCTYPE declaration you promise to use faithfully. But remember, I haven't paid any membership dues. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 shane at aptest.com Thu Sep 16 20:29:07 1999 From: shane at aptest.com (Shane P. McCarron) Date: Mon Jun 7 17:15:04 2004 Subject: What XHTML should do with namespaces References: <009a01bf006d$67f97460$1ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <37E13772.86FD1331@aptest.com> Rick proposes an interesting model. This model is largely already supported in XHTML Modularization. XHTML Modularization provides a toolkit for developing markup languages from modules. These modules are defined abstractly, and then mapped onto an implementation (an XML DTD, but an XML Schema is also possible). These modules can be collected together to form arbitrary XHTML-family markup languages. Users can also develop new modules with their own elements and attributes, extend the content models of XHTML-provided modules, etc. These are defined in Building XHTML Modules, Modularization of XHTML, and XHTML 1.1. These public documents are available at http://www.w3.org/TR The working group never intended XHTML 1.0 to be extensible. It is a bridge. It is there to help HTML document authors make the transition to XML in a way that is backward compatible with existing browsers. Nothing more. Don't read too much into it. It will drive you crazy. With regard to namespaces, IMO the work on Modularization is orthogonal to namespaces. It is not the intent of the working group to define multiple namespaces within the modularization infrastructure. You could, I supposed, use modularization to define a collection of namespaces that represent different collections of functionality. These namespaces could then be cobbled together in compound documents. However, the resulting documents would not be validatable. Regardless, the modularization architecture of XHTML is designed to address the goal of extensibility on a massive scale. It can be mapped into XML Schema or XML DTDs. It can rely upon XML namespaces or not. I suggest you all check these documents out before worrying about the extensibility of XHTML. -- Shane P. McCarron phone: +1 612 434-4431 ApTest fax: +1 612 434-4318 mobile: +1 612 799-6942 e-mail: shane@aptest.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Thu Sep 16 20:25:48 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:04 2004 Subject: Another look at namespaces In-Reply-To: <00a101bf006f$c4ba8070$1ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <4.1.19990916142517.024ddae0@mail.webgeek.com> At 02:17 AM 9/17/99 +0800, Rick Jelliffe wrote: >that does >not mean we are accusing the HTML WG of being a conspiracy. No, but you're basically suggesting that we're thick. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Sep 16 21:03:44 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:04 2004 Subject: Another look at namespaces Message-ID: <00bc01bf0076$ed87bca0$1ff96d8c@NT.JELLIFFE.COM.AU> From: Ann Navarro >At 02:17 AM 9/17/99 +0800, Rick Jelliffe wrote: > >>that does >>not mean we are accusing the HTML WG of being a conspiracy. > >No, but you're basically suggesting that we're thick. Come on, stop making this into some personal thing. I said " It seems clear that the HTML team have some mental concept of namespaces which exists independently of what the W3C specification actually allows". Perhaps this concept is an improvement; but don't expect anyone to swallow a major, last minute, unexpected use of namespaces that goes against all the discussions at the time and against all public statements since that time. There still has been no justification for it: TB-Ls comment that HTML has three DTDs so should have three namespaces puts the cart before the horse; Andrew Layman's comment that there are definitional schemas and that these set namespaces is undebated and can be proved wrong by the simple example of RDF, which defines a namespace but allows major parts of schemas undefined, notably the GIs (element type names) of second and third tier elements. So if RDF is a legitimate use of namespaces, and if namespaces come from definitional schemas, then the definitional schema does not need to include a specific content model: if can be extended and refined willy nilly. Following this line, the only thing in a schema left ultimately is a list of names. However, it is quite possible for someone to make a list of names, and use some in one DTD and others in another DTD, with no mixing. This is a legitimate use of namespaces in the current spec; again, it shows that there is no nessecary connection between a "definitional schema" and a namespace, unless the definitional schema is a simple list of names (in some format TBA). Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Sep 16 21:20:16 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:04 2004 Subject: More than three namespaces for XHTML? (was Re: What XHTML should do with namespaces) Message-ID: <00c101bf0079$362e4cb0$1ff96d8c@NT.JELLIFFE.COM.AU> From: Shane P. McCarron >Regardless, the modularization architecture of XHTML is designed to >address the goal of extensibility on a massive scale. It can be mapped >into XML Schema or XML DTDs. It can rely upon XML namespaces or not. I >suggest you all check these documents out before worrying about the >extensibility of XHTML I had. Whether XHTML modularization and profiles rely on namespaces (which surely they should) is not the issue here. The issue is that the XHTML namespaces should not be equated with the HTML DTDs. Actually, it is an issue: if namespaces are to be taken from DTD, then every different possible combination of modularized HTML has its own effective DTD and will therefore need its own namespace. So we are not talking about 3 namespaces for XHTML, but potentially dozens! I have been trying to figure out what on earth the HTML WG is thinking. The best I can come up with is that they do not think that HTML processors will use the namespace prefixes: they will key off the local name only and they expect that qualified names will never be used, because the namespace declaration on the html element will preclude it. In other words, there is some kind of tacet assumption that qualified names are never used and that, because then CSS will work fine, there is really no problem. So it would not be an issue if there were 1,000 namespaces, because the namespace just selects the DTD variant. However, this view is not correct: XHTML will be used by namespace-aware applications and these applications should not need be programmed to cope with every namespace variant, especially if there may be dozens. 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 tyler at infinet.com Thu Sep 16 22:00:44 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:15:04 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" References: <4.1.19990916120701.0249cb80@mail.webgeek.com> Message-ID: <37E14C81.177ECBD7@infinet.com> Ann Navarro wrote: > At 11:43 AM 9/16/99 -0400, Hunter, David wrote: > >(If I develop an Intranet application, I want to be able to > >use XHTML without clients having to run out to the W3C site regularly. > >Ditto for any other XML vocabularies which are defined going forward, from > >the W3C or anyone else.) > > It also should be noted that there's nothing precluding a cache'd copy of > that "thing" for that Intranet application. True, but I think all of this misses the point here. Since November 1997 when I started working with XML, I have never once found any need for a DTD or some other Schema language for the applications I have written which use XML. For databases, schema's I feel are very necessary, but I just have not found any real-world use for DTD's or schemas to date other than as a technical document a programmer can refer to. Add in what namespaces do to DTD's and Schemas in general and you effectively have no real reason to produce documents that would be processed by a validating XML Parser. The one exception I can think of is an abstract element tree like the DOM where you want to make sure you have a valid document since the DOM itself has no way of enforcing a document type during the tree building process. In the case of most applications, they build there own data structures directly from an event-based XML parser or else from some sort of object-oriented framework which delegates the events to some sort of abstract element API. If you get an unknown form of element content, the application can choose how to handle it as it wishes. Whether this element content is supposed to be there is defined by programmer documentation which may include a DTD as a reference (such as in the XSLT spec). If expected element content does not occur within the scope of the containing element being processed, then the application can fill in the default values as it sees fit. In the case of internal general entities (if you choose to use them), you can handle all of that business at the application level as well, therefore eliminating the need for DTD's or schemas. In the case of XHTML and this whole debate about 3 namespaces vs. one namespace, in theory the 3 namespaces proposal makes much more sense than having just one namespace. In reality, for not just software, but average web netizens as well who believe it or not still sometimes like to code HTML by hand or at least post-edit the content generated from their very poor and universally incompatible HTML editing tools, having three namespaces just exponentiates the confusion. So the fact this list is arguing about document science concepts for a markup language whose intended audience is virtually anyone on the internet who wants to build a web page, totally misses the point. We need to ask the question "how does this impact the users of this wonderful new markup language we are proposing". To date, I have only seen a handful of comments on this issue and since I write software for users for financial gain, and not for personal adulation, I ask myself these questions all the time when I write a new software module that has some end-user interaction associated with it. Hopefully the W3C is more concerned with creating an XHTML spec of practical use rather than some piece of art that CS 101 students will reflect on 100 years later as something beautiful but "never caught on with the masses". What seems like the best solution sometimes is not always the most satisficing to your real goals. Tyler Baker xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Thu Sep 16 21:57:59 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:15:04 2004 Subject: Binary-encoding of XML for communication In-Reply-To: <002f01bf0036$4e6a8160$85247385@ssel.toshiba.co.jp> References: <805C62F55FFAD1118D0800805FBB428D02BBFEAB@cc20exch2.mobility.com> Message-ID: <3.0.1.32.19990916112925.008c3100@tiac.net> I'm not aware of any such standard (unless you just did something obvious like use Java serialization on a DOM). However, my experience has been that gzip (zlib) crunches textual XML amazingly well (thanks to the fact that most XML documents are full of the same tags over and over and over...). And expat can turn XML text into a binary representation really fast. Sometimes, simple tools work very well. At 08:26 PM 9/16/99 +0900, Shinichiro HAMADA wrote: >Hello, all. > >We are trying to develop a Server/Clients network system with XML. In this >system, Clients read structured data and send them as XML data to a server. > >We estimate too heavy to communicate text-based XML and to decode/encode it >to/from XML object tree. So we think it's desiable to communicate XML data >as binary serialized object tree. And it's better that the binary code is >open format. > >If I remeber correctly, such a open binary XML format are discussed among a >starndard XML community. Is it true? If anyone knew anything about that, >please tell me. > >Thank you in advance. > >-- >Shinichiro HAMADA >TOSHIBA Corp. > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Thu Sep 16 23:06:50 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:15:05 2004 Subject: Another try on groves Message-ID: <37E1532B.82F3BB03@prescod.net> Imagine that you are a Mozilla programmer. One day you are trolling through the XML family of specifications and you notice that RDF and XLink offer some intriguing possibilities. RDF allows you to associate, let's say, ratings with components of XML documents. So you could have a big XML document representing a Slashdot forum and you could use RDF to hide the articles ranked as trolls. Using RDF all of this could be done on the client side using sophisticated Mozilla-built in features. Of course a decent programmer would not restrict the feature to Slashdot, or to online forums but to any XML document with ratings described by RDF. Using XLink you could also allow links to be imposed. These could point to other documents on the Web that relate to the current conversation. They could also be annotations by non-slashdot members. A light comes on. Now you understand what these specifications were meant to allow. So you start madly implementing. As you are about a third of the way through you notice that the RDF and XLink specifications do not explicitly limit their targets to XML. ANY media type with a fragment identifier can be described by RDF or linked by XLink. Uh oh. Things just got a lot more complex. You can now address into PDFs, MPEGs, ShockWaves and CorelDraw graphics. Of course Mozilla supports those formats though third party plug-ins. You don't even have the code to them...the only way to influence them is to improve the plug-in API. Now you have a choice: you can subvert the intent of the RDF and XLink specifications by pretending that they only apply to XML or you can step up to the challenge of implementing the features in a manner that does not discriminate against non-XML media types. Obviously MPEG movies are not going to be XML documents in our lifetimes. If you are in a hurry you might jump to the conclusion that the best way to address into these media types is either to convert them INTO XML (perhaps reasonable for PDF) or at least have them expose their properties as a DOM. The problem with being in a hurry is that you end up wasting time. You will waste time here because the impedence mismatch between MPEGs and the DOM is going to be huge. A frame is not an "element", it has no "attributes". Now I claim that a frame is an object and that it has properties. And any idiot knows that objects can be represented in XML using a variety of techniques but think about the logic of doing it this way: you are taking a thing that is "logically" an object, expressing it in terms of a text file format so that another module in the same process can re-interpret it as logical objects. The *only good reason* to dumb something down into XML elements and attributes is to move the information between processes separated by space, time or incompatibility. Using XML as the "universal API" is madness because there *is no universal API*. The idea is patently ridiculous. (some Unix evangelists have claimed that open/read/write is hte universal interface but actual Unix usage demonstrates that this is not even close to true...look at the heavy usage of CORBA and IDL in Unix GUIs) The term "dumb down" is not an insult against XML or the DOM. After all, the act of representing something as XML necessarily "dumbs down" the XML to Unicode characters but that can hardly be considered an insult against Unicode! Representing Unicode requires a dumbing down into octets which are dumbed down into bits to be sent across the wire. All of this dumbing down is great when it is necessary but inconvenient and inefficient when it is not. So as a Mozilla programmer your next step is to define a base class for "linkable objects". Let's call those "nodes." In order to navigate around these nodes it is useful (some claim necessary...I believe them but have not verified this for myself) to have the nodes have properties like "parent", "children", and so forth. Yes, this is very DOM like but the big difference comes in the next step: the next step is that the "properties" of these things can be rich -- not "dumbed down" to elements and attributes. This not only removes two layers of code (dumbing down and building up) it also removes a lot of potential for confusion: "the object's principle light source property is represented by a reference to a principle light source element which represents a light source object. Go read the documentation to see how a light source object is represented in our DOM representation." Why not represent a "principle light source" property with a property named "principle light source" and why not let its value be a real object (not an element) with properties that are also real objects. Okay, so what else do we need in our "node" ("linkable object") interface? Well, runtime discoverability of node types and properties is useful in any language and absolutely required if we are going to expose our objects in a dynamically typed language like Javascript or DSSSL. So we need methods that allow us to find out the node's class and property list. This base "interface" is known in grove terms as the "intrinsic properties." They aren't just magical hidden features -- they are properties just like "principle light source" and "element type name." There's an important operation we need every pair of nodes to support: given two node references we need to be able to figure out if they are to the same node. If we are going to make a list of all opinions about a particular Slashdot posting then we need to be able to recognize when multiple links are talking about the same thing. This is why I've harped in the past, on this list, about object identity. Linking is not going to work properly unless we figure it out. Arguably, object identity is the *whole point of groves*. But of course there is more. Now consider that some applications work on all XML document types but many work on only a particular document type. The same holds for COM objects. The same holds for groves. Some will work with any old grove (e.g., a hyperlink database) but a renderer will require a particular set of node types. Just as we have a schema to allow XML documents in a class to be consistent we have a schema for groves called a "property set." This can even be compiled into a header file in a strongly typed programming language (just like a COM type library or OLE class). Here are what I consider the crucial points of this discussion: * existing web technologies will not "work properly" without a data model for linkable, annotable data. These technologies implicitly depend upon this model that *does not exist*. Call it a universal data model, meta data-model, meta, meta, data-model, whatever. It needs to exist. * near-term software applications will run up against the lack of this model not in the distant future but in years or months. Arguably they have *already* run up against the problem of the lack of this model. The XML information set is a stop-gap for applications that are all XML but this is supposed to be a hypermedia web -- the stopgap can only hold for so long. * there is nothing futuristic about groves. They take some basic ideas from the information set, add them to some basic ideas from COM/CORBA, add in a few original ideas specific to the hyperlinking domain and that's it. Groves only seem abstract because most people are still confused by and scared of linking applications. The (IMHO) chaotic development of linking and annotative specifications and software on the Web is a symptom of this same problem. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mike at DataChannel.com Thu Sep 16 23:31:46 1999 From: mike at DataChannel.com (Mike Dierken) Date: Mon Jun 7 17:15:05 2004 Subject: Transmitting CGI vars to an XML doc. Message-ID: <8EAE75D3D142D211A45200A0C99B6023013253CD@ZEUS> I did something like this a while back that I termed 'Dynamic Entity References' and here is a write-up: http://xdev.datachannel.com/press/lounge.html This may give you more ideas. Mike -----Original Message----- From: Binesh Bannerjee [mailto:binesh@hex21.com] Sent: Wednesday, August 18, 1999 10:13 AM To: xml-dev@ic.ac.uk Subject: Re: Transmitting CGI vars to an XML doc. On Wed, 18 Aug 1999, Binesh Bannerjee wrote: > What is the way that people here are using to send CGI parameters > to an XML driven CGI? Sorry for the endless clarifications, but I just ... Well, want to clarify. The way I'm thinking about approaching this is as follows: CGI request comes into Servlet. Servlet creates a "CGI_Descriptor" XML doc. Servlet passes CGI XML doc, Template XML doc, Template XSL doc to "Processor" Processor reads Template XML doc (via DOM) replaces CGI vars [ This is the part that's unclear to me. ] Processor spawns new processors to handle "Subtemplates" within template (which follows recursively this same procedure.) Processor uses XSL to create the output page, and sends this off to the browser. My unknowns are, how to represent in the Template XML doc CGI variables, and how people are handling XML in "subtemplates" that themselves may need to be processed further... Am I correct in thinking that adding say a " tag that is to expand into todays date would necessarily be a proprietary piece of code, that no standard XML browser would ever be able to read? (Although, a date one is far too simple, since that would likely be done with the ECMAscript in XSL...) It would be nice to be able to do "?> and then binesh_plugin would add whatever it needed to into the doc... If not, it's looking like I'll have to do something like so: Which then I'd write something using the DOM, that traverses the doc and looks for binesh_plugin, and replaces that node with whatever it thinks should be there instead... But I'd _hate_ to have to do this because anything I do with DOM would be opaque to a general XML style browsers... Again any help appreciated, thanks... (BTW, total Unix guy and microsoft-phobe here... So...) Binesh * There's nothing wrong with me... http://www.panix.com/~binesh * * There's something wrong with the universe. http://www.hex21.com/ * * CGI/Java Consulting * * I know it's all in vain * * I know that I'm to blame * * I know the purest rain * * Won't wash this bloody stain * * I know this sickness from inside * * Will tear us apart, tear us apart * * You're still in my heart tearing apart * * Tearing Apart - Siouxsie And The Banshees * xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe 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 ann at webgeek.com Thu Sep 16 23:28:06 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:05 2004 Subject: Another look at namespaces In-Reply-To: <00bc01bf0076$ed87bca0$1ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <4.1.19990916172542.025cd8c0@mail.webgeek.com> At 03:08 AM 9/17/99 +0800, Rick Jelliffe wrote: > From: Ann Navarro > >>At 02:17 AM 9/17/99 +0800, Rick Jelliffe wrote: >> >>>that does >>>not mean we are accusing the HTML WG of being a conspiracy. >> >>No, but you're basically suggesting that we're thick. > >Come on, stop making this into some personal thing. I think I've shown a remarkable degree of restraint over the past few weeks, in the face of considerable hyperbole and poor assumptions. But I do object to the assertion that we're somehow out in left field. We disagree, there's a difference. >There still has been no justification for it: What are you doing to do if you get something that finally meets your definition of "justification"? Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken_north at compuserve.com Thu Sep 16 23:19:00 1999 From: ken_north at compuserve.com (Ken North) Date: Mon Jun 7 17:15:05 2004 Subject: Sybase and XML? References: <01BF003F.C86030B0@grappa.ito.tu-darmstadt.de> Message-ID: <006d01bf0089$784e9a40$0b00a8c0@grissom> Ronald Bourret wrote: > Do you know of any URLs with technical details? I've poked around the IBM, > Microsoft, Sybase, and Informix web sites, but can't find anything specific Ron, 1. The Sybase site has some white papers in PDF format. You can find them by searching on XML. 2. AFAIK, nothing has been published on the Informix site. 3. Microsoft just made its announcement this week. The code name for the next release of SQL Server is Shiloh, so you might try using that for further searching. 4. Information isn't freely available because beta testers sign a non-disclosure agreement. Anything I can post here has to have been publicly disclosed. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From abrahams at valinet.com Fri Sep 17 00:06:56 1999 From: abrahams at valinet.com (Paul W. Abrahams) Date: Mon Jun 7 17:15:05 2004 Subject: Unicode surrogate block in XML? Message-ID: <37E16B3C.1FC56A27@valinet.com> The XML 1.0 spec explicitly excludes the Unicode surrogate characters from XML documents (production 2). It now seems, from information I've picked up on the Unicode web site, that surrogate characters are likely to play a more important role in the future, since the available 16-bit characters are almost all used up. (Unicode 2.0 has 18,134 spares but Unicode 3.0 has only 7827 spares. The trend is clear.) Is any thought being given in W3C to allowing surrogate characters in XML documents? Paul Abrahams xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 00:04:20 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:15:05 2004 Subject: Another look at namespaces Message-ID: <5BF896CAFE8DD111812400805F1991F712E172C1@RED-MSG-08> A little more courtesy should be extended to the members of the HTML WG. The namespaces specification describes a mapping from colonized names to URIs, and indicates that the function of this is universal identification. The specification does not require that a namespace correspond to anything like a schema; but neither does it forbid such correspondence, either generally or in specific contexts. The specification does not require that identification indicate semantics, but neither does it forbid it, either generally or in specific contexts. And so on. No one should take the silence of the specification on a particular subject as equivalent to either a recommendation or a proscription. Silence is just ... silence. On reading the specification, some may wish that it said more, or said what it does say better, and for the latter, as an editor of the specification, I apologize. Some evidently think that the best use of the specification is not the use to which the HTML WG has put it. These insights are more productive when shared as a technical discussion on how namespaces should best be used, not speculations on the intellectual and moral incapacity of the WG; and are always best if accompanied by the courtesy of remembering that when people disagree with you, it is not always the sign of some fault in 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 ann at webgeek.com Fri Sep 17 00:12:17 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:05 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <37E14C81.177ECBD7@infinet.com> References: <4.1.19990916120701.0249cb80@mail.webgeek.com> Message-ID: <4.1.19990916181124.025d5510@mail.webgeek.com> At 04:01 PM 9/16/99 -0400, Tyler Baker wrote: >Ann Navarro wrote: > >> At 11:43 AM 9/16/99 -0400, Hunter, David wrote: >> >(If I develop an Intranet application, I want to be able to >> >use XHTML without clients having to run out to the W3C site regularly. >> >Ditto for any other XML vocabularies which are defined going forward, from >> >the W3C or anyone else.) >> >> It also should be noted that there's nothing precluding a cache'd copy of >> that "thing" for that Intranet application. > >True, but I think all of this misses the point here. Since November 1997 >when I started >working with XML, I have never once found any need for a DTD or some other >Schema language for >the applications I have written which use XML. We need to be careful to remember that when working with Recommendations, our own personal experiences aren't the only experiences that are applicable. I personally detest frames, yet they were popular enough to make it into previous HTML Recs. That I didn't like/need/use them didn't invalidate their (then) usefulness. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Sep 17 00:26:16 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:15:05 2004 Subject: Another look at namespaces References: <006101beffba$a2984280$a60a1712@col.w3.org> <14304.11288.712453.705292@localhost.localdomain> Message-ID: <37E16A98.9235C4@prescod.net> David Megginson wrote: > > 1. An application must be able to determine the general language used > by (part of) a document. > 2. An application must be able to determine the specific dialect used > by (part of) a document. David, can you please define "general language" and "dialect" in a manner that I can implement in a computer program? Is "XML" a general language? Is "XHTML" a dialect? Is "XSLT" a language and "XSLT used with XSL FOs" a dialect? Please don't appeal to my common sense or intuition because I have neither and unfortunately neither does my Pentium 233. > We mustn't make easy tasks difficult for the sake of theoretical > purity -- It isn't a question of theoretical purity. It's a question of implementability. According to your model every "language" and "dialect" becomes a special case because there is no definition of what is a language and what is a dialect. You can't design a general purpose processor for mapping dialects into languages or between dialects because it's all "language" specific. Want to know how HTML dialects are related? Go read the HTML spec. Want to know how SVG dialects are related? Go read the SVG spec. > I know, because we tried to do that over and over again in > the SGML world, and, well, we're not debating SGML any more, are we? It seems that we are. Renamed, retargeted and revamped -- and getting "purer and purer" every day (for better or worse). Compare the design purity of, let's say CONCUR to that of namespaces (not entirely unrelated problem domains, BTW). And let's not even get into SHORTREF. SGML was NOT a purist design -- XML is closer but is still pretty far away from purity. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Fri Sep 17 00:37:46 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:15:05 2004 Subject: Binary-encoding of XML for communication Message-ID: <5BF896CAFE8DD111812400805F1991F712E172C2@RED-MSG-08> Actually, much XML is transmitted in a binary form today, thanks to the LZ compression built into modern modems. As Joshua Smith observed, XML compresses amazingly well (in my tests, many documents compress to between five and ten percent of their original size). And, as others have observed, much value in XML comes from the fact that it is text-based. Before investing in a non-textual equivalent of XML, I recommend carefully looking at whether and where such a thing is actually needed. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 00:39:00 1999 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:15:05 2004 Subject: Another look at namespaces Message-ID: <5BF896CAFE8DD111812400805F1991F712E172C4@RED-MSG-08> Rick Jeliffe wrote "Andrew Layman's comment that there are definitional schemas and that these set namespaces is undebated and can be proved wrong by the simple example of RDF, which defines a namespace but allows major parts of schemas undefined,..." I recommend that you return to my original post and look at what I actually wrote. You might be pleasantly surprised to find that I am both aware of and support the idea of namespaces which are not defined by schemas. :-) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 02:09:49 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:05 2004 Subject: Another look at namespaces In-Reply-To: <000001bf0068$8d5f6020$15a8fea9@w21tp> References: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <000001bf0068$8d5f6020$15a8fea9@w21tp> Message-ID: <14305.20165.688555.834528@localhost.localdomain> Don Park writes: > I believe that: > > 1. A namespace is empty of meaning beyond being distinguishable from other > namespaces. > 2. A name within a namespace is also meaningless beyond being > distinguishable from other names in the namespace. > 3. Meaning of a name requires a frame of reference. I cannot remember Tim Bray's exact wording, but he said something like "programs can use qualified names they recognize as triggers for processing behaviour". That (or whatever he actually said) is the best summary of Namespaces that's come out so far. 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 Sep 17 02:03:55 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:05 2004 Subject: Another look at namespaces In-Reply-To: <199909161702.NAA11855@hesketh.net> References: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com> <006101beffba$a2984280$a60a1712@col.w3.org> <199909161702.NAA11855@hesketh.net> Message-ID: <14305.19804.526873.841691@localhost.localdomain> Simon St.Laurent writes: > I don't think anyone's argued hard that three flavors of DTDs was a > horrible thing, though I know many of us (including, perhaps even Ann) > would just as soon reduce it to one. This is actually an important point -- I have found three flavours of HTML DTD very useful for authoring (in PSGML), but I have not found or written any processing tools at all that care about which DTD I happened to use. 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 Sep 17 02:35:28 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:15:05 2004 Subject: Unicode surrogate block in XML? Message-ID: <3.0.32.19990916173644.00c55100@pop.intergate.bc.ca> At 06:12 PM 9/16/99 -0400, Paul W. Abrahams wrote: >The XML 1.0 spec explicitly excludes the Unicode surrogate characters >from XML documents (production 2). It now seems, from information >I've picked up on the Unicode web site, that surrogate characters are >likely to play a more important role in the future, since the >available 16-bit characters are almost all used up. (Unicode 2.0 has >18,134 spares but Unicode 3.0 has only 7827 spares. The trend is >clear.) No. Production [2] says [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] This follows the unicode model in allowing 17 planes of 64k characters each, i.e. about a million characters. For this to work in UTF-16, you need surrogate pairs. What XML rules out is *characters* whose numeric value is that of one-half of a surrogate pair. There will never be any such characters precisely because those values are reserved for use in surrogate pairs. That's why XML rules them out. -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 Fri Sep 17 02:58:11 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:05 2004 Subject: Discourse and Discourtesies In-Reply-To: <5BF896CAFE8DD111812400805F1991F712E172C1@RED-MSG-08> Message-ID: <199909170100.VAA32573@hesketh.net> At 03:05 PM 9/16/99 -0700, Andrew Layman wrote: >A little more courtesy should be extended to the members of the HTML WG. Could you please let us know precisely what it is that you're objecting to? A number of W3C-affiliated folks are griping, but, to be honest, I don't see any discourtesy, just a large number of serious questions. (Your message didn't cite any examples.) If anything, I see W3C folk turning back serious questions with personal reactions and overstated rhetoric that borders on contempt and ridicule. While it is unfortunate that a seemingly large number of XML-dev folk disagree with the work of the HTML WG, I don't see much flamethrowing going on. Some folks may interpret disagreement as personal attacks, but I can't see I've seen cause for that lately. Just curious, Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 terje at in-progress.com Fri Sep 17 05:01:38 1999 From: terje at in-progress.com (Terje Norderhaug) Date: Mon Jun 7 17:15:06 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" Message-ID: At 1:01 PM 9/16/99, Tyler Baker wrote: > >True, but I think all of this misses the point here. Since November 1997 >when I started >working with XML, I have never once found any need for a DTD or some other >Schema language for >the applications I have written which use XML. For databases, schema's I >feel are very >necessary, but I just have not found any real-world use for DTD's or >schemas to date other >than as a technical document a programmer can refer to. An XML editor can facilitate authoring much better if it has a DTD available. With a DTD, the editor can provide a sophisticated user interface that suggests the elements that can be used, where they can be used, and their attributes. Without a DTD, the author will be required to specify the names of each element and attribute, making authoring cumbersome. So DTDs have real world use even if the document can be processed without. -- Terje Norderhaug President & Chief Technologist Media Design in*Progress San Diego, California XML Software for Mac Web Professionals at Take advantage of XML with Emile, the first XML editor for Mac! xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Sep 17 03:49:41 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:06 2004 Subject: Another look at namespaces In-Reply-To: <37E16A98.9235C4@prescod.net> References: <006101beffba$a2984280$a60a1712@col.w3.org> <14304.11288.712453.705292@localhost.localdomain> <37E16A98.9235C4@prescod.net> Message-ID: <14305.26144.396116.962881@localhost.localdomain> Paul Prescod writes: > David Megginson wrote: > > > > 1. An application must be able to determine the general language used > > by (part of) a document. > > 2. An application must be able to determine the specific dialect used > > by (part of) a document. > > David, can you please define "general language" and "dialect" in a > manner that I can implement in a computer program? A language is an arbitrary point in a continuum, discovered empirically. For example, consider the following: Marked-up text => SGML => HTML => HTML 4.0 => HTML 4.0 strict There is a very large set of software that can work with HTML (more or less interoperably), but considerably less software that works with SGML in general, and almost nothing that works exclusively with HTML 4.0, much less HTML 4.0 strict. More importantly, there is a well-defined set of behaviours associated with the software that works with HTML, and that set of behaviours is generally considered useful in itself. The same thing applies in natural languages: Indo-European => Germanic => English => Canadian => Ontario => Toronto It's easy but wasteful to make too much of small distinctions, though it's still important to be able to present them. > Is "XML" a general language? Is "XHTML" a dialect? Is "XSLT" a > language and "XSLT used with XSL FOs" a dialect? Please don't > appeal to my common sense or intuition because I have neither and > unfortunately neither does my Pentium 233. It depends on your perspective. Since we're talking about Namespaces in XML documents, then XML itself is the universe, so you can remove it from the equation. XSLT and XSL FOs are separate languages that happen to work well together because they don't really compete (unlike two natural languages, and more like, say, Algebra and English). Of course, we won't know this for certain until there are enough implementations of XSLT and XSL FOs to see how people are using them -- the proof is in the implementation, not the design. 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 tyler at infinet.com Fri Sep 17 06:04:17 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:15:06 2004 Subject: XML in the real world... Was "Re: Another look atnamespaces" References: <4.1.19990916120701.0249cb80@mail.webgeek.com> <4.1.19990916181124.025d5510@mail.webgeek.com> Message-ID: <37E1BE16.B7CAAD7E@infinet.com> Ann Navarro wrote: > At 04:01 PM 9/16/99 -0400, Tyler Baker wrote: > >Ann Navarro wrote: > > > >> At 11:43 AM 9/16/99 -0400, Hunter, David wrote: > >> >(If I develop an Intranet application, I want to be able to > >> >use XHTML without clients having to run out to the W3C site regularly. > >> >Ditto for any other XML vocabularies which are defined going forward, from > >> >the W3C or anyone else.) > >> > >> It also should be noted that there's nothing precluding a cache'd copy of > >> that "thing" for that Intranet application. > > > >True, but I think all of this misses the point here. Since November 1997 > >when I started > >working with XML, I have never once found any need for a DTD or some other > >Schema language for > >the applications I have written which use XML. > > We need to be careful to remember that when working with Recommendations, > our own personal experiences aren't the only experiences that are > applicable. I personally detest frames, yet they were popular enough to > make it into previous HTML Recs. That I didn't like/need/use them didn't > invalidate their (then) usefulness. Comparing frames to schemas is like comparing apples to oranges. I don't mind a spec having lots of unnecessarily complex and perhaps generally useless features so long as they are not a prerequisite for accomplishing simple tasks at both the software level as well as the user level. "Namespaces in XML" is an add on to XHTML which effectively adds a complex and generally useless feature (as currently defined) that also happens to be a prerequisite to getting anything simple accomplished. For example, while working on an XML parser package a while back, I was considering implementing support for XSchema as I found DTD's to not do too well out of a document context. But then I started thinking "Will anyone ever need XML Schemas in the first place". As I said before, other than for the sake of having a language for expressing a data format in programmer documentation (like with EBNF), what does a schema do at the software level other than for enforcing rules in an editor? I look at XML as being more of a protocol than anything of persistent value even though I have used XML for both persistence and as a serialization protocol in the same application (a testament to XML 1.0 being simple enough to be useful for all kinds of tasks). So with respect to XHTML, again I beg the question, why do we need three HTML specs when most HTML parsers are some hack job that try and handle everything that can possibly be thrown at it?. When writing one of these very forgiving parsers, falling back on some DTD for validation will get you absolutely nothing. So even though in principle 3 XHTML namespaces might make more sense than having just one, what does this actually buy you at the software level (in other words what does it buy for the poor souls at MS and AOL who have to implement all of this stuff in the next generation of web browsers), what does it buy professional webmasters who now have to not only create specially tailored web sites for Navigator and Internet Explorer, but now may have to create web sites for these two browsers times three for each namespace, and what does it buy end-users who will need to take a bottle of Advil whenever they first hear the word "Namespace"? Remember that HTML really took off because it was simple and just about any novice computer user could whip up a web page in no time flat. What is the purpose of making things more complicated if they serve no useful purpose for the future. I mean, how are we enhancing the user experience of HTML in web browsers and other applications with having namespaces in XHTML in the first place? Having the "Namespaces in XML" spec fall into XHTML is about the worse thing you could ever do if you want the next generation of HTML to be usable by anyone other than experienced professional programmers. Even though I really could care less about HTML right now for the applications I write at the moment, I just don't like seeing an entire generation of web developers and web users have to deal with an HTML spec that has a much higher learning curve than necessary. Regards, 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 Sep 17 06:22:47 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:15:06 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" References: Message-ID: <37E1C268.6ADC9810@infinet.com> Terje Norderhaug wrote: > At 1:01 PM 9/16/99, Tyler Baker wrote: > > > >True, but I think all of this misses the point here. Since November 1997 > >when I started > >working with XML, I have never once found any need for a DTD or some other > >Schema language for > >the applications I have written which use XML. For databases, schema's I > >feel are very > >necessary, but I just have not found any real-world use for DTD's or > >schemas to date other > >than as a technical document a programmer can refer to. > > An XML editor can facilitate authoring much better if it has a DTD > available. With a DTD, the editor can provide a sophisticated user > interface that suggests the elements that can be used, where they can be > used, and their attributes. Without a DTD, the author will be required to > specify the names of each element and attribute, making authoring > cumbersome. So DTDs have real world use even if the document can be > processed without. XML is used as a base for all sorts of document and data formats. An editor which simply displays a tree diagram of XML content does not buy you much. HTML editors used to do this and still do cause some people do like to do things by hand, but really most HTML editors are WYSIWYG in nature now. XML content is generally and almost exclusively created by a script or software that uses XML as either a document format or else as a serialization protocol for some type of object. In both instances, the software almost always writes out elements directly to a stream. The point is, if you want to do redundant validation at the parser level and then at the application level, then you are always free to do so. Either way, until we have machines that actually think you are not gonna be able to just take some abstract piece of content that does not have a particular software module associated with it and do anything interesting with it. Most high-performance HTML parsers I am aware of just parse the data directly into an object tree and enforce the rules of HTML directly rather than fallback on a DTD. So again what do 3 namespaces buy you that one namespace does not even if you have 3 different DTD's for XHTML? 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 tgraham at mulberrytech.com Fri Sep 17 07:13:57 1999 From: tgraham at mulberrytech.com (Tony Graham) Date: Mon Jun 7 17:15:06 2004 Subject: Unicode surrogate block in XML? In-Reply-To: <37E16B3C.1FC56A27@valinet.com> References: <37E16B3C.1FC56A27@valinet.com> Message-ID: <14305.52871.340000.400547@menteith.com> At 16 Sep 1999 18:12 -0400, Paul W. Abrahams wrote: > The XML 1.0 spec explicitly excludes the Unicode surrogate characters > from XML documents (production 2). It now seems, from information > I've picked up on the Unicode web site, that surrogate characters are > likely to play a more important role in the future, since the > available 16-bit characters are almost all used up. (Unicode 2.0 has > 18,134 spares but Unicode 3.0 has only 7827 spares. The trend is > clear.) > > Is any thought being given in W3C to allowing surrogate characters in > XML documents? The code values from the Surrogate block (soon to be the High Surrogates, High Private Use Surrogates, and Low Surrogates) are not allowed in XML documents, but the characters that you reference with the two parts of a Surrogate Pair are definitely allowed. The characters that you can address with a Surrogate Pair are in the range #x10000 to #x10FFFF. In Unicode terminology, this is the Unicode Scalar Value of the Surrogate Pair. Production 2 from the XML Recommendation shows that these are legal characters: [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] In a UTF-16 encoded document, you can use the code values from the Surrogate block to refer to these characters. It would be an error if, for example, you used an unpaired Surrogate code value, but any UTF-16 application is going to complain about or ignore an unpaired surrogate. In a UTF-8 encoded document, you can refer to the characters in the range #x10000 to #x10FFFF using a four-byte sequence that has no relationship to the code values in the Surrogate block. In UCS-4 (or the new UTF-32) you can directly represent characters in the range #x10000 to #x10FFFF. In any XML document, you can make numeric references to any Unicode character in the range #x10000 to #x10FFFF (as well as to any other legal character number). These references are independent of the encoding used in the XML document. #x10000 is the first code value outside the Basic Multilingual Plane (the ISO/IEC 10646 term for the characters in the range #x0 to #xFFFF). "𐀀" is the hexadecimal numeric reference for this code value. The sequence of #xD800 #xDC00 is the two Surrogate code values that address #x10000. That four-byte sequence may occur in a UTF-16 encoded file to represent #x10000. In contrast, "��" in an XML document is two illegal character references in a row. Regards, Tony Graham ====================================================================== Tony Graham mailto:tgraham@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9632 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ====================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From shinichiro.hamada at toshiba.co.jp Fri Sep 17 09:23:01 1999 From: shinichiro.hamada at toshiba.co.jp (Shinichiro HAMADA) Date: Mon Jun 7 17:15:06 2004 Subject: Binary-encoding of XML for communication References: <805C62F55FFAD1118D0800805FBB428D02BBFEAB@cc20exch2.mobility.com> <3.0.5.32.19990916101657.00a6de40@corp.infoseek.com> Message-ID: <004f01bf00dd$f7cad1e0$85247385@ssel.toshiba.co.jp> Thank you for all comments! We feel severe about CPU load of the server rather than communication traffic. So we are looking for codes easy to decode into object tree. In addition to it, we also hope to keep system openness. All your comments are very helpful for us. 1 HTTP 1.1 "content-coding" 2 Use SAX 3 LZ Compression Thank you very much. -- Shinichiro HAMADA TOSHIBA Corp. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 09:44:07 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:06 2004 Subject: Another look at namespaces Message-ID: <009301bf00e1$4b8cbf20$3bf96d8c@NT.JELLIFFE.COM.AU> From: Andrew Layman >Rick Jeliffe wrote "Andrew Layman's comment that there >are definitional schemas and that these set namespaces is undebated >and can be proved wrong by the simple example of RDF, which >defines a namespace but allows major parts of schemas undefined,..." > >I recommend that you return to my original post and look at what I actually >wrote. You might be pleasantly surprised to find that I am both aware of >and support the idea of namespaces which are not defined by schemas. :-) I think second point in that posting is well-made, that "There is nothing in the namespaces specification that requires that all the elements in a document come from the same namespace". I don't think that is a contentious issue. But it is the first point, that I don't see: "If indeed there are separate languages, where the elements in one require different processing (such as different validation) from elements in another, then the distinct elements of each should be distinguished by different namespaces." This says that a schema determines the namespace. A change in content model requires a change in namespace; the namespace URI is a new doctype declaration with attribute syntax and different combining rules. ( I agree that different meanings "should" be distinguished by different namespaces, otherwise the whole use of namespaces is subverted, but to say that different validation requires different namespaces goes much to far. A schema uses names in spaces; a document uses names in spaces; a schema does not create a namespace and a document does not create a namespace (at the moment, nothing formally creates/defines a namespace, in the same way that nothing defines a URI: the URI if syntactically correct is useable for a purpose or unuseable.) It follows from Andrew's second point that if I want to use and include in it my own element then I cannot use any of the namespaces provided by XHTML. These namespaces invoke particular DTDs, and these DTDs have closed content models (if they were open, we would only need one namespace). This contrasts with the view that we can derives the items in a namespace by looking at all the schemas and documents which invoke that namespace. In the absense of a namespace definition language, containing just a simple list, that there is xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 docuverse.com Fri Sep 17 11:04:42 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:06 2004 Subject: Discourse and Discourtesies In-Reply-To: <199909170100.VAA32573@hesketh.net> Message-ID: <000501bf00ec$33342340$74bbfea9@w21tp> Frankly, I like it like this. It feels like New York without the smell. Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 docuverse.com Fri Sep 17 11:04:32 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:06 2004 Subject: Another try on groves In-Reply-To: <37E1532B.82F3BB03@prescod.net> Message-ID: <000301bf00ec$2ff60f40$74bbfea9@w21tp> Paul, Thanks for the excellent article. I am starting to see the light (although it could just be that I left the kitchen light on :). Elements and attributes are indeed crude and cumbersome to use. Script languages like JavaScript relieves some of the pain but most of the work so far has been on making HTML easier to work with and support for other document models is sadly lacking. I do have great hope for the XML Data Binding specification (see below for link) which does address half of the issues you raised. Concerns I have with XML Data Binding specification are a) it is a Java-only solution, and b) it doesn't exist yet. I also agree that node references would be far easier to work with if they behaved exactly like the referenced objects. But then it is just application of the Proxy design pattern with node identity requirement thrown in. At this point, I see the Grove concept as not something new but very old, practical, and obvious, at least to me, described in abstract ways. Its very strength, general applicability, is probably the very reason why people who understand it feel that it must be described abstractly. I do like the Grove concept and now feel that it will have its day in the Sun (sorry, JavaSoft then). However, I believe the patient must feel the pain, acutely and repeatedly, before the doctor can prescribe the cure. DOM will be used and then abandoned later for something better when the pain becomes too much. Best, Don Park Docuverse References: XML Data Binding specification: http://www.javasoft.com/aboutJava/communityprocess/jsr/jsr_031_xmld.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 steven.livingstone at scotent.co.uk Fri Sep 17 11:18:49 1999 From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM) Date: Mon Jun 7 17:15:06 2004 Subject: SOAP Message-ID: <8DCB90532FF7D211B34400805FD488536F61AC@SENMAIL3> I have created a mailing list for SOAP (Simple Object Access Protocol) for discussions relating to the recent specification sent to the IETF at http://search.ietf.org/internet-drafts/draft-box-http-soap-00.txt Please send a blannk email to rpc-soap-subscribe@onelist.com if you wish to join. Thanks for your time - Steven Steven Livingstone - http://www.deltabiz.com 07771 957 280 or +447771957280 Author - Professional Site Server 3, Wrox Press http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002696 Professional Site Server 3.0 Commerce Edition, Wrox Press http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002505 President, AIP Scotland. ceo@citix.com http://www.citix.com Join Association of Internet Professionals - http://www.citix.com/aip xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From francis at redrice.com Fri Sep 17 11:28:06 1999 From: francis at redrice.com (Francis Norton) Date: Mon Jun 7 17:15:06 2004 Subject: Another try on groves References: <37E1532B.82F3BB03@prescod.net> Message-ID: <37E20A5C.75E79B93@redrice.com> Thank you Paul. No disrespect to the more political discussions on XML-DEV, which I appreciate are inspired by deep feelings about serious issues, but I'd just like to say that this post is the kind of informative and enlightening gem that makes it worth plowing through all the traffic. Now that I have some feeling for the rationale behind Groves, I'd be very interested in knowing what this might mean for implementations. Could one come up with a language independent API like the DOM, to which Grove compliant APIs would conform? Presumably there is more complexity in that the DOM has a closed set of underlying object types whereas each Grove interface would would have different underlying object types. In Java terms, would this be an interface (a totally abstract class which guarantees a core functionality in any object which implements it)? Has anyone in fact built CORBA IDL or a Java interface defining the Grove API, or am I coming in at the wrong level? Francis. Paul Prescod wrote: [ a compelling illustration and explanation of Groves ] xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From davidc at nag.co.uk Fri Sep 17 13:11:50 1999 From: davidc at nag.co.uk (David Carlisle) Date: Mon Jun 7 17:15:06 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" Message-ID: <199909171111.MAA14708@nag.co.uk> Ann said > We need to be careful to remember that when working with Recommendations, > our own personal experiences aren't the only experiences that are > applicable. True, but personal experience is nevertheless a useful guide. Given that it is (in my experience) so much more inconvenient to use a namespace aware application (such as xslt, which is currently the most common namespace aware application) with XHTML using multiple namespaces, I have to ask, has _anyone_ who is proposing that this is a good idea actually tried using the multiple namespace approach in practice? If you are using an application that ignores the namespace declaration then arguing the finer points of which is the more correct namespace model is an interesting, but not very practical, exercise. My fear is that as the extra effort to use multiple namespaces will be too great for most people, the actual result of an XHTML with 3 namespaces will be that the vast majority of XHTML documents will not specify a namespace at all, thus making it easier to write stylesheets etc. (eg ...) This will put a broad class of XHTML documents into the null namespace which will totally break the whole intention of namespaces that would allow tools to recognise XHTML elements as XHTML rather than some other XML element that just happens to have the same name. David PS Ann, I know (from personal experience:-) what it is like to be upholding an official line in the face of multiple complaints on a public list. I admire the way in which you've kept your calm, and managed to respond to most of the incoming flood. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 14:25:25 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:15:06 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" References: <199909171111.MAA14708@nag.co.uk> Message-ID: <37E23365.9E9F1104@infinet.com> David Carlisle wrote: > My fear is that as the extra effort to use multiple namespaces will be > too great for most people, the actual result of an XHTML with 3 > namespaces will be that the vast majority of XHTML documents will > not specify a namespace at all, thus making it easier to write > stylesheets etc. (eg ...) This will put > a broad class of XHTML documents into the null namespace which will > totally break the whole intention of namespaces that would allow > tools to recognise XHTML elements as XHTML rather than some other > XML element that just happens to have the same name. I think that this is what will end up happening in the end. A long time ago in a galaxy far far away when I was working with XSL, I argued that "Namespaces in XML" will probably end up being completely unused by webmasters and the like who are after all the intended audience for XSL (now more specifically known as XSLT). I do feel that namespaces of some sort will be necessary for XML, but that ideal is far from what the W3C recommendation "Namespaces in XML" actually is. Until a decent usable "Namespaces in XML" recommendation comes out (which is unlikely but there is always hope) then developers like myself will use our own custom solutions (I have one now which works just great) for dealing with the namespaces issue in our applications. Unfortunately, those who deal with WWW content almost exclusively in their jobs, will be forced to deal with the myriad of problems "Namespaces in XML" brings to XHTML. Even if XHTML were to have just one namespace, "Namespaces in XML" really mucks things up for what I always thought HTML was supposed to be in that it is a presentation format. > David > > PS > Ann, I know (from personal experience:-) what it is like to be upholding > an official line in the face of multiple complaints on a public list. > I admire the way in which you've kept your calm, and managed to respond > to most of the incoming flood. Though I don't agree with what much of Ann has said, I do respect that she at least takes the time and energy to argue the points of the HTML WG rather than take the usual W3C line of deafening silence on issues until it is too late. Also, the fact that 99% of the posts on this list aside from Ann's are from men who need to get out more (including myself) makes it all the more encouraging to see someone like Ann challenge the incoming flood of testosterone that swamps this mailing list (-: 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 david at megginson.com Fri Sep 17 14:30:23 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:07 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <199909171111.MAA14708@nag.co.uk> References: <199909171111.MAA14708@nag.co.uk> Message-ID: <14305.64593.302542.455403@localhost.localdomain> David Carlisle writes: > True, but personal experience is nevertheless a useful guide. > Given that it is (in my experience) so much more inconvenient to > use a namespace aware application (such as xslt, which is currently the > most common namespace aware application) with XHTML using multiple > namespaces, I have to ask, has _anyone_ who is proposing that this is a > good idea actually tried using the multiple namespace approach in > practice? I can answer the second part -- I don't think that it's a good idea, but I have tried it in practice. Because RDF changed its Namespace URI at the last minute when it went to REC, there are major deployed RDF document bases (especially RPMFind and DMOZ) that use still the wrong Namespace URI for RDF, and cannot easily change to the correct URI now because they're trapped by deployed software. In two separate projects, I tried implementing support for the legacy (incorrect) Namespace URI, and doing so was trickier than I expected, because it complicates the simple hashing schemes that are necessary to process Namespace-qualified elements efficiently. For now, I've decided to support only the correct RDF-Syntax Namespace URI (the one in the final REC), but I don't imagine that DMOZ or RPMFind will be able to become conformant any time soon because they have extremely large user bases with the old Namespace URI hard-coded in their software. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From timbl at w3.org Fri Sep 17 14:44:35 1999 From: timbl at w3.org (Tim Berners-Lee) Date: Mon Jun 7 17:15:07 2004 Subject: Binary-encoding of XML for communication Message-ID: <01de01bf010a$be84d3e0$a60a1712@col.w3.org> The WAP Binary XML Encoding Specification was submitted to the W3C http://www.w3.org/Submission/1999/07/ by IBM, Ericsson, Motorola and Phone.com Dan Connolly's comments on it to put it in perspective of the W3C and XML are at http://www.w3.org/Submission/1999/07/Comment (This does *not* imply any endorsement by W3C in any way nor that is is on any path to becoming a Recommendation.) I understand that in the mobile area there is a strong need seen for binary XML. I also understand that this specification is not a generic encoding system for any XML document - but clearly this problem and some that Dan identifies may not prevent some of the ideas in the spec being used for a general standard. I know it is nice to stick with text (and compression if necessary) but if binary XML is going to happen anyway, would it not be wise for the XML community to be involved so as to ensure that it was absolutely equivalent to XML+NS? Tim BL -----Original Message----- From: Shinichiro HAMADA To: - XML-Dev Date: Thursday, September 16, 1999 7:29 AM Subject: Binary-encoding of XML for communication >Hello, all. > >We are trying to develop a Server/Clients network system with XML. In this >system, Clients read structured data and send them as XML data to a server. > >We estimate too heavy to communicate text-based XML and to decode/encode it >to/from XML object tree. So we think it's desiable to communicate XML data >as binary serialized object tree. And it's better that the binary code is >open format. > >If I remeber correctly, such a open binary XML format are discussed among a >starndard XML community. Is it true? If anyone knew anything about that, >please tell me. > >Thank you in advance. > >-- >Shinichiro HAMADA >TOSHIBA Corp. > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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 Fri Sep 17 14:47:29 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:15:07 2004 Subject: Another look at namespaces References: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <37E2357C.FDAD0C55@prescod.net> Rick Jelliffe wrote: > > It seems clear that the HTML team have some mental concept of namespaces > which exists independently of what the W3C specification actually > allows. I think that you are putting the blame in the wrong place. A quick perusal of this forum suggests that the namespace editors disagree on what the namespace specification "really means". It seems to me that the specification has proven too general, too flexible and has been shown to depend too much on mystical shared understanding of a "reasonable namespace" that turns out not to be shared. > If a W3C specs can be utterly overturned in such a way, what is their > value? There is nothing in the HTML specification that violates the text of the XML namespaces specification. If you are going to say that it violates the "spirit" of the specification then we are back where we started. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Sep 17 14:57:26 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:15:07 2004 Subject: More than three namespaces for XHTML? (was Re: What XHTML should do with namespaces) References: <00c101bf0079$362e4cb0$1ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <37E23992.32795F94@prescod.net> Rick Jelliffe wrote: > > Actually, it is an issue: if namespaces are to be taken from DTD, then > every different possible combination of modularized HTML has its own > effective DTD and will therefore need its own namespace. > > So we are not talking about 3 namespaces for XHTML, but potentially > dozens! That is not true. If schemas are paramaterizable then we can have one namespace per schema but still have only a few namespaces. In a programming language every function has a name, not every possible combinations of functions: add( multiply(1,2),multiply(3,4)) not addmultiplymultiply(1,2,3,4) Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Fri Sep 17 14:58:28 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:15:07 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" References: <4.1.19990916120701.0249cb80@mail.webgeek.com> <37E14C81.177ECBD7@infinet.com> Message-ID: <37E23614.E477FEF0@prescod.net> Tyler Baker wrote: > >... > In the case of most applications, they build there own data structures directly from an > event-based XML parser or else from some sort of object-oriented framework which delegates the > events to some sort of abstract element API. If you get an unknown form of element content, > the application can choose how to handle it as it wishes. Whether this element content is > supposed to be there is defined by programmer documentation which may include a DTD as a > reference (such as in the XSLT spec). If expected element content does not occur within the > scope of the containing element being processed, then the application can fill in the default > values as it sees fit. Part of the zen of SGML (inherited by XML) is that standards exist to protect end users from programmers. If the definitive *executable* specification for an interchange language is a software product then the that product's vendor essentially owns that language. So for instance there is an open specification for "RTF" but there is no such thing as an RTF "validator" so the definitive specification for what is or is not valid RTF is Word for Windows. End users that want to check an RTF document's conformance do so by pumping it through Word. This puts every competitor to Microsoft at a disadvantage and that in turn hurts end users. HTML has the same problem. XHTML is trying to move away from that. On the other hand, the definitive executable specification (validator) for Docbook is the DTD and Docbook producing software can be easily tested for conformance using neutral (and free) third party tools. One could imagine a world in which there were hundreds of "hand-coded" validators for RTF, HTML (there are!), and every other language but once you've written a few of these you come to think: "wouldn't it be better if there was a generalized way to do that." Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From timbl at w3.org Fri Sep 17 15:20:34 1999 From: timbl at w3.org (Tim Berners-Lee) Date: Mon Jun 7 17:15:07 2004 Subject: Another look at namespaces Message-ID: <01ec01bf010f$2b389950$a60a1712@col.w3.org> -----Original Message----- From: Tim Bray To: XML-DEV Date: Thursday, September 16, 1999 12:46 PM Subject: RE: Another look at namespaces >At 08:30 AM 9/16/99 -0700, Andrew Layman wrote: >>With all due respect to Simon St. Laurent, I believe that Tim Berners-Lee >>was correctly precise when he wrote "the document corresponding to the >>namespace URI becomes >>the place where the namespace-author can put *definitive* >>information about the intent of the namespace." > >I and many others disagree, for reasons best expressed in Jon Bosak's >summary of the issues. Among other things, I don't believe that most >interesting namespaces *have* definitive information, but have semantics >that are communicated via some messy combination of schemas, stylesheets, >prose documentation, and running code. We either have a different use of words or a very serious problem. Whereas with natural langauge, meanings change and grow and everyone has slightly different associations with a word, in computer languages we need to build on top of XML we need to have the ability to define meaning precicely in terms of other existing languages. If you believe that "HTML 4.0" specification - and a schema for XHTML - can decied that

        cannot occur in then do you not grant th ewriters of the spec the right to make that definitiove assertion (in prose or schema) whatever code someone may or may not write to produce or parse

        inside >>While there are many processes that can be applied to a document, and >>correspondingly many specifications of those processes, there can be, for a >>given term in a namespace, at most one correct *definition*. > >I disagree, I think this is a strong and surprising claim, and I would >like to see some real-world supporting evidence. We are designing this, not investigating it as a natural phenomenon. This is my understanding of the history of for example RDF and namespaces. The RDF M&S working group decided it needed a way for system designers to define new vacabularies for new data models. They realized that while using XML was something they had been asked to do, they would need a way of creating new modules of meaning. The XML working group then explainted that they were producing that functionality in XML, and so (as with atomic data types) the RDF group decided to simply hang of teh XML namespace functionality. This implies taht the meaning of an RDF property (conveyed by an XML element) is defined by the namepsace it is in. My assumption - in which I don't think I was alone - was that this meaning could be (either of course programmed strighht into a specific application) or information about it could be put into the schema. The RDF spec, indeed, defines the relationship between the name and an element of the schema (one of the bits which needs to be tracked byeween xml and rdf schemas) I had assumed that the xml schema work would allow definitive information about content models to be put into the xml schema. My understanding was also that because one document can contain information form more than one language, that one schema document, optionally available at the namespace URI, would contain both xml-schema language and rdf-schema language. This is IMHO a very nice arrangement in fact. Perhaps perception of it is clouded bythe fact that XML 1.0 doesn't mention namespaces at all, and XML NS does not mention schemas at all. In other words, the specs -- having to only refer backwards in time -- have not been good at pointing to how the future architecure will fit together. Tim BL in no official capacity. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken at bitsko.slc.ut.us Fri Sep 17 15:24:14 1999 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Mon Jun 7 17:15:07 2004 Subject: Another try on groves In-Reply-To: Francis Norton's message of "Fri, 17 Sep 1999 10:31:08 +0100" References: <37E1532B.82F3BB03@prescod.net> <37E20A5C.75E79B93@redrice.com> Message-ID: Francis Norton writes: > Now that I have some feeling for the rationale behind Groves, I'd be > very interested in knowing what this might mean for implementations. > > Could one come up with a language independent API like the DOM, to > which Grove compliant APIs would conform? Presumably there is more > complexity in that the DOM has a closed set of underlying object > types whereas each Grove interface would would have different > underlying object types. In Java terms, would this be an interface > (a totally abstract class which guarantees a core functionality in > any object which implements it)? Has anyone in fact built CORBA IDL > or a Java interface defining the Grove API, or am I coming in at the > wrong level? I'd like to believe you're coming in at the wrong level. Many languages have built-in syntax to access ``members of objects'' or ``fields of records'' that can often be applied to accessing ``properties of nodes''. In this case, the grove API is the language's native syntax. Where native syntax is not applicable, groves most closely resemble container classes (dictionaries, mappings, hash tables; lists, arrays, sequences). Again, a language's standard container class interface or protocol can be used. -- Ken MacLeod ken@bitsko.slc.ut.us xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 15:28:25 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:07 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <37E23614.E477FEF0@prescod.net> References: <4.1.19990916120701.0249cb80@mail.webgeek.com> <37E14C81.177ECBD7@infinet.com> <37E23614.E477FEF0@prescod.net> Message-ID: <14306.2524.155954.17889@localhost.localdomain> Paul Prescod writes: > Part of the zen of SGML (inherited by XML) is that standards exist > to protect end users from programmers. Unfortunately, standards can end up protecting end users from programmers so effectively that the end users end up with no off-the-shelf software: that's why it's a good idea for standards never to go more than one step ahead of current practice. Remember, the main goals of computer standards are interoperability and shared development cost. Many SGML (or CORBA, or what-have-you) consulting shops rely on exactly the opposite: they make their money by developing expensive, customized solutions that are only marginally interoperable, while holding the standards flag over the poor customer's eyes. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 17 15:32:10 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:07 2004 Subject: XML in the real world... Was "Re: Another look atnamespaces" In-Reply-To: <37E1BE16.B7CAAD7E@infinet.com> References: <4.1.19990916120701.0249cb80@mail.webgeek.com> <4.1.19990916181124.025d5510@mail.webgeek.com> Message-ID: <4.1.19990917092914.02187680@mail.webgeek.com> At 12:05 AM 9/17/99 -0400, Tyler Baker wrote: > >So with respect to XHTML, again I beg the question, why do we need three HTML >specs when most HTML parsers are some hack job that try and handle >everything that >can possibly be thrown at it?. When writing one of these very forgiving >parsers, >falling back on some DTD for validation will get you absolutely nothing. For current HTML parsers, you need exactly *zero* namespaces. They aren't aware of them. They ignore them. (The same could be said for DTDs on the rendering side of things, though authoring is greatly aided by their inclusion). There is no learning curve in regards to namespaces for the developer of XHTML documents that will be served on today's Internet as text/html. Zero. None. Since XHTML is also XML, namespaces may be used there, which is why we currently have: >So even though in principle 3 XHTML namespaces might make more sense than having just one Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Fri Sep 17 15:39:02 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:15:07 2004 Subject: Another look at namespaces References: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <000001bf0068$8d5f6020$15a8fea9@w21tp> <14305.20165.688555.834528@localhost.localdomain> Message-ID: <37E23B93.55EAD264@mecomnet.de> David Megginson wrote: > > > I cannot remember Tim Bray's exact wording, but he said something like > "programs can use qualified names they recognize as triggers for > processing behaviour". That (or whatever he actually said) is the > best summary of Namespaces that's come out so far. Perhaps his exact wording is to be preferred. The stated summary conflates the identity of the name with the mechanism used to ensure and/or establish that identity. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 17 15:42:07 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:07 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <199909171111.MAA14708@nag.co.uk> Message-ID: <4.1.19990917094025.0218f320@mail.webgeek.com> At 12:11 PM 9/17/99 +0100, David Carlisle wrote: >Ann, I know (from personal experience:-) what it is like to be upholding >an official line in the face of multiple complaints on a public list. >I admire the way in which you've kept your calm, and managed to respond >to most of the incoming flood. While it may be the "official" line, it is indeed one I firmly believe in, which I suppose makes it a bit easier. Best, Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Sep 17 15:44:25 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:07 2004 Subject: Schemas considered dangerous (was Re: Another look at namespaces) In-Reply-To: <01ec01bf010f$2b389950$a60a1712@col.w3.org> References: <01ec01bf010f$2b389950$a60a1712@col.w3.org> Message-ID: <14306.3491.65052.793942@localhost.localdomain> Tim Berners-Lee writes: > Perhaps perception of it is clouded bythe fact that XML 1.0 doesn't > mention namespaces at all, and XML NS does not mention schemas at > all. In other words, the specs -- having to only refer backwards > in time -- have not been good at pointing to how the future > architecure will fit together. There's also the critically-important point that most programming languages (such as C++ and Java) do the equivalent of schema processing at compile time (where it's secure and not time-critical), while XML processors will have to do it at run time. That means that there are a few potentially-nasty problems: 1. The burdon of determining inheritance and class relationships falls on the processor, which has to repeat it for each cycle. 2. Processing time is not predictable, since schemas can reference other schemas to an unknown depth. 3. Processing is not secure, since schemas will likely be able to refer to schemas at other sites. For example of the third problem (which is the most serious), let's imagine that I have the following document: Tim Berners-Lee David Megginson

        We'll have the new product ready next month: please remember that this is confidential.

        Now, my 'memo' schema says that it is derived from a 'memo' schema hosted at the W3C site: http://www.megginson.com/ns/memo/ is a kind of http://www.w3.org/schemas/memo# Assume that the schema at the W3C site has the schema equivalent of the following DTD construction: That means that, by default, my memo is confidential. Now, what if someone cracks the W3C's Web site (not mine), and changes this to the equivalent of I write my memo, send it to my document system, and it automatically displays it on my public Web site. Ouch! 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 ann at webgeek.com Fri Sep 17 15:46:03 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:07 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <37E23365.9E9F1104@infinet.com> References: <199909171111.MAA14708@nag.co.uk> Message-ID: <4.1.19990917094330.0251cd90@mail.webgeek.com> At 08:26 AM 9/17/99 -0400, Tyler Baker wrote: > Unfortunately, those who deal with WWW content almost >exclusively in their jobs, >will be forced to deal with the myriad of problems "Namespaces in XML" >brings to XHTML. Even >if XHTML were to have just one namespace, "Namespaces in XML" really mucks >things up for what >I always thought HTML was supposed to be in that it is a presentation format. It's assertions like this that honestly confuse me. WWW content,rendered on today's HTML browsers, cares not a whit about namespaces, so how does having 3 complicate your life more than 1? We effectively have "0" since the browsers don't use, acknowledge, or appreciate the namespace. > Also, the fact that 99% of >the posts on this >list aside from Ann's are from men who need to get out more (including >myself) makes it all >the more encouraging to see someone like Ann challenge the incoming flood of >testosterone that >swamps this mailing list (-: Would it help to know that in my "previous life" (of most of my 20s), I spent nearly 10 years in the radio control room at the police department, effectively telling 30-50 men where to go all night? ;) Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Sep 17 15:46:19 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:07 2004 Subject: XML in the real world... Was "Re: Another look atnamespaces" In-Reply-To: <4.1.19990917092914.02187680@mail.webgeek.com> References: <4.1.19990916120701.0249cb80@mail.webgeek.com> <4.1.19990916181124.025d5510@mail.webgeek.com> <4.1.19990917092914.02187680@mail.webgeek.com> Message-ID: <14306.3604.241818.960359@localhost.localdomain> Ann Navarro writes: > For current HTML parsers, you need exactly *zero* namespaces. They aren't > aware of them. They ignore them. (The same could be said for DTDs on the > rendering side of things, though authoring is greatly aided by their > inclusion). That's not entirely true -- MSIE 5, which is very widely deployed, *does* know about and use Namespaces for everything but HTML (because there's not a standard HTML Namespace yet). I think that Mozilla either does the same or is about to. 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 ann at webgeek.com Fri Sep 17 15:47:13 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:08 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <14305.64593.302542.455403@localhost.localdomain> References: <199909171111.MAA14708@nag.co.uk> <199909171111.MAA14708@nag.co.uk> Message-ID: <4.1.19990917094707.0218e8a0@mail.webgeek.com> At 04:31 AM 9/17/99 -0400, David Megginson wrote: >but I don't imagine that DMOZ or RPMFind will be >able to become conformant any time soon because they have extremely >large user bases with the old Namespace URI hard-coded in their >software. In all objectiveness, isn't that more a problem of it being "hard coded" than of a change in URI? Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Sep 17 15:52:08 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:08 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <4.1.19990917094707.0218e8a0@mail.webgeek.com> References: <199909171111.MAA14708@nag.co.uk> <4.1.19990917094707.0218e8a0@mail.webgeek.com> Message-ID: <14306.3962.279889.493297@localhost.localdomain> Ann Navarro writes: > >but I don't imagine that DMOZ or RPMFind will be > >able to become conformant any time soon because they have extremely > >large user bases with the old Namespace URI hard-coded in their > >software. > > In all objectiveness, isn't that more a problem of it being "hard > coded" than of a change in URI? That's the whole point of this discussion: Namespace URIs are necessarily hard-coded in documents and applications. That's why many of us want exactly one, persistent XHTML Namespace URI. In this case, DMOZ and RPMFind did hard-code the Namespace URI before RDF-Syntax went to REC, so technically, they're to blame; however, it is unfortunately that the last-minute change robbed RDF of the chance of having two very highly-visible and heavily-used conformant implementations. 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 Sep 17 15:55:04 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:15:08 2004 Subject: Abusing namespaces References: <4.1.19990916122123.0248fbf0@mail.webgeek.com> <199909161602.MAA09307@hesketh.net> <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <4.1.19990916124455.024a9eb0@mail.webgeek.com> Message-ID: <37E23A67.CFDD973C@prescod.net> Ann Navarro wrote: > > I'm arguing that each flavor of XHTML is sufficiently different (idiom, > dialect, what have you) that it deserves a different namespace. Don't fall into this trap. Once we start quantifying differences based on percentages of shared idioms we are into the land of voodoo standardization. We have three grammars. According to Chomsky and "formal languages 201" this means we have three languages. I'll be happy to discard Chomsky (what has he done for me LATELY) if someone comes up with something better. But I won't discard something I can implement in code in favor of "I can't define a dialect but I know it when I see it." I can't code to that and the scary thing is that Microsoft, Oracle and Netscape can't either: so we are opening ourselves up to abuse. "ORAHTML is a *dialect* of HTML so it uses the same namespace. It crashes our competitor's products but that's not our problem." If the defining characteristic of HTML is a single finite grammar then we are safe. When we finish a well-defined extensibility model, we can allow extensibility. Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 17 16:06:46 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:08 2004 Subject: XML in the real world... Was "Re: Another look atnamespaces" In-Reply-To: <14306.3604.241818.960359@localhost.localdomain> References: <4.1.19990917092914.02187680@mail.webgeek.com> <4.1.19990916120701.0249cb80@mail.webgeek.com> <4.1.19990916181124.025d5510@mail.webgeek.com> <4.1.19990917092914.02187680@mail.webgeek.com> Message-ID: <4.1.19990917100638.025361e0@mail.webgeek.com> At 05:47 AM 9/17/99 -0400, David Megginson wrote: >Ann Navarro writes: > > > For current HTML parsers, you need exactly *zero* namespaces. They aren't > > aware of them. They ignore them. (The same could be said for DTDs on the > > rendering side of things, though authoring is greatly aided by their > > inclusion). > >That's not entirely true -- MSIE 5, which is very widely deployed, >*does* know about and use Namespaces for ******everything but HTML****** (because >there's not a standard HTML Namespace yet). I think that Mozilla >either does the same or is about to. *****everything but HTML ******* (emphasis mine) Which was my point. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 17 16:12:02 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:08 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <14306.3962.279889.493297@localhost.localdomain> References: <4.1.19990917094707.0218e8a0@mail.webgeek.com> <199909171111.MAA14708@nag.co.uk> <4.1.19990917094707.0218e8a0@mail.webgeek.com> Message-ID: <4.1.19990917101151.02532f10@mail.webgeek.com> At 05:52 AM 9/17/99 -0400, David Megginson wrote: >That's the whole point of this discussion: Namespace URIs are >necessarily hard-coded in documents and applications. Documents, perhaps, but I haven't seen "necessarily" for applications. ? Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata.makoto at fujixerox.co.jp Fri Sep 17 16:18:05 1999 From: murata.makoto at fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:15:08 2004 Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial) Message-ID: <199909171422.AA02003@archlute.fujixerox.co.jp> John Cowan writes: >This is version 0.1 of a proposed technical corrigendum to XML 1.0 >to incorporate the new characters of Unicode 3.0 into the allowable >sets used in XML Names. It presumes that XML should not >remain limited to an obsolete version of the Unicode and ISO 10646 >standards. I love the idea. This is certainly a great improvement. I have one question. Is U+30FB (Katakana Middle Dot) a name character in Unicode 3.0? I had a look at the WWW site of the Unicode Consortium, but I could not find any information about it. Omission of this character in Unicode (and thus XML) is very serious. This character is so common. It is a very bad error of Unicode nameing rule. In a meeting of Japanese Standardization Association, I was asked why this character is not allowed as a name character in XML. Some users asked the same question in an XML mailing list in Japan. This character is needed very very badly. I have spoken with some members of UTC and repeatedly asked them to make this change. But I am still not sure if Unicode 3.0 allows this character as a name character. The second version of ISO TR 10176:1998 (Guideline for preparation of programming language) also has a rule for name characters. This rule allows U+30FB as a name character. In the property list of Unicode, U+30FB is classified as hyphens. Property dump for: 0x20000800 (Hyphen) 002D 00AD 058A 1806 2010..2011 (2 chars) 30FB FE63 FF0D FF65 If we cannot handle U+30FB as an exception, we can allow all these characters except FE63, FF0D, FF65. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata.makoto@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 david at megginson.com Fri Sep 17 16:18:26 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:08 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <4.1.19990917094330.0251cd90@mail.webgeek.com> References: <199909171111.MAA14708@nag.co.uk> <4.1.19990917094330.0251cd90@mail.webgeek.com> Message-ID: <14306.5515.101185.963225@localhost.localdomain> Ann Navarro writes: > It's assertions like this that honestly confuse me. WWW content,rendered on > today's HTML browsers, cares not a whit about namespaces, so how does > having 3 complicate your life more than 1? I and others have pointed out several times that this assertion is not true -- I know for certain that version 5 of Internet Explorer does use Namespaces, and I think that Mozilla does 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 ann at webgeek.com Fri Sep 17 16:20:22 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:08 2004 Subject: Abusing namespaces In-Reply-To: <37E23A67.CFDD973C@prescod.net> References: <4.1.19990916122123.0248fbf0@mail.webgeek.com> <199909161602.MAA09307@hesketh.net> <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <4.1.19990916124455.024a9eb0@mail.webgeek.com> Message-ID: <4.1.19990917101952.0253ee80@mail.webgeek.com> At 02:56 PM 9/17/99 +0200, Paul Prescod wrote: >Ann Navarro wrote: >> >> I'm arguing that each flavor of XHTML is sufficiently different (idiom, >> dialect, what have you) that it deserves a different namespace. > >Don't fall into this trap. Once we start quantifying differences based >on percentages of shared idioms we are into the land of voodoo >standardization. > >We have three grammars. According to Chomsky and "formal languages 201" >this means we have three languages. I'll be happy to discard Chomsky >(what has he done for me LATELY) if someone comes up with something >better. Noted, and I agree. I suppose I was trying to use the language being tossed around, and in doing so, have pointed out even to myself how weak those labels are in the discussion at hand. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From davidc at nag.co.uk Fri Sep 17 16:21:48 1999 From: davidc at nag.co.uk (David Carlisle) Date: Mon Jun 7 17:15:08 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <4.1.19990917094330.0251cd90@mail.webgeek.com> (message from Ann Navarro on Fri, 17 Sep 1999 09:46:19 -0400) References: <199909171111.MAA14708@nag.co.uk> <4.1.19990917094330.0251cd90@mail.webgeek.com> Message-ID: <199909171419.PAA19834@nag.co.uk> Ann > It's assertions like this that honestly confuse me. WWW content,rendered on > today's HTML browsers, cares not a whit about namespaces, so how does > having 3 complicate your life more than 1? We effectively have "0" since > the browsers don't use, acknowledge, or appreciate the namespace. Browsers today might not, but IE5 which is essentially namespace aware would have cared except that I understand that it hard codes html: (but given there wasn't (isn't) an official namespace for html this is at least forgivable) But if you have (as surely you will soon) a namespace aware browser and want to say something like top level HTML h1 elements should be rendered bold but you don't want to affect other elements not related to html that just happen to be called h1 then with the one namespace case (using xslt syntax but that isn't really the point here) you just associate html: with the html namespace (or make that namespace the default) and then go (or ) ... in either case this styling works for current and future flavours of HTML. In the multiple namespace case it is really far more technical to write a match that will find any element with local name h1 and namespace URI beginning with a certain string. It is not just for styling, if I want to index all top level section elements I want to find all html h1 elements but not hit h1 elements from some unrelated language. the xpath expression "html:h1" (assuming xmlns:html has been suitably declared somewhere) gets me exactly what I want in the one namespace case. If you believe having separate namespaces for the three current flavours and another one, xhtml1.1 on the way, is better, then please write down the xpath expression to locate titles in HTML documents and then try to convince us that it is better. Something like "*[starts-with(namespace(.),'http://www.w3.org/xxxx') and local-name(.)='h1']" instead of "html:h1" Now perhaps you will just say it looks bad because the xpath syntax is odd but I don't think that is the reason. The reason is that in order to re-enforce the mechanisms (doctype) that an authoring tool has to guide an HTML author into the a particular flavour of HTML you are suggesting that you tell every XML namespace aware application that a frameset h1 is completely different from a transitional h1 which is completely different from an xhtml 1.1 h1. This just will confuse everybody to the point of breaking the entire system. No one will understand why they have to use the above to access HTML h1 elements, when it is `clear' that an html h1 is essentially the same thing in all flavours of html. That's why they are all called h1, and why the flavours are all called (x)html. That's why there should be one namespace. David PS Using `flavour' because `dialect' appears too contentious:-) Use flavor (I think?) if your dialect of English is different. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 16:22:10 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:08 2004 Subject: XML in the real world... Was "Re: Another look atnamespaces" In-Reply-To: <4.1.19990917100638.025361e0@mail.webgeek.com> References: <4.1.19990917092914.02187680@mail.webgeek.com> <4.1.19990916120701.0249cb80@mail.webgeek.com> <4.1.19990916181124.025d5510@mail.webgeek.com> <4.1.19990917100638.025361e0@mail.webgeek.com> Message-ID: <14306.5760.20065.372291@localhost.localdomain> Ann Navarro writes: > >That's not entirely true -- MSIE 5, which is very widely deployed, > >*does* know about and use Namespaces for ******everything but HTML****** > (because > >there's not a standard HTML Namespace yet). I think that Mozilla > >either does the same or is about to. > > *****everything but HTML ******* (emphasis mine) > > Which was my point. They still use Namespaces in HTML documents, though -- it's just HTML itself that lacks a Namespace. It's a crime, really, that they ended up having to hard-code the 'html' prefix for lack of a standard Namespace. We (and I include myself) really missed the boat on that one: it's a rare opportunity where the W3C could actually have made a difference in deployed software, and MS would have been happy for the guidance. Now we already face the possibility of nasty inter-op problems. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at docuverse.com Fri Sep 17 16:31:30 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:08 2004 Subject: Binary-encoding of XML for communication In-Reply-To: <01de01bf010a$be84d3e0$a60a1712@col.w3.org> Message-ID: <000201bf0119$c27dd5a0$74bbfea9@w21tp> >I know it is nice to stick with text (and compression if >necessary) but if binary XML is going to happen anyway, >would it not be wise for the XML community to be involved >so as to ensure that it was absolutely equivalent to XML+NS? I believe binary XML is inevitable. XML, as a concept, is not specific to text and certain applications will require binary XML for performance, environment constraints, etc. One caveat is that it is difficult to come up with one binary format that fits all situations. XML is already being compressed via modems as Andrew mentioned, but as broadband use increases the compression factor will be lost. Some might argue that compression is not necessary when broadband is the norm but I think not. Waste is waste and bandwidth is like memory in that one can never have enough. I am with TimBL on the issue with binary XML. WAP is all right but not good enough for general use. We need to put our heads together and squeeze one out. I think it should support exactly one namespace (just kidding :). Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Sep 17 16:34:26 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:08 2004 Subject: Abusing namespaces References: <4.1.19990916122123.0248fbf0@mail.webgeek.com> <199909161602.MAA09307@hesketh.net> <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <4.1.19990916124455.024a9eb0@mail.webgeek.com> <37E23A67.CFDD973C@prescod.net> Message-ID: <37E251C9.DF27E7EA@pacbell.net> Paul Prescod wrote: > > We have three grammars. According to Chomsky and "formal languages 201" > this means we have three languages. Curiously, that's _not_ what the HTML spec says. I'm amused that nobody from W3C has responded to my points that the HTML spec uses language like "ONE LANGUAGE" and "THE LANGUAGE" (emphasis added) concurrently with its "three DTDs" wording ... so the W3C is inconsistent in its use of terminology, since the terms actually used in the HTML spec do not support the stance defending XHTML. My radar always starts malfunctioning when I'm trying to have a rational discussion with folk who redefine terminology to support their points, as soon as it gets inconvenient. The HTML world is sufficiently imprecise that the formal languges perspective isn't applicable in any straightforward manner. Else surely over 90% of the HTML in the world would not be viewable in a browser -- it'd get rejected as rife with syntax errors. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 17 16:37:18 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:09 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <14306.5515.101185.963225@localhost.localdomain> References: <4.1.19990917094330.0251cd90@mail.webgeek.com> <199909171111.MAA14708@nag.co.uk> <4.1.19990917094330.0251cd90@mail.webgeek.com> Message-ID: <4.1.19990917103725.0253aaf0@mail.webgeek.com> At 06:18 AM 9/17/99 -0400, David Megginson wrote: >Ann Navarro writes: > > > It's assertions like this that honestly confuse me. WWW content,rendered on > > today's HTML browsers, cares not a whit about namespaces, so how does > > having 3 complicate your life more than 1? > >I and others have pointed out several times that this assertion is not >true -- I know for certain that version 5 of Internet Explorer does >use Namespaces, and I think that Mozilla does as well. For HTML. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Sep 17 16:38:28 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:09 2004 Subject: Another look at namespaces References: <006101beffba$a2984280$a60a1712@col.w3.org> <4.1.19990916092628.02454100@mail.webgeek.com> Message-ID: <37E2529D.B4A6AE83@pacbell.net> Ann Navarro wrote: > > At 02:12 AM 9/16/99 -0700, David Brownell wrote: > > >> The exciting use of namespaces in schemas will be when ... > > > >That's all quite true! But it doesn't require any inflexible > >one-to-one association of namespace URIs and schemas (or DTDs). > > I've yet to see anyone assert that it must. That was the gist of Tim's point that the "definitive" schema would be found at the end of the namespace URI. Something can't be both optional and definitive in that way ... if it's optional, some other way could be be at least as correct/definitive. - 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 Sep 17 16:41:17 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:09 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <4.1.19990917103725.0253aaf0@mail.webgeek.com> References: <4.1.19990917094330.0251cd90@mail.webgeek.com> <199909171111.MAA14708@nag.co.uk> <4.1.19990917103725.0253aaf0@mail.webgeek.com> Message-ID: <14306.6895.781035.218125@localhost.localdomain> Ann Navarro writes: > At 06:18 AM 9/17/99 -0400, David Megginson wrote: > >Ann Navarro writes: > > > > > It's assertions like this that honestly confuse me. WWW content,rendered on > > > today's HTML browsers, cares not a whit about namespaces, so how does > > > having 3 complicate your life more than 1? > > > >I and others have pointed out several times that this assertion is not > >true -- I know for certain that version 5 of Internet Explorer does > >use Namespaces, and I think that Mozilla does as well. > > For HTML. That's tautological -- since there isn't a standard Namespace for HTML, browsers can hardly use a standard HTML Namespace. The proof of the success (and necessity) of Namespaces is that browsers are using Namespaces for lots of other stuff now, and they they are using Namespaces to disambiguate everything else *from* HTML in an HTML document. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 17 16:44:17 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:09 2004 Subject: Another look at namespaces In-Reply-To: <37E2529D.B4A6AE83@pacbell.net> References: <006101beffba$a2984280$a60a1712@col.w3.org> <4.1.19990916092628.02454100@mail.webgeek.com> Message-ID: <4.1.19990917104404.0254a100@mail.webgeek.com> At 07:39 AM 9/17/99 -0700, David Brownell wrote: >Something can't be both optional and definitive in that >way ... if it's optional, some other way could be be >at least as correct/definitive. Yes, it very well could. I don't see them as being mutually exclusive. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at docuverse.com Fri Sep 17 16:45:53 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:09 2004 Subject: A compromise? Message-ID: <000401bf011b$dc47c8e0$74bbfea9@w21tp> What if we came up with a way to associate a schema with any element without using namespace? Would it address the real concerns of the HTML WG? Something like: Hello, world! blah blah Except it doesn't use the !DOCTYPE. How about it? Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Fri Sep 17 17:04:49 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:09 2004 Subject: XML in the real world... Was "Re: Another look at namespaces" In-Reply-To: <14306.6895.781035.218125@localhost.localdomain> References: <4.1.19990917103725.0253aaf0@mail.webgeek.com> <4.1.19990917094330.0251cd90@mail.webgeek.com> <199909171111.MAA14708@nag.co.uk> <4.1.19990917103725.0253aaf0@mail.webgeek.com> Message-ID: <4.1.19990917110449.02391f00@mail.webgeek.com> At 06:41 AM 9/17/99 -0400, David Megginson wrote: >Namespaces for lots of other stuff now, and they they are using >Namespaces to disambiguate everything else *from* HTML in an HTML >document. Except that you can't have a valid HTML document that has "everything else" in it. MS may have cobbled the 'html' namespace to allow their xml-islands approach, but it's operating outside the spec as you've pointed out. Ann --- Author of Effective Web Design: Master the Essentials Coming in September --- Mastering XML Founder, WebGeek Communications http://www.webgeek.com Vice President-Finance, HTML Writers Guild http://www.hwg.org Director, HWG Online Education http://www.hwg.org/services/classes xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Sep 17 17:06:46 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:09 2004 Subject: Another look at namespaces References: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU> <37E2357C.FDAD0C55@prescod.net> Message-ID: <37E2593B.2C01A3C@pacbell.net> Paul Prescod wrote: > > Rick Jelliffe wrote: > > > > It seems clear that the HTML team have some mental concept of namespaces > > which exists independently of what the W3C specification actually > > allows. > > I think that you are putting the blame in the wrong place. A quick > perusal of this forum suggests that the namespace editors disagree on > what the namespace specification "really means". It seems to me that the > specification has proven too general, too flexible and has been shown to > depend too much on mystical shared understanding of a "reasonable > namespace" that turns out not to be shared. The namespaces spec did sort of get rushed through at the last minute, with a PR that said "this is how it'll be, don't bother sending any comments unless you can prove the sky is falling". As of course it could not be. Perhaps a lot of the current problems with XHTML map to such issues. Rush one spec through with some open issues, and then watch the issues multiply as time goes by. - 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 grove at infotek.no Fri Sep 17 17:08:35 1999 From: grove at infotek.no (Geir Ove Grønmo) Date: Mon Jun 7 17:15:09 2004 Subject: Another try on groves In-Reply-To: References: <37E1532B.82F3BB03@prescod.net> <37E20A5C.75E79B93@redrice.com> Message-ID: * Ken MacLeod | Francis Norton writes: | | > Now that I have some feeling for the rationale behind Groves, I'd be | > very interested in knowing what this might mean for implementations. | > | > Could one come up with a language independent API like the DOM, to | > which Grove compliant APIs would conform? Presumably there is more | > complexity in that the DOM has a closed set of underlying object | > types whereas each Grove interface would would have different | > underlying object types. In Java terms, would this be an interface | > (a totally abstract class which guarantees a core functionality in | > any object which implements it)? Has anyone in fact built CORBA IDL | > or a Java interface defining the Grove API, or am I coming in at the | > wrong level? | | I'd like to believe you're coming in at the wrong level. Many | languages have built-in syntax to access ``members of objects'' or | ``fields of records'' that can often be applied to accessing | ``properties of nodes''. In this case, the grove API is the | language's native syntax. | | Where native syntax is not applicable, groves most closely resemble | container classes (dictionaries, mappings, hash tables; lists, arrays, | sequences). Again, a language's standard container class interface or | protocol can be used. Yes. Think of it more as a data structure instead of as an API, since there are no methods involved. Geir O. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken at bitsko.slc.ut.us Fri Sep 17 17:37:28 1999 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Mon Jun 7 17:15:09 2004 Subject: groves.org already taken Message-ID: I've found a domain, web, and mail hosting site that could host a grove home, but the obvious ``grove.org'' and ``groves.org'' are already taken. Suggestions for other possible names are welcome. Ideas we've already come up with are: opengroves.org grovemodel.org www.xml.com/groves -- Ken MacLeod ken@bitsko.slc.ut.us xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Sep 17 17:45:55 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:09 2004 Subject: Another look at namespaces References: <006101beffba$a2984280$a60a1712@col.w3.org> <4.1.19990916092628.02454100@mail.webgeek.com> <4.1.19990917104404.0254a100@mail.webgeek.com> Message-ID: <37E26274.903E443F@pacbell.net> Ann Navarro wrote: > > At 07:39 AM 9/17/99 -0700, David Brownell wrote: > > >Something can't be both optional and definitive in that > >way ... if it's optional, some other way could be be > >at least as correct/definitive. > > Yes, it very well could. I don't see them as being mutually exclusive. If an alternative can be more correct, then how could that one approach (overloading the namespace URI to point to one type of schema information) possibly be definitive ??? Perhaps you could elaborate on your logic here, concretely in the case of XHTML. There are a lot of issues that seem to get conflated in this XHTML-oriented namespace discussion: - "what's a language" ... side issue except that the HTML spec ("one language") is claimed to describe three ("three DTDs") and this ties to the next issue - "how do namespaces and DTDs relate" ... HTML WG has chosen a 1-1 mapping, which stance isn't in the least bit conservative (causing trouble) - "how do namespaces and schemas relate" ... not yet answerable, and also not the same as the DTD issue, since what different sorts of schemas will do/say/mean is still under discussion - "what do namespaces signify" ... the namespace spec says namespaces are used to disambiguate _names_ but some attribute more to it than that (notably wanting schema coupling approaches) The problem with the WG's non-conservative stance is clearly that it's in conflict with a lot of things that the developer community is doing, which IS conservatively following that namespace spec: using namespace URIs to indicate _only_ the vocabulary selection, and using other mechanisms to establish couplings for various types of semantics. (Where "validity" checking is one kind of optional semantic constraint.) Perhaps rather than arguing about who's right and who's wrong, or trying to argue vision statements, the discussion could more usefully be about how the HTML WG can more usefully work with the XML developer community it's targetting with XHTML. That relationship is clearly not collaborative today; it should be. - 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 Fri Sep 17 18:08:08 1999 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:15:09 2004 Subject: Another look at namespaces References: <01ec01bf010f$2b389950$a60a1712@col.w3.org> Message-ID: <37E2680C.64449633@mecomnet.de> Tim Berners-Lee wrote: > > > We either have a different use of words or a very serious > problem. I suspect the potential for a serious problem. > Whereas with natural langauge, meanings change and > grow and everyone has slightly different associations with a word, > in computer languages we need to build on top of XML we need > to have the ability to define meaning precicely in terms of > other existing languages. > > If you believe that "HTML 4.0" specification - and a schema for XHTML - > can decied that

        cannot occur in then do you not grant > th ewriters of the spec the right to make that definitiove assertion (in > prose > or schema) whatever code someone may or may not write to produce or > parse

        inside Yes, but with respect to the DTD, not the namespace. There are no grounds to take issue with the XHTML specification where it prescribes a specific interpretation to the element <{http://www.w3.org/TR/xhtml1/strict}p> in the presence of the respective document type declaration but any claims that the interpretation should arise directly from the evocation of the namespace "{http://www.w3.org/TR/xhtml1/strict}p" are misleading. That is, the permission granted in 3.1.1#4, that the external identifier need not be present, ascribes to the respective root xmlns attribute a meaning which is neither asserted in the namespace recommendation, nor adequately specified in the XHTML pr itself. In this regard, i have two questions: 1) what is the status of a document which "evokes" the namespace "http://www.w3.org/TR/xhtml1/DTD/strict.dtd" but contains no document type declaration? Is it XHTML conformant but of indeterminate XML validity? 2) what is the status of a document which "evokes" this namespace, but contains a document type declaration with respective element declarations which differ from those in the above mentioned dtd? I suspect that it is XHTML non-conformant but of determinate XML validity ie. the evocation of the namespace is, in itself, immaterial. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Sep 17 18:09:32 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:09 2004 Subject: A compromise? References: <000401bf011b$dc47c8e0$74bbfea9@w21tp> Message-ID: <37E2682E.7CEAB54B@pacbell.net> Don Park wrote: > > What if we came up with a way to associate a schema with any element without > using namespace? Would it address the real concerns of the HTML WG? I'm also curious why the HTML WG should care, since (X)HTML has only DTDs (currently three of them) for which there's already a standard association technique: Seems to me that the best compromise is to stick exclusively to what is already accepted -- ruling out schemas. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Fri Sep 17 18:21:42 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:09 2004 Subject: Associating Element Node to Document Node References: <8B049D471C61D111847C00805FA67B1C03239D00@usa0129ms1.ess.mc.xerox.com> Message-ID: <37E26B07.7A398B7@pacbell.net> For the record, I replied privately that package-internal property APIs like setOwnerDocument() shouldn't be used here. There's a public XmlDocument.changeNodeOwner() method that does the job nicely, including all the additional checks needed in a public API. Since it's a computed property, "nodeOwner" wasn't intended to look like a simple JavaBeans property. - Dave "Goyal, Sanjeev" wrote: > > I am using Sun's XML Parser and DOM implementation (Java Project X Core > Library TR2) > > -----Original Message----- > From: Goyal, Sanjeev > Sent: Monday, September 13, 1999 6:20 PM > To: 'xml-dev@ic.ac.uk'; 'xml-feedback@java.sun.com' > Subject: Associating Element Node to Document Node > > Hi, > > I want to associate a ElementNode to a Document before I append the > Element to DocumentNode. Basically, I am specializing the ElementNode and > writing my own element nodes. I have a specific requirements to do that. > Following is the code snippet: > > public class TestNode extends ElementNode > { > public TestNode(XmlDocument parentDoc) > { > super(); > setTag("SIFNode"); > setOwnerDocument(parentDoc); > } > > } > > I am not able to use the setOwnerDocument() API. Please help me in > this regard. > > Thanks, > Sanjeev > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 mnutter at fore.com Fri Sep 17 18:58:07 1999 From: mnutter at fore.com (Mark Nutter) Date: Mon Jun 7 17:15:09 2004 Subject: groves.org already taken In-Reply-To: Message-ID: <4.2.0.58.19990917123418.00c9ca00@pophost1.fore.com> At 10:37 AM 09/17/99 -0500, Ken MacLeod wrote: >I've found a domain, web, and mail hosting site that could host a >grove home, but the obvious ``grove.org'' and ``groves.org'' are >already taken. Suggestions for other possible names are welcome. >Ideas we've already come up with are: > > opengroves.org > grovemodel.org > www.xml.com/groves "groves-r-us.org"? :-) Seriously, I like grovemodel.org the best. Actually, I like xml.org/groves best, but I have the impression it rather implies that groves are strictly an xml thing -- IOW it risks giving a false impression. On the other hand, that might be a trivial objection rather than a real, practical difficulty. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Mark Nutter, Internet Applications Developer FORE Systems Some people are atheists 'til the day they die. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From malliks at rocketmail.com Fri Sep 17 18:58:13 1999 From: malliks at rocketmail.com (Mallikarjuna Sangappa) Date: Mon Jun 7 17:15:09 2004 Subject: XML Schemas in XT Message-ID: <19990917170005.8277.rocketmail@web4.rocketmail.com> Hi, Is it possible to translate XML Documents created out of XML Schemas instead of XML DTDs? TIA. Mallik _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Sep 17 19:50:23 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:15:09 2004 Subject: On a more pleasant note Message-ID: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca> There's been a lot of angst around here recently. On a countervailing note: I am building this big hairy complicated app in which a web server traverses an extremely complex database, extracts some dense information structures, sends them to a client, and the client does some nifty rendition tricks. Building the database is hard. Traversing the database is hard. Doing the rendition on the client is hard. But generating the message on the server takes one little C subroutine (printf calls, nothing fancy), and extracting the information from it on the client (using an XML parser, it doesn't matter which) is one little Java routine. The client-side worked first time, the server-side on the second (I wasn't escaping some &'s properly, which the XML parser on the client caught first time through). All the rest is done by Apache and Linux and Windows and TCP/IP and HTTP and java.net.URL and the XML parser. It took maybe an hour to build both sides. Seems to me that this is the right way to build distributed applications. -Tim PS: In the XML I'm sending out from the server, I am embedding some human readable text encoded, obviously enough, in HTML. What would be a good way to distinguish it from my own XML tags so that I can extract it and feed it to the HTML renderer? Any suggestions? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 20:24:51 1999 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:15:10 2004 Subject: On a more pleasant note In-Reply-To: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca> References: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca> Message-ID: <19990917142707.D3880@w3.org> > Building the database is hard. Traversing the database is hard. Doing the > rendition on the client is hard. But generating the message on the server > takes one little C subroutine (printf calls, nothing fancy), and extracting > the information from it on the client (using an XML parser, it doesn't > matter which) is one little Java routine. The client-side worked first > time, the server-side on the second (I wasn't escaping some &'s properly, > which the XML parser on the client caught first time through). All the > rest is done by Apache and Linux and Windows and TCP/IP and HTTP and > java.net.URL and the XML parser. It took maybe an hour to build both sides. Good :-) > Seems to me that this is the right way to build distributed applications. If this community succeeded where 20 years of research in distributed computing failed to provide, we should try to see things in an optimistic way. > PS: In the XML I'm sending out from the server, I am embedding some human > readable text encoded, obviously enough, in HTML. What would be a good way > to distinguish it from my own XML tags so that I can extract it and feed > it to the HTML renderer? Any suggestions? I bet the game is to answer "an HTML namespace" and you beat me with a stick for a few hours while asking "which one", right ;-) Daniel, obviously speaking for himself -- 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, XML, http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schen at falconwing.com Fri Sep 17 20:20:58 1999 From: schen at falconwing.com (schen@falconwing.com) Date: Mon Jun 7 17:15:10 2004 Subject: groves.org already taken In-Reply-To: <4.2.0.58.19990917123418.00c9ca00@pophost1.fore.com> Message-ID: On Fri, 17 Sep 1999, Mark Nutter wrote: > At 10:37 AM 09/17/99 -0500, Ken MacLeod wrote: > >I've found a domain, web, and mail hosting site that could host a > >grove home, but the obvious ``grove.org'' and ``groves.org'' are > >already taken. Suggestions for other possible names are welcome. > >Ideas we've already come up with are: > > > > opengroves.org > > grovemodel.org > > www.xml.com/groves > > Seriously, I like grovemodel.org the best. [ ... ] I second the motion =) So is there a call to arms here? I'd gladly collaborate with anyone else interested in defining the XML InfoSet in grove terms, and also a Java API for groves. . . . Sean. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From timbl at w3.org Fri Sep 17 20:39:01 1999 From: timbl at w3.org (Tim Berners-Lee) Date: Mon Jun 7 17:15:10 2004 Subject: Another look at namespaces Message-ID: <01ff01bf013c$2923a290$a60a1712@col.w3.org> -----Original Message----- From: Rick Jelliffe >The only information that properly belongs in a namespace is a list of >names. That is not useful. I realize that the word "Namespace" (as the end result fo the discussions of modules or docuemnt types or vocabularies or...) may be an english word which does not convey this, but a a namespaces is a language: a set of names plus a set of syntactic constraints plus - to be useful - a meaning shared by writer and recipient. That meaning can be to a certian (and, with technology, growing) extend by expressed formally in a mapping to other languages. Or is can be disccussed in the bar, a mid: URI written on the back of napkin, and used from then on by the people who were in the bar in the messages they write to each other. >All other information, however convenient, is not namespace information >but something else: what is this "intent" business? There is no mention >of >"intent" in the namespaces spec that I recall, quite the opposite. The >fundamental justification for namespace is to be free from intent. The generic Namepsaces draft only indicates how to identify names in a document by a URI of a namespace. It doesn't say anything about the meaning of any namespace because it is not that spec which allows one to talk about it. However, the namespace URI is the hookto which the whole of the rest of the system can be attached: it allows one in a schema or other document to say what the names "mean" for any particular level of "meaning". >There is no W3C method to define a namespace as list of names. There is an xml-schema spec in the works destined to do that and more. One can either take the existing specs at face value at any point in history, and not complain about the lack of functionality. Or you can work with the model which you forsee you can >There is no >W3C method to declare which schema should be used, akin to the >stylesheet declaration. Yes there is: resolution of the schema URI. >In the absense of these, of course people will >try to >turn namespaces URIs into schema declaration URLS. "URL" is a term some use to refer to a subset of URIs which have a network protocol for being dereferenced. If you access a schema fro the URI you are dereferencingthe URI whatever the number indirections you migh go through. > The W3C should >provide a proper way to define namespaces (as simple lists) and a >way to declare schemas. Forgive me if I am missing something but do you mean XML Schema Part 1: Structures http://www.w3.org/1999/05/06-xmlschema-1/ > (Furthermore, the idea of a namespace-author >being in some way the controller of the resource for a schema is bad; Why? (To eleborate a little, the publisher of a reseource is the controller of the mapping between the URI and the result of dereferencing that URI. I should have said "namespace-publisher". Authors and publishers tend to have a close understanding like a contract. But I don't think that detail is what you are getting at) >a schema identifier (or a namespace list) should be identified using >the URI equivalent of a Formal Public Identifier: I can ask some service >to provide me that schema (or that namespace list) in any format >that anyone has chosen to make available.) Of course. You could use an md5: for example or a uuid or a mid: You can do that with an HTTP URI too. You can ask anyone for a copy of http://www.w3.org/1999/05/06-xmlschema-1/ ... the HTTP 1.1 spec only gives you a cannonical way of getting a definitive copy. So longas you own the DNS name, you can use any part of HTTP space as a FPI-like space. (eg see http://purl.org/) >>While there are many processes that can be applied to a document, and >>correspondingly many specifications of those processes, there can be, >for a >>given term in a namespace, at most one correct *definition*. > >Again, the only declaration information that is proper to a namespace >is a list of names. A content model is a schema, and nothing to do with >names in a namespace, in particular. I don't understand how you say that the content model has nothing to do with the list of names. It lists the names and says how they can be combined. [...] >Again, Andrew is simply conflating schema and namespace. The idea that >he and Tim are putting forward is that a language is defined by a single >set of content models; this confuses "language" with "grammar" and >is disproved by long-standing SGML practise, (disproved by practise?) > in which variants of >a language can be defined in the same DTD (selected by marked sections, >or by simply overriding parameter entity declarations). You can refer to SGML as a language in its entirety, (containing all possible bits of SGML as combined according to the spec) and you refer to a document type in SGML as a language, consisting of all possible documents fo a given type. You could define the set of all parameterisable document types as a language, or one parameterised type inwhich you exclude any further declarations or parameterization as a language. But if you want to keep the word "language" which has no formal definition at all, then I will have to find another. >I think the problem is the bad idea that content models *define* a >language rather >than simply *describe* or *declare* it. I can go along with that. A content model defines the set of names, and constrains the ways in which they can syntactically be combined. Other languages (such as rdf-schema and futher languages a la Semantic Web Toolbox http://www.w3.org/DesignIssues/Toolbox musings) could more be said to "define" the names in a namespace. [...] >>Further, I expect that one can argue that a namespace is an abstract >concept >>denoting a set of names, and this argument is true, so far as it goes, >but >>it does not go far enough: For specific processing, to make use of a >>namespace one needs to know what names are in it, which are not, and >what >>the meaning is for each name Absolutely. One needs to knwo the meaning of the each name in order to know the meaning of the document. >Here is the crux: Andrew is saying a namespace mechanism should provide >more >than just a space of names! He says it should also provide meanings. If >it does so, >it is not a namespace, but a schema. Hang on. The namespace is an asbtract thing, (like software module). A schema is a document which tells you some information about it the namespace. It may contain information in various langauges. In particular, the xml schema draft gives you a way of expressing an XML content model. Other languages will allow one (in the same document) to provide "meaning" by mapping onto some other vocabulary. >Andrew is saying that we should >not have namespaces but schemas. This is a legitimate view, but it utterly >flies in the face of the current spec and all previous pronouncements on >it. I didn't hear Andrew saying that. He seems to say "The specification does not require that a namespace correspond to anything like a schema; but neither does it forbid such correspondence, either generally or in specific contexts." >If W3C says a namespace is a schema, they should withdraw the XML >Namespaces Spec immediately. As I emailed a month ago, Namespaces is dead. Not by >neglect but by abuse. You seem agitated about this, but as I don't understand your complaint yet. I have noone associated with W3C say that a "a namespace is a schema" so I suppose I don't have to understand the rest of your paragraph, which ?s good because I don't. I hope thay I can see though your clear agitation about this to the misunderstand someone must have somewhere. >Rick Jelliffe> Tim BL in no offical capacity xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From timbl at w3.org Fri Sep 17 21:16:59 1999 From: timbl at w3.org (Tim Berners-Lee) Date: Mon Jun 7 17:15:10 2004 Subject: Another look at namespaces Message-ID: <028801bf0141$9f63c0c0$a60a1712@col.w3.org> Philip Nye wrote on Thursday, September 16, 1999 5:54 AM >Tim Berners-Lee wrote: [...] >> I feel that language subsets are completely well defined, by the change >> of namsespace preserving validity. >I get the strong sense that your view is that subsetting is "good" and >useful (my own feelings exactly). We agree. > What I don't understand is why this >obvious point is not reflected in the namespace spec. The namespace spec had its work cut out finding a syntax for declaring and use name prefixes. Lots of folks wanted namespaces ASAP and so making remarks that "subsets relationships are very helpful" or even better defining an RDF property so that processors everywhere can use it probably would have delayed the spec. I don't in fact think that the namsepaces spec would have been the best place for it. But it sounds as though the xml-schema group *would* do well to define this relationship. After all, it is just the sort of useful thing as you point out one would naturally expect to find in the schema, and the xml-schema langauge seems appropriate. >Namespaces have no structure whatever. Schemata have lots of structure >but no guaranteed recognition and access mechanism. An access mechnaism for a URI to a document is well defined for many URI schemes. If you need it, use one,like HTTP, which has an access mechanism. >Philip Nye >Engineering Arts UK Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Sep 17 21:20:40 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:10 2004 Subject: Another look at namespaces In-Reply-To: <01ff01bf013c$2923a290$a60a1712@col.w3.org> References: <01ff01bf013c$2923a290$a60a1712@col.w3.org> Message-ID: <14306.23748.964502.765514@localhost.localdomain> Tim Berners-Lee writes: > That is not useful. I realize that the word "Namespace" (as the > end result fo the discussions of modules or docuemnt types or > vocabularies or...) may be an english word which does not convey > this, but a a namespaces is a language: a set of names plus a set > of syntactic constraints plus - to be useful - a meaning shared by > writer and recipient. As (I think) Tim is arguing later in his message, a Namespace is a component of a vocabulary: specifically, it's the mechanism that XML documents use to represent (and disambiguate) the names that are part of a vocabulary, but, as Rick argues, it's not the vocabulary itself. Since Paul Prescod mentioned Chomsky, I'll mention Saussure: like written or spoken words, a namespace-qualified name is a pure signifiant without any signifi?e. For example, the signifier "{http://www.megginson.com/ns/}apt" can be represented by Namespaces. The signified (say, "a valid ICAO airport code") cannot be represented by Namespaces, but for now will probably be represented in human-readable documentation and hard-coded in applications. I guess that a machine-readable schema could constrain the element to contain up to four alphanumeric characters, but who cares, really? My application still has to know somehow that it's an airport code and it has to know what it wants to do with airport codes (sell you a ticket? give you driving directions? tell you that the document contains a match for the code you were looking for?). 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 bpaul at wbtsystems.com Fri Sep 17 21:41:12 1999 From: bpaul at wbtsystems.com (Barry Paul) Date: Mon Jun 7 17:15:10 2004 Subject: On a more pleasant note In-Reply-To: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca> Message-ID: <001b01bf0145$54f225f0$8e5ca3ce@mumble.wbtsystems.com> > PS: In the XML I'm sending out from the server, I am embedding some human > readable text encoded, obviously enough, in HTML. What would be > a good way > to distinguish it from my own XML tags so that I can extract it and feed > it to the HTML renderer? Any suggestions? Yep, three: 1. Use namespaces (seriously!) 2. Encode '<', '>', etc using entities 3. Enclose the HTML CDATA sections Problems with each solution: 1. This is OK if you are sure that the HTML is valid and well formed 2. What else would you have to encode? (HTML entities?) 3. Maybe some whitespace issues Seems like number 3 would be a good way to go. Cheers, ----- Barry xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 22:02:54 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:10 2004 Subject: On a more pleasant note In-Reply-To: <001b01bf0145$54f225f0$8e5ca3ce@mumble.wbtsystems.com> References: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca> <001b01bf0145$54f225f0$8e5ca3ce@mumble.wbtsystems.com> Message-ID: <14306.26269.359383.260896@localhost.localdomain> Barry Paul writes: > 1. Use namespaces (seriously!) > 2. Encode '<', '>', etc using entities > 3. Enclose the HTML CDATA sections [snip] > 1. This is OK if you are sure that the HTML is valid and well formed > 2. What else would you have to encode? (HTML entities?) > 3. Maybe some whitespace issues > > Seems like number 3 would be a good way to go. Actually, it's by far the worst of the three. When someone is actually generating the markup (as Tim is in this case), then there are immense advantages to being able to process the HTML with the same software as the rest of the document, so #1 is far and away the winner. After all, the human-readable documentation is meant to be part of the document. #2 is also pretty awful, but at least it won't blow up if the HTML happens to contain the "]]>" character sequence (say, as an emoticon?). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jesmith at kaon.com Fri Sep 17 22:04:41 1999 From: jesmith at kaon.com (Joshua E. Smith) Date: Mon Jun 7 17:15:10 2004 Subject: Nimble: An XML conformant programming language Message-ID: <3.0.1.32.19990917155708.008b9bb0@tiac.net> Gurus and others, You may recall that several months ago, I used this list as a resource in figuring out how to make a programming language which conforms to XML 1.0. Despite the fact that you all thought I was nuts, it's now done, and I think it's pretty cool. The language, called "Nimble" drives a Windows web browser plugin (now porting to other platforms). The language encapsulates an object model for 3D scene description, distributed simulation, user interface, behavior scripting, control flow, java/javascript interface, etc. The plugin for Netscape, and the ActiveX control for IE are called "HyperActive" and they let you deploy 3D audiovisual multiuser content in web pages. Basically, it's a general purpose multiplayer game engine wrapped in a little (<400K) plugin. Anyway, I thought that since many of you helped me puzzle out the design of this language, you might want to see the result. The plugin is free, as is the SDK (a manual which isn't really done yet, exporter, utilities & sample programs). You'll find it at: http://www.kaon.com/SDK Thanks again for all your help! -Joshua Smith xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tyler at infinet.com Fri Sep 17 22:11:28 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:15:10 2004 Subject: XML in the real world... Was "Re: Another look atnamespaces" References: <199909171111.MAA14708@nag.co.uk> <4.1.19990917094330.0251cd90@mail.webgeek.com> Message-ID: <37E29FF3.94799E49@infinet.com> Ann Navarro wrote: > It's assertions like this that honestly confuse me. WWW content,rendered on > today's HTML browsers, cares not a whit about namespaces, so how does > having 3 complicate your life more than 1? We effectively have "0" since > the browsers don't use, acknowledge, or appreciate the namespace. This is true now for HTML itself now, but aside from making browsers more bloated than they already are. What you end up having to do in practice anyways is map each P element from each namespace to some sort of element object in the document tree rather than just have one P element. How about 3 new versions of XHTML in say XHTML 2.0. Then you have 6 different namespaces to deal with, rather than just one. You will have code that says: if (namespace.equals("XHTML_1.0_STRICT")) { processXHTML10Element("elementName"); } else if (namespace.equals("XHTML_2.0_STRICT")) { processXHTML20Element("elementName"); } Every time you create a new version of XHTML, previous versions are in effect no longer backwards compatible unless you map the elements from the old namespace to the new namespace which really is bad practice and a hack. HTML 3.0 browsers could read HTML 2.0 content since HTML 3.0 inherited the properties of HTML 2.0. But by putting everything in its own namespace you are really saying that there will no longer be any sort of inheritance. If you can't see the potential for code bloat, let alone dangerous hacks that HTML engines will employ just to glue everything together, then I don't know what to say. On a related note, if anyone looks at the current draft of XSLT, it is a very nice piece of work, even though I wish that "Namespaces in XML" was removed from it and replaced with something different to handle the namespaces issue. One reason it is a nice piece of work is that through the hard work of James Clark, he has written a proof of concept implementation of each draft that he calls XT. Though I have never been present at any of the XSLT WG's, I am sure that Mr. Clark has raised many issues that would otherwise never have been raised if he had not actually implemented the most recent working drafts into XT. Perhaps, this should be done with XHTML even though a prototype implementation is actually a lot more work than writing an XSLT processor (may take at least three people). This may seem like a waste of resources, but I think it would really help out the HTML WG in separating theory from reality. > > Also, the fact that 99% of > >the posts on this > >list aside from Ann's are from men who need to get out more (including > >myself) makes it all > >the more encouraging to see someone like Ann challenge the incoming flood of > >testosterone that > >swamps this mailing list (-: > > Would it help to know that in my "previous life" (of most of my 20s), I > spent nearly 10 years in the radio control room at the police department, > effectively telling 30-50 men where to go all night? ;) Oh so I guess you are used to the overwhelming male atmosphere here. Well at least you had a large pool of men in uniform to date whenever you wanted to back then. Now you just have the option of having cyber-sessions with us XML-DEVers (-: 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 bpaul at wbtsystems.com Fri Sep 17 22:44:43 1999 From: bpaul at wbtsystems.com (Barry Paul) Date: Mon Jun 7 17:15:10 2004 Subject: On a more pleasant note In-Reply-To: <14306.26269.359383.260896@localhost.localdomain> Message-ID: <001e01bf014e$24509180$8e5ca3ce@mumble.wbtsystems.com> [using CDATA to hide HTML] > > Actually, it's by far the worst of the three. When someone is > actually generating the markup (as Tim is in this case), then there > are immense advantages to being able to process the HTML with the same Well, I was thinking of a situation where the HTML was not being generated by Tim. In this case there is more than a possibility that the HTML will not be well formed or valid. In this case #1 would not work. > #2 is also pretty awful, but at least it won't blow up if the HTML > happens to contain the "]]>" character sequence (say, as an > emoticon?). I agree, all the solutions are pretty horrible. Have you any other suggestions as to how "real-world" HTML could be encapsulated in XML? ----- Barry xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 17 22:48:55 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:10 2004 Subject: On a more pleasant note In-Reply-To: <001e01bf014e$24509180$8e5ca3ce@mumble.wbtsystems.com> References: <14306.26269.359383.260896@localhost.localdomain> <001e01bf014e$24509180$8e5ca3ce@mumble.wbtsystems.com> Message-ID: <14306.29024.414449.468797@localhost.localdomain> Barry Paul writes: > I agree, all the solutions are pretty horrible. Have you any other > suggestions as to how "real-world" HTML could be encapsulated in > XML? That's a separate question -- real-world (non-XML) HTML can be encapsulated reasonably in three ways: 1. Escape '<', '>', and '&' (assuming that there are no non-XML characters like form-feed). 2. Uuencode the whole mess. 3. Put it in a separate file and point to it. The second and third options work for anything -- you can use them for graphics, MP3s, or what-have-you. 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 tyler at infinet.com Fri Sep 17 22:55:44 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:15:10 2004 Subject: On a more pleasant note References: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca> Message-ID: <37E2AA89.A65664C9@infinet.com> Tim Bray wrote: > There's been a lot of angst around here recently. On a countervailing note: > I am building this big hairy complicated app in which a web server traverses > an extremely complex database, extracts some dense information structures, > sends them to a client, and the client does some nifty rendition tricks. > > Building the database is hard. Traversing the database is hard. Doing the > rendition on the client is hard. But generating the message on the server > takes one little C subroutine (printf calls, nothing fancy), and extracting > the information from it on the client (using an XML parser, it doesn't > matter which) is one little Java routine. The client-side worked first > time, the server-side on the second (I wasn't escaping some &'s properly, > which the XML parser on the client caught first time through). All the > rest is done by Apache and Linux and Windows and TCP/IP and HTTP and > java.net.URL and the XML parser. It took maybe an hour to build both sides. > > Seems to me that this is the right way to build distributed applications. For your problem domain of a traditional client/server app, yah this setup seems to work great for you. Since most people building web applications will likely have a setup that mirrors yours, your success story is reassuring. On the other hand, I am using XML for an entirely different distributed application some might consider groupware oriented that does not depend on some 24/7 server running all the time. Probably a lot more complicated than your 2 hour setup, but for this app XML I think has been a wonderful complement to object serialization as it is a much nicer data format for potential application interoperability later down the line. > -Tim > > PS: In the XML I'm sending out from the server, I am embedding some human > readable text encoded, obviously enough, in HTML. What would be a good way > to distinguish it from my own XML tags so that I can extract it and feed > it to the HTML renderer? Any suggestions? Well there is always the comment hack. If a comment starts with some magic string you define, then simply trim off the rest of the data in the comment as your HTML. You will of course need to make sure that you handle nested comments appropriately. Of course I am sure you have already thought of this as this I guess is pretty obvious and there are probably obvious pitfalls I can't think off the top of my head right now. But if I had 30 seconds to find a solution, that would be what I would try first (-: 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 john.tigue at tigue.com Fri Sep 17 23:02:31 1999 From: john.tigue at tigue.com (John Tigue) Date: Mon Jun 7 17:15:10 2004 Subject: SOAP non-opera (was CNET on XHTML) [re-send] Message-ID: <000601bf0158$e34f5440$788410d2@tigue.oz.net> I no longer invest any of my time in "RPC over HTTP via XML". So, this message is related to politics not technology. If, for some crazy reason, you're looking for a technical discussion (because this is xml-dev) then get out now. Don Park wrote: > The article was updated with Ann's comment added so it is > more balanced now although the result is the same: there is > trouble brewing for W3C. Since I am fairly certain that W3C > will ignore all the arguments and concerns raised against > three namespaces, I believe the divide between W3C and > XML-DEV will continue to widen. > > I wonder why the SOAP spec was submitted to IETF rather > than W3C? A new trend of sort? Over the last few years, Microsoft has repeatedly submitted DCOM specs to the IETF. SOAP is just DCOM over HTTP. So I do not feel that Microsoft's actions with regards to SOAP can be used as evidence to support "a new trend" in Microsoft's behavior as it relates to the W3C and the IETF. Here's an example of Microsoft submitting DCOM to the IETF, at http://www.ietf.org/mail-archive/ietf/msg00139.html Quoting modulo formatting: 6. There were 152 Internet-Draft Actions during the month of January, 1998: [...] Distributed Component Object Model Protocol -- DCOM/1.0 I do believe that SOAP will be discussed within the W3C. For example, the HTTP-NG Reading List at http://www.w3.mag.keio.ac.jp/Protocols/HTTP-NG/ReadingList.html contains a reference to a DCOM spec. Quoting: The DCOM protocol (DCOM ORPC - issued as an IETF Internet draft "draft-brown-dcom-v1-spec-01.txt". Expired, May 1996 Also, Microsoft has representation in the appropriate W3C WG, the HTTP-NG Protocol Design Group (PDG). So I suspect that SOAP will come up during the group's meetings. Although I was briefly a member of the HTTP-NG PDG WG, I have not been active in the W3C since I left DataChannel almost a year ago so this is all conjecture (hopefully without confidentiality concerns). That said, I hope to never write another word about XML-RPC, SOAP, WebBroker, or their ilk. /John -- John Tigue john.tigue@tigue.com http://www.tigue.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From timbl at w3.org Sat Sep 18 00:18:15 1999 From: timbl at w3.org (Tim Berners-Lee) Date: Mon Jun 7 17:15:11 2004 Subject: Another look at namespaces Message-ID: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org> -----Original Message----- From: David Megginson To: XML-DEV Cc: Tim Berners-Lee Date: Friday, September 17, 1999 3:23 PM Subject: Re: Another look at namespaces >Tim Berners-Lee writes: > > > That is not useful. I realize that the word "Namespace" (as the > > end result fo the discussions of modules or docuemnt types or > > vocabularies or...) may be an english word which does not convey > > this, but a a namespaces is a language: a set of names plus a set > > of syntactic constraints plus - to be useful - a meaning shared by > > writer and recipient. > >As (I think) Tim is arguing later in his message, a Namespace is a >component of a vocabulary: specifically, it's the mechanism that XML >documents use to represent (and disambiguate) the names that are part >of a vocabulary, but, as Rick argues, it's not the vocabulary itself. > >Since Paul Prescod mentioned Chomsky, I'll mention Saussure: like >written or spoken words, a namespace-qualified name is a pure lang="fr">signifiant without any lang="fr">signifi?e. There is a signifi?e, unless the namespace is useless. To design a namespace with no meaning is a possible excercise but as documents written in such a namespace would have no meaning. The namespaces spec doesn't tell you how to describe the meaning of a name. But that does *not* mean that it should have none. >For example, the signifier "{http://www.megginson.com/ns/}apt" can be >represented by Namespaces. The signified (say, "a valid ICAO airport >code") cannot be represented by Namespaces, but for now will probably >be represented in human-readable documentation and hard-coded in >applications. > >I guess that a machine-readable schema could constrain the element to >contain up to four alphanumeric characters, but who cares, really? > My >application still has to know somehow that it's an airport code and it >has to know what it wants to do with airport codes (sell you a ticket? >give you driving directions? tell you that the document contains a >match for the code you were looking for?). But once your application can do that with a http://www.megginson.com/ns#element-apt then an RDF assertion that http://www.blee.com/ns2 is-subset-of http://www.megginson.com/ns will allow your application to know automatically how to process airport codes in my vocabulary. I just declared mine to be a subset of yours. Or I might in a schema want to assert that http://www.blee.com/ns2#element-airportcode is-equivalent-to http://www.megginson.com/ns#element-apt >David 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 Marc.McDonald at Design-Intelligence.com Sat Sep 18 00:21:40 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:15:11 2004 Subject: Another look at namespaces Message-ID: <4454C011BDE5D211B6C800609776E5402682E3@master.design-intelligence.com> > >There is no W3C method to define a namespace as list of names. > > There is an xml-schema spec in the works destined to do that > and more. > > One can either take the existing specs at face value at any point in > history, and not complain about the lack of functionality. Or you can > work with > the model which you forsee you can > In the works does not equal recommendation. In particular, why should XHTML go off and decide a mechanism to solve a problem which is a general XML problem and is being worked on by the schema group? XHTML should define no namespace at all and await schemas. The existing namespace spec merely disambiguates. You can't declare the list of valid names. You can't declare the valid structure. You don't have to use a namespace unless an element is ambiguous. If schemas end up extending namespaces (to have a reference to a schema required for instance), then fine. But, XHTML should not be making that decision. Also, as noted in other messages, browsers don't use namespaces. So, there may need to be 2 versions of every XHTML document - one for browsers and one for XML parsers. I thought the point of XHTML was an XML compatible version of HTML. That would mean no implicit ending of elements, for instance. An XHTML document should be acceptable to an HTML browser and an XML 1.0 parser. It looks to me like the use of namespaces makes that impossible. Is a browser going to recognize strict:p? And if XHTML documents for browsers don't use namespaces why do we have to use them with XML? Marc B. McDonald Principal Software Scientist Design Intelligence, Inc. 1111 Third Avenue, Suite 1500 Seattle, WA 98101 marc.mcdonald@design-intelligence.com Ph: 206.343-7797 Fax: 206.343.7750 http://www.design-intelligence.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Sep 18 00:30:59 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:11 2004 Subject: Another look at namespaces In-Reply-To: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org> References: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org> Message-ID: <14306.49588.271748.587016@localhost.localdomain> Tim Berners-Lee writes: > The namespaces spec doesn't tell you how to describe the > meaning of a name. But that does *not* mean that it should have none. But I didn't suggest that at all (sorry for any confusion) -- I merely suggested that the Namespace-qualified name itself is just a signifier. The signified is something and somewhere else. I'm fairly certain that we agree on this point. 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 Marc.McDonald at Design-Intelligence.com Sat Sep 18 00:39:20 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:15:11 2004 Subject: A compromise? Message-ID: <4454C011BDE5D211B6C800609776E5402682E4@master.design-intelligence.com> David Brownell wrote: > Don Park wrote: > > > > What if we came up with a way to associate a schema with any element > without > > using namespace? Would it address the real concerns of the HTML WG? > > I'm also curious why the HTML WG should care, since (X)HTML has > only DTDs (currently three of them) for which there's already > a standard association technique: > > '-//W3C//DTD XHTML 1.0 Transitional//EN' > 'http://www.w3.org/TR/xhtml1/DTD/transitional.dtd'> > > Seems to me that the best compromise is to stick exclusively to what > is already accepted -- ruling out schemas. > EXACTLY. Leave the work to the schema group to solve the general problem for all XML, not a special solution for XHTML which may or may not end up being compatible. The only argument I've seen presented is if you want to use HTML in your XML document. It is suggested to declare the HTML namespace and prefix the elements you use. Since HTML elememts are mixed with other document elements, the DOCTYPE declaration wouldn' t work. Actually it would since the DTD referenced would have to contain the XHTML element declarations (or use ANY). If it included the declarations then there would be no ambiguity - validation does not recognize namespaces so H1 would be declared without a prefix. If it were declared with a prefix, then it would be establishing a standard prefix and any application could just as easily recognize 'strictH1' as 'strict:h1'. The reuse of DTD content is a general XML issue and should also be solved generally. I'm not sure which group has responsiblity for it (I'm guessing schemas). > Marc B. McDonald > Principal Software Scientist > > Design Intelligence, Inc. > 1111 Third Avenue, Suite 1500 > Seattle, WA 98101 > marc.mcdonald@design-intelligence.com > Ph: 206.343-7797 > Fax: 206.343.7750 > > http://www.design-intelligence.com > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sat Sep 18 01:00:51 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:15:11 2004 Subject: Another look at namespaces Message-ID: <3.0.32.19990917160313.00ca0b30@pop.intergate.bc.ca> At 09:18 AM 9/17/99 -0400, Tim Berners-Lee wrote: >From: Tim Bray >>Among other things, I don't believe that most >>interesting namespaces *have* definitive information, but have semantics >>that are communicated via some messy combination of schemas, stylesheets, >>prose documentation, and running code. > >We either have a different use of words or a very serious >problem. Whereas with natural langauge, meanings change and >grow and everyone has slightly different associations with a word, >in computer languages we need to build on top of XML we need >to have the ability to define meaning precicely in terms of >other existing languages. Actually, Tim B-L and I are both advocates of moving as much semantics as possible from idiosyncratic impenetrable procedural code and woolly forests of prose into declarative schemas so that you can start to use some knowledge rep tricks and do a bit of meaning-discovery, not just the resource-discovery enabled by the current Web. This is what Tim calls "the semantic web" in his platform speeches, and its foundation is RDF and RDF style schemas. I'm onside with this. Perhaps the disagreement (if any) is on the degree to which this is possible. There are going to be lots of languages invented, and while I believe that we will get increasingly better definitional machinery as time goes on, I see no reason to believe that any of the following are going away: - human-readable documentation - messy procedural code that actually does something useful with the data - stylesheets (plural) - related resources containing hyperlink networks - related resources containing RDF assertions in some vocabulary - transformation specs along the lines of XSLT and so on and so on. What bothers me is the notion that among all these things, the schema is somehow privileged and special. I think that which of the above laundry-list you care most about is very highly application-dependent, data-dependent, and rather wholly unpredictable in the general case. I suspect that the proportion of real-world applications that actually use the schema at run-time will be moderate at best - schemas come more usefully into play in application design, authoring support, and so on. Perhaps Tim B-L thinks that this proportion will in fact be quite high? This is a reasonable disagreement, and we've all been fooled by technology enough times to have learned humility. So.......... where do we still have disagreements with concrete short-term implications? 1. I'm convinced that the namespace mechanism, while it's useful for what it is, is hopelessly inadequate as a tool for direct mapping between instances and schemas. We need at least one level of indirection, i.e. the packaging work that's hanging fire in the W3C XML activity. 2. For this reason, I think that the correspondence between namespaces and DTDs in XHTML 1.0 PR doesn't do a good job of meeting the needs of either people who need schema discrimination or of people who think HTML-is-HTML. 3. I am astonished and disappointed that the W3C still can't bring itself to publish a 3-line note saying that for those who see HTML just as HTML, and who want to mix & match those tags with others, they should use the following URI as a namespace name for HTML: -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Sat Sep 18 01:28:45 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:11 2004 Subject: XML in the real world... Was "Re: Another look atnamespaces" In-Reply-To: <37E29FF3.94799E49@infinet.com> References: <199909171111.MAA14708@nag.co.uk> <4.1.19990917094330.0251cd90@mail.webgeek.com> Message-ID: <199909172330.XAA51828@out4.prserv.net> At 04:09 PM 9/17/99 -0400, Tyler Baker wrote: > How about 3 new versions of XHTML in say >XHTML 2.0. Then you have 6 different namespaces to deal with, rather than just >one. Except there aren't 3 new versions of XHTML in the next iteration. There's 1. XHTML 1.1 (see public working drafts) >Oh so I guess you are used to the overwhelming male atmosphere here. Well at least >you had a large pool of men in uniform to date whenever you wanted to back then. Hrm. Cops or crooks, what would you pick? ;) >Now you just have the option of having cyber-sessions with us XML-DEVers (-: Don't think my husband ( http://www.basicguru.com/navarro/ ) would approve much ;) Ann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Sat Sep 18 02:05:02 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:11 2004 Subject: Another look at namespaces In-Reply-To: <4454C011BDE5D211B6C800609776E5402682E3@master.design-intel ligence.com> Message-ID: <199909180007.AAA51248@out4.prserv.net> At 03:24 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: >. In particular, why should XHTML >go off and decide a mechanism to solve a problem which is a general XML >problem and is being worked on by the schema group? We didn't decide someone else's problem. We took a work in progress and used it as the basis of *one* aspect (out of several) for our decision on the namespace issue. Ann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 18 03:17:52 1999 From: b.laforge at jxml.com (Bill la Forge) Date: Mon Jun 7 17:15:11 2004 Subject: A working alternative to XML Data Binding (An Open Source Release Notice) Message-ID: <002401bf0174$327c3c20$c8a8a8c0@thing1.jxml.com> Having an easy way to convert XML documents to Java objects is (IMHO) a great idea. But I don't like code generators. And XML Data Binding looks like yet another reason to tie a project to a particular vendor's proprietary IDE. MDSAX could be an answer, but it has been difficult to understand and harder to use. But that is no longer true. MDSAX 2.0 has been reworked with the intent of making it easy to use. Like XML Data Binding, MDSAX uses a schema to drive the conversion of XML documents into application-specific Java objects. But MDSAX is designed to work with existing objects (like Swing components), rather than forcing a programmer to subclass generated code. You might like the new documentation, too: http://www.jxml.com/mdsax/index.html Bill la Forge, CTO JXML, Inc. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Sat Sep 18 03:09:23 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:11 2004 Subject: Another look at namespaces In-Reply-To: <4454C011BDE5D211B6C800609776E5402682ED@master.design-intel ligence.com> Message-ID: <199909180111.BAA85878@out4.prserv.net> At 05:58 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: > >> At 03:24 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: >> >> >. In particular, why should XHTML >> >go off and decide a mechanism to solve a problem which is a general XML >> >problem and is being worked on by the schema group? >> >> We didn't decide someone else's problem. We took a work in progress and >> used it as the basis of *one* aspect (out of several) for our decision on >> the namespace issue. >> >> Ann >> >> But that is jumping the gun - part of a work in progress is in a proposed >> recommendation. The key phrase in there is "one aspect" -- and we're still not *using* schemas, we're addressing the possibility that this may happen, as well as dealing with the other use cases described in Steven's message. Ann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Marc.McDonald at Design-Intelligence.com Sat Sep 18 02:57:08 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:15:11 2004 Subject: Another look at namespaces Message-ID: <4454C011BDE5D211B6C800609776E5402682ED@master.design-intelligence.com> > At 03:24 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: > > >. In particular, why should XHTML > >go off and decide a mechanism to solve a problem which is a general XML > >problem and is being worked on by the schema group? > > We didn't decide someone else's problem. We took a work in progress and > used it as the basis of *one* aspect (out of several) for our decision on > the namespace issue. > > Ann > > But that is jumping the gun - part of a work in progress is in a proposed > recommendation. > > Things can change before it is a recommendation, particularly when the > only published document on schemas is a requirements document, not even a > working draft or proposed recommendation status. > > I can show you a lot of XML files that used the wrong capitalization for > XML declarations because it was changed with the official 1.0 release. XSL > has changed between versions. The URI for RDF has changed with the final > release. > > I seem to remember some rather explicit language in the status of document > section of working drafts: > > "This is a draft document and may be updated, replaced or obsoleted by > other documents at any time. While we do not anticipate substantial > changes, we still caution that further changes are possible. It is > inappropriate to use this document as reference material or to cite it as > other than 'work in progress'". > I would think using something that hasn't even reached 'work in progress' status and putting it in a proposed recommendation is far more problematic than using a working draft as reference material. Again, from the rationales I've seen, you aren't really using namespaces as defined by the spec. You are trying to define XML modules which is not part of namespaces but I would think are part of the schema group's task. I don't mind the XHTML DTD broken into modular pieces, just don't talk about namespaces at all. The general XML solution will apply equally well to XHTML modules when it is developed. Marc B. McDonald Principal Software Scientist Design Intelligence, Inc. 1111 Third Avenue, Suite 1500 Seattle, WA 98101 marc.mcdonald@design-intelligence.com Ph: 206.343-7797 Fax: 206.343.7750 http://www.design-intelligence.com P. S. Cops or Crooks? Isn't it more important which you choose than us ;) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Marc.McDonald at Design-Intelligence.com Sat Sep 18 03:33:19 1999 From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com) Date: Mon Jun 7 17:15:11 2004 Subject: Another look at namespaces Message-ID: <4454C011BDE5D211B6C800609776E5402682EF@master.design-intelligence.com> > : RE: Another look at namespaces > > At 05:58 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: > > > >> At 03:24 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: > >> > >> >. In particular, why should XHTML > >> >go off and decide a mechanism to solve a problem which is a general > XML > >> >problem and is being worked on by the schema group? > >> > >> We didn't decide someone else's problem. We took a work in progress and > >> used it as the basis of *one* aspect (out of several) for our decision > on > >> the namespace issue. > >> > >> Ann > >> > >> But that is jumping the gun - part of a work in progress is in a > proposed > >> recommendation. > > > The key phrase in there is "one aspect" -- and we're still not *using* > schemas, we're addressing the possibility that this may happen, as well as > dealing with the other use cases described in Steven's message. > > Ann > "... we're addressing the possiblity that this may happen ..." I just don't see why a proposed recommendation should address a possibility in an area that hasn't even had a working draft released. Just don't address it until it is a recommendation and save us all this time. Which Steven and which message? There have been so many messages and I didn't see it in the Sept archive. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ann at webgeek.com Sat Sep 18 03:39:23 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:11 2004 Subject: Another look at namespaces In-Reply-To: <4454C011BDE5D211B6C800609776E5402682EF@master.design-intel ligence.com> Message-ID: <199909180141.BAA107642@out4.prserv.net> At 06:36 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote: > "... we're addressing the possiblity that this may happen ..." > I just don't see why a proposed recommendation should address a >possibility in an area that hasn't even had a working draft released. Just >don't address it until it is a recommendation and save us all this time. Perhaps I'm not being clear. That was only *one aspect* of the decision to use three namespaces. Not the only one. The others were also compelling enough to result in that decision. Even if we "don't address" schemas, the other use cases are still there, and the decision is the same. It is not a matter of only looking at schemas. > Which Steven and which message? There have been so many messages and >I didn't see it in the Sept archive. Steven Pemberton, HTML WG Chair, providing the official rationale statement. Ann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 18 04:49:37 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:11 2004 Subject: Signifiers/Namespaces (was Re: Another look at namespaces) In-Reply-To: <14306.49588.271748.587016@localhost.localdomain> References: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org> <03ed01bf015a$dc243cb0$a60a1712@col.w3.org> Message-ID: <199909180251.WAA22043@hesketh.net> Hmm... structuralism... seems appropriate here. Maybe we can say that: a local name is a partial signifier, like having part of a (person's) name a qualified name is a complete signifier a schema is a set of rules describing how signifiers can contain other signifiers, and defines a set of signifiers. This still leaves us needing something else to connect signifiers to _signifieds_ - which we don't have yet. A schema, except perhaps in the documentation end of it, still doesn't do that. RDF is one possibility that's been suggested for connecting signifiers to signified, and XML packaging has been suggested as another. Right now, it seems like we're spending a lot of time manipulating signifiers and hoping that the connection to the signified is obvious. Which it is - except that everyone's obvious is different. Have to stop home and pick up that battered copy of Saussure. Can't say I was ever fond of Chomsky. At 06:33 PM 9/17/99 -0400, David Megginson wrote: >Tim Berners-Lee writes: > > The namespaces spec doesn't tell you how to describe the > > meaning of a name. But that does *not* mean that it should have none. > >But I didn't suggest that at all (sorry for any confusion) -- I merely >suggested that the Namespace-qualified name itself is just a >signifier. The signified is something and somewhere else. I'm fairly >certain that we agree on this point. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 abrahams at valinet.com Sat Sep 18 04:10:55 1999 From: abrahams at valinet.com (Paul W. Abrahams) Date: Mon Jun 7 17:15:11 2004 Subject: Unicode surrogate block in XML? Message-ID: <37E2F5FC.7B90D7F8@valinet.com> Tony Graham (tgraham@mulberrytech.com) Fri, 17 Sep 1999 01:15:51 -0400 (EST) >> In any XML document, you can make numeric references to any Unicode character in the range #x10000 to #x10FFFF (as well as to any other legal character number). These references are independent of the encoding used in the XML document. << Is it really correct to refer to #x10FFFF, say, as a Unicode character, since Unicode characters are limited to 16 bits? I'd think it's necessary here to refer to that as a UCS-4 character. >> The sequence of #xD800 #xDC00 is the two Surrogate code values that address #x10000. That four-byte sequence may occur in a UTF-16 encoded file to represent #x10000. In contrast, "��" in an XML document is two illegal character references in a row. << I've been trying to fathom the distinction between Unicode and UTF-16, if there is one, and how these in turn relate to the UCS-2 encoding of ISO 10646. There's also the question of whether an XML document can be stored directly in Unicode, or whether instead it must be stored in either UTF-8 or UTF-16, as Section 2.2 seems to imply when it says ``all XML processors must accept the UTF-8 and UTF-16 encodings of 10646''. The latter appears to be the case; but if it isn't, then how would an XML document be stored directly in Unicode? I've pondered both Appendix C of the Unicode Standard and the relevant part of the FAQ on the Unicode website, and I'm still unclear about all of this. (By the way, the FAQ erroneously refers to UTF as the Unicode Transformation Format rather than the UCS transformation format.) In any event, thanks, Tony, for your very enlightening response to my original query. Paul Abrahams xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From fujisawa at the.canon.co.jp Sat Sep 18 05:41:49 1999 From: fujisawa at the.canon.co.jp (Jun Fujisawa) Date: Mon Jun 7 17:15:11 2004 Subject: C/C++ DOM implementation using expat In-Reply-To: <001801bf005a$0c4c3200$1ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: At 11:42 PM +0800 99.9.16, Rick Jelliffe wrote: > If anyone is working on a C DOM implementation using expat, > there is a C interface definition for DOM (.h) available at > http://www.ascc.net/~ricko/src/dom_interface.h > which they might find convenient to use (contributions and suggestions > welcome). I find the C interface definition for DOM very interesting. I don't have any idea on which level of conformance to CORBA mapping rules might be important, here is my questions and comments. - why DOM_Object is not defined as void*? - how about defining DOM_Environment as follows: typedef struct DOM_Environment { CORBA_exception_type _major; DOM_Exception; } DOM_Environment; - DOM_String could be simply defined as CORBA_wchar*. - two underscores are not needed for mapping operations. -- Jun Fujisawa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 18 06:07:11 1999 From: tyler at infinet.com (Tyler Baker) Date: Mon Jun 7 17:15:12 2004 Subject: XML in the real world... Was "Re: Another lookatnamespaces" References: <199909171111.MAA14708@nag.co.uk> <4.1.19990917094330.0251cd90@mail.webgeek.com> <199909172330.XAA51828@out4.prserv.net> Message-ID: <37E31044.156154BC@infinet.com> Ann Navarro wrote: > At 04:09 PM 9/17/99 -0400, Tyler Baker wrote: > > > How about 3 new versions of XHTML in say > >XHTML 2.0. Then you have 6 different namespaces to deal with, rather than > just > >one. > > Except there aren't 3 new versions of XHTML in the next iteration. > > There's 1. XHTML 1.1 (see public working drafts) OK, well I suppose I was confused. Nevertheless, every new version of XHTML will give programmers the choice of having the HTML processor map elements from different namespaces (each version of XHTML) to a single common element (a hack) or else have different HTML processors for each namespace (bloat). There is no concept of inheritance whatsoever, which although not absolutely necessary, I think would be good practice considering the history of the web community's adoption of new HTML specs as they come out the door. > >Oh so I guess you are used to the overwhelming male atmosphere here. Well > at least > >you had a large pool of men in uniform to date whenever you wanted to back > then. > > Hrm. Cops or crooks, what would you pick? ;) Depends on the cop or the crook. Even then crooks might be more attractive than some of the markup enthusiasts in this forum. > >Now you just have the option of having cyber-sessions with us XML-DEVers (-: > > Don't think my husband ( http://www.basicguru.com/navarro/ ) would approve > much ;) Hey what he does not know won't hurt him. Just don't let him read the blasphemous content that gets posted to this listserv or he might develop a fetish to posting arguments about specifications which at the end of our lives will probably be a meaningless set of events in history that are no more relevant than taking a drive on a Sunday afternoon with the wife in kids (or in your case your husband and any children you may have that are not already grown and out of the house). On a lighter note, who would of ever thought many years back that a simple network protocol for hypertext developed by Tim B-L would evolve into the greatest protocol ever for adults to waste their lives away in chat rooms talking dirty to each other while exchanging nude pictures of each other all on Yahoo and other portal sights with free chat, email, and web accounts. Just think that all of this debating about XHTML and namespaces is really just about the best data format to deliver porn to the masses. So why I and others waste my life in the dark art of internet programming so that marriages can be wrecked by internet addiction and kids can be desensitized by internet porn, I guess I will never know without some deep reflection. Nevertheless, I am pretty sure that 5-10 years down the line the W3C will be a dot in the annals of web history because it failed to listen to the devoted developers of the internet community about their concerns on W3C recommendations no matter how stupid or trivial they may seem at the time. Hopefully in the meantime another standards organization will arise that fills the void left by the W3C that many of us developers feel exists when we try and think of a relevant internet standards organization with financial backing. Well off to bigger and better things (-: Tyler Baker xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tgraham at mulberrytech.com Sat Sep 18 06:39:27 1999 From: tgraham at mulberrytech.com (Tony Graham) Date: Mon Jun 7 17:15:12 2004 Subject: Unicode surrogate block in XML? In-Reply-To: <37E2F5FC.7B90D7F8@valinet.com> References: <37E2F5FC.7B90D7F8@valinet.com> Message-ID: <14307.5845.120000.679232@menteith.com> At 17 Sep 1999 22:16 -0400, Paul W. Abrahams wrote: > Tony Graham (tgraham@mulberrytech.com) > Fri, 17 Sep 1999 01:15:51 -0400 (EST) > > >> In any XML document, you can make numeric references to any Unicode > > character in the range #x10000 to #x10FFFF (as well as to any other > legal character number). These references are independent of the > encoding used in the XML document. << > > Is it really correct to refer to #x10FFFF, say, as a Unicode > character, since Unicode characters are limited to 16 bits? I'd think > it's necessary here to refer to that as a UCS-4 character. The Unicode Standard started out with the design principle that all characters have a uniform width of 16 bits. The expectation was that the 65,000 or so characters that you can address with 16 bits would far exceed the requirements. However, reality intruded, and the practicalities (and possibly the political realities) of defining a universal character set has meant that there are more characters to be defined than can fit in a 16-bit address space. Unicode 2.0, published in 1996, defines the Surrogate block and a mechanism for using two code values from the surrogate block to address over one million extra characters. The Unicode Standard, Version 2.0, supports surrogates, but doesn't quite know what to do about them. Section 3.7 of the Unicode Standard, Version 2.0, defines surrogates, and they are mentioned again in section C.3, but you're left with the impression that they and UTF-16 are really an ISO/IEC 10646 thing. UTF-16 was initially defined in Amendment 1 of ISO/IEC 10646-1:1993, so it wasn't far off the mark. Planes 15 and 16 are reserved for private use, so there's been a legitimate use for surrogates, or, more broadly, for using characters outside Plane 0, since 1996. Since 1996, however, there have been numerous proposals for scripts to be included in the Unicode Standard and ISO/IEC 10646, and many of these are slated for definition in Plane 1, i.e. they'll need more than 16 bits to address the characters. As far as I know, none have been assigned code values yet, but it won't be too long after the release of the Unicode Standard, Version 3.0, and ISO/IEC 10646-1:2000. Furthermore, Plane 2 is reserved as the CJK Unified Ideographs Supplementary Plane, and it already has 41,000 characters lined up for inclusion. > >> The sequence of #xD800 #xDC00 is the two Surrogate code values that > > address #x10000. That four-byte sequence may occur in a UTF-16 > encoded file to represent #x10000. In contrast, "��" in > > an XML document is two illegal character references in a row. << > > I've been trying to fathom the distinction between Unicode and UTF-16, > if there is one, and how these in turn relate to the UCS-2 encoding of There isn't one anymore. The Unicode Standard used to say that it corresponded to UCS-2, but now it has embraced UTF-16 (and given us UTF-16BE and UTF-16LE for big-endian and little-endian representations without the BOM, respectively). The Unicode Consortium now also defines UTF-32, which is a 32-bit representation of the characters that you can address with UTF-16. There is no difference between the UTF-32 representation of a character and the UCS-4 representation of a character over the range of characters that you can address with UTF-32. The only difference is that when you say that your document is UTF-32, you're saying that it comes with the Unicode character semantics and conformance requirements rather than the different requirements of UCS-4. UTF-8 has also come into the fold since 1996. In the Unicode Standard, Version 2.0, UTF-8 was relegated to section A.2, but now it's an accepted alternative for UTF-16. > ISO 10646. There's also the question of whether an XML document can > be stored directly in Unicode, or whether instead it must be stored in > either UTF-8 or UTF-16, as Section 2.2 seems to imply when it says > ``all XML processors must accept the UTF-8 and UTF-16 encodings of > 10646''. The latter appears to be the case; but if it isn't, then > how would an XML document be stored directly in Unicode? I've UTF-8 and UTF-16 can encode the characters of the Unicode Standard. The Unicode Standard used to miss an aspect compared to how some people, e.g. some ISO standards, define a character set. Roughly speaking, the base aspect is the character repertoire, which is a collection of abstract characters. The next aspect is a mapping of the character repertoire onto a set of numbers. The third aspect is mapping the character numbers onto some representation as bits or bytes. The Unicode Standard used to conflate the second and third aspects since the character numbers are identical to the value of the 16-bit quantities that you can use to represent the characters. Hence it seems like a Unicode character is its 16-bit character number. This simplification falls down when you have character numbers that you can't express with 16-bits and you allow other bit representations for the characters. You'll find that the Unicode Consortium now speaks about UTF-8, UTF-16, UTF-32, and UTF-EBCDIC. The favourite is probably still UTF-16, but even UTF-16 isn't one 16-bit quantity to one character. Also, the Unicode character encoding model (http://www.unicode.org/unicode/reports/tr17/) now has five levels. > pondered both Appendix C of the Unicode Standard and the relevant part > of the FAQ on the Unicode website, and I'm still unclear about all of > this. (By the way, the FAQ erroneously refers to UTF as the Unicode > Transformation Format rather than the UCS transformation format.) There are two definitions for UTF. ISO/IEC 10646 always defines it as "UCS transformation format", and the Unicode Consortium mostly defines it as "Unicode transformation format" (see section C.3 of the Unicode Standard, Version 2.0, for an exception). They mean the same thing. > In any event, thanks, Tony, for your very enlightening response to my > original query. I hope this remains enlightening, and not overwhelming. Regards, Tony Graham ====================================================================== Tony Graham mailto:tgraham@mulberrytech.com Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9632 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ====================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at docuverse.com Sat Sep 18 06:42:34 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:12 2004 Subject: A compromise? In-Reply-To: <37E2682E.7CEAB54B@pacbell.net> Message-ID: <002301bf0190$d00a0820$dceefea9@w21tp> >I'm also curious why the HTML WG should care, since (X)HTML has >only DTDs (currently three of them) for which there's already >a standard association technique: But the current XML to DTD association mechanism has following problems: 1. Only one DTD per document 2. Can not specify at element granuarity 3. Can not replace DTD inline Above restrictions makes it difficult to create composite XML documents. Because XML namespace mechanism happens to lack above three problems, there is a desire to equate namespace to schemas. Why not use what is already there? By offering a namespace-like mechanism for schema association that solves above three problems, we can breakout of current impass. Here is a possible (and not necessarily the best) rendition of such a mechanism: Comments? Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 18 08:12:29 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:15:12 2004 Subject: Another look at namespaces References: <006101beffba$a2984280$a60a1712@col.w3.org> <14304.11288.712453.705292@localhost.localdomain> Message-ID: <37E257CB.75C05A3A@prescod.net> David Megginson wrote: > > I believe that > > a. the vast majority of applications will be most concerned with #1; > and > b. the applications concerned only with #1 will tend to be the > lightest-weight ones. This sounds similar to me to a goal we set in designing XML. It's become corrupted over time but as I recall the original goal was that XML should not only be implement but "hackable" in the sense that you could sit down with Perl and Awk regular expressions and do cool things with XML documents like rename element types and so forth. I thought that that was a bad criterion for several reasons but one of the major ones was that nobody *should* have to hack XML with regular expressions. They should be able to download a nice XML module and go to work on top of it instead of pretending that the XML was just text. So XML came around and not only did the nice modules come around for every language but they are actually built into the distributions of most languages now. Java is a little slow but nobody seems to have a big problem downloading and installing parsers. Even if XML was as hard to parse as SGML (which, thankfully, it is not) it would be possible to make "lightweight" applications if you can depend on using a library that someone else has written. Most "lightweight" applications today depend on megabytes of JDK, JVM, OS, GUI and device drivers. So "lightweight" typically means "written in a few lines of code but built on top of mountains of it." Part of your and my life's work has been to help develop the mountains. As part of that exercise I claim that it should be possible to write a single module that handles versioning for most XML applications and transparently allows older applications to do "the right thing" with newer documents. I claim this because I believe so strongly that XML applications should be both lightweight AND robust and I see no reason to require a trade-off. Build on a "version engine" and in a few lines of code you have an application that is future-proof and tiny. In order to invent this version engine we need a unified, implementable concept of language versions and/or dialects. We can't just say: "HTML is anything we say it is and an HTML dialect is anything similar." --- Obviously there is another definition of lightweight that implies tiny byte counts, minimal dependencies, and so forth. "Microwave oven XML" style lightweight. But the truth is that "standard XML" and HTML are not very good for those applications anyhow. You must design an variants that are not so expensive to implement. Therefore I am reluctant to start thinking about embedded processor at level 4 when levels 0 through 3 didn't really do so effectively. Microwave oven designers can develop an XML subset (perhaps just canon XML?) and their own namespace and versioning strategy. I'll bet the smallest, from-scratch (i.e. using no libraries) XML compliant parser takes up more ram than my first computer had! Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at prescod.net Sat Sep 18 08:12:25 1999 From: paul at prescod.net (Paul Prescod) Date: Mon Jun 7 17:15:12 2004 Subject: Another look at namespaces References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <37E25959.6BFCE9BA@prescod.net> Rick Jelliffe wrote: > > Again, Andrew is simply conflating schema and namespace. The idea that > he and Tim are putting forward is that a language is defined by a single > set of content models; this confuses "language" with "grammar" What definition of language are you using that does NOT state that every language has one and only one grammar. Is there a book I can read that defines it? The SGML Cookbook doesn't count. > and > is disproved by long-standing SGML practise, in which variants of > a language can be defined in the same DTD (selected by marked sections, > or by simply overriding parameter entity declarations). SGML does not (AFAIR) define the word "language." It defines the word "document type" and a document type has one and only one grammar. Even if we ignored this we could say that SGML use a very flexible grammar definition language that defines grammars that are not context-free or hedge-regular or whatever. Grammars can be paramaterizable, extensible and otherwise complex. But as Tim B-L and I both said, the important consideration is temporal. XHTML 1.0 could be defined with one of these "parameterizable grammars". We could have one dialect and neither of us would care much. But it would set a bad precedent because it would validate this fuzzy notion of "wink, wink, we know what a language is, nudge, nudge." This will cause problems over time when new versions come about. Assertion: Once there are deployed XHTML processors it should be absolutely illegal to silently pass off new, incompatible versions as if they were the same as old versions. New, compatible versions (e.g. subsets) are not a problem. A version attribute has a few problems * it is HTML *specific* -- every document type has versioning issues and every document type (now) has a different approach to it. There can be no general version-handling "engine" as long as this is the case. * the version attribute doesn't tell a new processor what it needs to know in order to know whether it can process the document safely. Once again, there is no standard for communicating *what has changed*. "Rip Van Winkle, the language has changed. Certain of your grammatical constructs have become offensive. You will be shot if you use them" "Can you tell me which ones?" "Sorry, you'll just have to learn by experimentation." > If the element is removed, it is the > declarations > for running text that should be changed, not the declarations for

        . > DTDs only provide parameter entities for this, which disguises this > basic > modeling truth. The modelling language isn't the issue. The resulting grammar is the issue. You could use prose to define XHTML -- if there are three grammars there are three languages. If you use a flexible grammar notation that allows the three grammars to be collapsed into one (such as prose) then you have one language. But if we define HTML's grammar *today* so that it automatically allows any extension we can think of in the future: Then we have issued an invitation for massive abuse by software vendors. > If W3C says a namespace is a schema, they should withdraw the XML > Namespaces > Spec immediately. There is a world of difference between saying that a namespace *is a schema* and saying that there are a set of W3C specifications (including XHTML) that have namespaces that have a one to one correspondance with schemas. It's like saying that "p" doesn't have to be defined in a DTD (because not every XML document has DTDs) but the *HTML* "p" *is* defined in a DTD (which has been the stance since HTML 2). Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at docuverse.com Sat Sep 18 08:22:36 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:12 2004 Subject: Another look at namespaces In-Reply-To: <199909180141.BAA107642@out4.prserv.net> Message-ID: <002b01bf019e$c40fe5e0$dceefea9@w21tp> >Steven Pemberton, HTML WG Chair, providing the official >rationale statement. I don't think the official rationale statement made its appearance on the XML-DEV yet. BTW, please look at my "A Compromise?" thread. It discusses a possible solution out of this mess. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Sat Sep 18 12:31:30 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:12 2004 Subject: Another look at namespaces In-Reply-To: <37E257CB.75C05A3A@prescod.net> References: <006101beffba$a2984280$a60a1712@col.w3.org> <14304.11288.712453.705292@localhost.localdomain> <37E257CB.75C05A3A@prescod.net> Message-ID: <14307.27304.102083.860559@localhost.localdomain> Paul Prescod writes: > This sounds similar to me to a goal we set in designing XML. It's > become corrupted over time but as I recall the original goal was > that XML should not only be implement but "hackable" in the sense > that you could sit down with Perl and Awk regular expressions and > do cool things with XML documents like rename element types and so > forth. Yes, the famous Desperate Perl Hacker. Granted, that was a slightly excessive goal, but in striving for it, the XML WG did create something that was implementable. I had the first AElfred prototype running in a couple of evenings, while I had spent over a year on and off trying to come up with a Java-based SGML parser. The goal of writing an XML parser in a week (i.e. 40-50 hours) is very attainable, even by non-specialists. I agree that there's little point in writing XML parsers any more, but the fact that they were trivially easy to write helped massively with their adoption -- the irony of the simplicity (or worse-is-better) principle is that, in the end, it conceals itself: now that there is lots of XML parsing software, it doesn't matter whether XML is simple or complex (because the complexity is hidden from the application); but that software wouldn't exist if XML hadn't been so simple in the first place. That's why, for example, we never ended up with a single Java-based SGML parser (even though it would be just as easy to process SGML if we did have the libraries). 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 Sat Sep 18 12:48:04 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:12 2004 Subject: Another look at namespaces In-Reply-To: <37E25959.6BFCE9BA@prescod.net> References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU> <37E25959.6BFCE9BA@prescod.net> Message-ID: <14307.28278.600041.530052@localhost.localdomain> Paul Prescod writes: > Rick Jelliffe wrote: > > > > Again, Andrew is simply conflating schema and namespace. The idea that > > he and Tim are putting forward is that a language is defined by a single > > set of content models; this confuses "language" with "grammar" > > What definition of language are you using that does NOT state that every > language has one and only one grammar. Is there a book I can read that > defines it? The SGML Cookbook doesn't count. Well, for natural languages, there is almost never a single grammar: it varies (sometimes dramatically) by time, place, gender, and social background. The different grammars share certain patterns, which you can collect into a meta-grammar if you wish, but that meta-grammar is necessarily descriptive, fuzzy, and incomplete (the next field researcher in New York City, Nairobi, or Kingston, Jamaica could find an example that forces us to change the meta-grammar). > > and > > is disproved by long-standing SGML practise, in which variants of > > a language can be defined in the same DTD (selected by marked sections, > > or by simply overriding parameter entity declarations). > > SGML does not (AFAIR) define the word "language." It defines the word > "document type" and a document type has one and only one grammar. That's the spec, not the usage. In SGML practice, a single document type (lower-case) is almost always defined by multiple DTDs: in other words, the spec got it wrong, so the implementors simply worked around it. > But as Tim B-L and I both said, the important consideration is temporal. > XHTML 1.0 could be defined with one of these "parameterizable grammars". > We could have one dialect and neither of us would care much. But it > would set a bad precedent because it would validate this fuzzy notion of > "wink, wink, we know what a language is, nudge, nudge." This will cause > problems over time when new versions come about. > > Assertion: Once there are deployed XHTML processors it should be > absolutely illegal to silently pass off new, incompatible versions as if > they were the same as old versions. New, compatible versions (e.g. > subsets) are not a problem. > > A version attribute has a few problems > > * it is HTML *specific* -- every document type has versioning issues > and every document type (now) has a different approach to it. There can > be no general version-handling "engine" as long as this is the case. It can become conventional for languages that need it, like the Perl $VERSION attribute. Standards writers hate conventions (because they didn't get to invent them), but those of us in the U.K, Canada, and the U.S., at least, are very used to the idea that The Law is a combination of statutes and common law. > * the version attribute doesn't tell a new processor what it needs to > know in order to know whether it can process the document safely. Once > again, there is no standard for communicating *what has changed*. Neither does the Namespace URI -- that information is available only through outside documents (schemas, or what have you), and there is no absolutely no difference in the mechanism for retrieving them using the Namespace URI or the value of the version attribute. [snip] > The modelling language isn't the issue. The resulting grammar is the > issue. You could use prose to define XHTML -- if there are three > grammars there are three languages. If you use a flexible grammar > notation that allows the three grammars to be collapsed into one (such > as prose) then you have one language. This is a puzzling statement -- in other words, if I use notation A to describe it, XHTML is three languages, but as soon as I switch to notation B, it magically becomes one? I suppose that Derrida would approve. 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 ann at webgeek.com Sat Sep 18 16:13:19 1999 From: ann at webgeek.com (Ann Navarro) Date: Mon Jun 7 17:15:12 2004 Subject: Another look at namespaces In-Reply-To: <002b01bf019e$c40fe5e0$dceefea9@w21tp> References: <199909180141.BAA107642@out4.prserv.net> Message-ID: <199909181415.OAA23740@out1.prserv.net> At 11:26 PM 9/17/99 -0700, Don Park wrote: >>Steven Pemberton, HTML WG Chair, providing the official >>rationale statement. > >I don't think the official rationale statement made its appearance on the >XML-DEV yet. Looks like it hasn't -- perhaps because he posted as a non-subscriber. Unfortunately, I'm on the road this weekend, and don't have my copy of it available to repost. One or two other people, I believe, were directly cc'd on it--perhaps they can repost it. Otherwise, I'll do so on Monday from the office. >BTW, please look at my "A Compromise?" thread. It discusses a possible >solution out of this mess. It only addresses a part of the problem, unfortunately. Ann xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 18 16:35:14 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:12 2004 Subject: Another look at namespaces In-Reply-To: <37E25959.6BFCE9BA@prescod.net> References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU> Message-ID: <199909181437.KAA05856@hesketh.net> We seem to have fallen into linguistics. At 05:08 PM 9/17/99 +0200, Paul Prescod wrote: >Rick Jelliffe wrote: >> >> Again, Andrew is simply conflating schema and namespace. The idea that >> he and Tim are putting forward is that a language is defined by a single >> set of content models; this confuses "language" with "grammar" > >What definition of language are you using that does NOT state that every >language has one and only one grammar. Is there a book I can read that >defines it? The SGML Cookbook doesn't count. I could start with H.L. Mencken's _The American Language_ (Fourth Edition with Supplements, 1948), in particular a citation of Noah Webster, in 1789: (second supplement, p. 333) >The most difficult task now to be be performed by the advocates >of pure English is to restrain the influence of men learned in >Greek and Latin, but ignorant of their own tongue, who have labored >to reject much good English because they have not understood the >original construction of the language.... They seem not to consider >that grammar is formed on language, and not language on grammar. That last sentence seems to summarize the problem we're having here. Whether or not _The SGML Cookbook_ makes this claim that a language is not constrained to a single grammar, I'll be making that claim in my next book, probably giving it an entire chapter for folks who find this issue intriguing. (Fortunately, the book isn't meant to be read straight through, so those who find this issue boring can skip around.) Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sat Sep 18 17:38:44 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:12 2004 Subject: Unicode surrogate block in XML? Message-ID: <006601bf01ec$c62b7670$37f96d8c@NT.JELLIFFE.COM.AU> From: Paul W. Abrahams >Is it really correct to refer to #x10FFFF, say, as a Unicode >character, since Unicode characters are limited to 16 bits If Tony wanted to be exact he would have said "Universal Character Set character" or something similar. But then no-one would understand what he meant! 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 cbullard at hiwaay.net Sat Sep 18 18:28:21 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:15:12 2004 Subject: Another look at namespaces References: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU> <37E2357C.FDAD0C55@prescod.net> <37E2593B.2C01A3C@pacbell.net> Message-ID: <37E3B94A.373@hiwaay.net> David Brownell wrote: > > Perhaps a lot of the current problems with XHTML map to such issues. > Rush one spec through with some open issues, and then watch the issues > multiply as time goes by. A by product of relying on a philosophy of attaining "minimum victories" is that it can engender longer conflicts. See the history of the wars of Rome with Carthage. On the other hand, trying for one definitive battle can also lead to the complete destruction of both sides, or the Pyrrhic victory. It is important at each phase of the development of the spec to know and resolve the most important issues. Getting it all done in one pass can also lead to a very long pass. See HyTime and DSSSL. Both standards are as complete as one could expect for a very complex set of requirements, some only discovered in process, and both were so far ahead of time that we are still mining them for building materials much as Egyptian palaces were made from blocks and the facing materials of the pyramids at Giza. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Sat Sep 18 18:28:21 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:15:13 2004 Subject: Binary-encoding of XML for communication References: <000201bf0119$c27dd5a0$74bbfea9@w21tp> Message-ID: <37E3B1D4.533F@hiwaay.net> Don Park wrote: > > I am with TimBL on the issue with binary XML. WAP is all right but not good > enough for general use. We need to put our heads together and squeeze one > out. I think it should support exactly one namespace (just kidding :). At the rate at which we are now deploying mobile communications within both CDPD and RF systems across the world for public safety, haing no standard on this will be mean we will go with the most useful implementation (probably whatever Microsoft agrees to) and that will become the de facto standard for one of the largest commercial applications of mobile binaries. Essentially, we are past the point of waiting. The RFPs are there and vendors such as Motorola, GTE, etc. are moving on. The problem is severe. We must be able to download and upload textual data, mugshot images, maps, etc. in a record of authority environment. At this time, we take a wait and see attitude toward XML because relational systems offer ubiquitous, safe alternatives and XML appears to be mired in its philosophical constraints. 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 cbullard at hiwaay.net Sat Sep 18 18:28:21 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:15:13 2004 Subject: Another look at namespaces References: <006101beffba$a2984280$a60a1712@col.w3.org> <4.1.19990916092628.02454100@mail.webgeek.com> <37E2529D.B4A6AE83@pacbell.net> Message-ID: <37E3B7D1.543F@hiwaay.net> David Brownell wrote: > > That was the gist of Tim's point that the "definitive" > schema would be found at the end of the namespace URI. > > Something can't be both optional and definitive in that > way ... if it's optional, some other way could be be > at least as correct/definitive. Try a change in terminology here: record of authority. It has a precise meaning in a contracting environment and a contracting environment is what is required for namespaces to be applied beyond its specification. Note that a record of authority is that artifact by which parties are contractually obligated, testable, and litigable. In the process of creating documentation, only in very restricted cases is the philosophy of "conversation from author to reader" useful. When this philosophy was advanced in the IETM community in the early 90s (See Eric Jorgensen), it was in the context of a type of document used in diagnostic systems where directive statements encoded as dynamic node navigation was used: technical manuals and wizards. However, there is an entirely different system of document production and use in place to create these "conversations". When creating documents as the record of authority for say, a system, there will be multiple instances as the document is changed version by version to correspond with the emerging design, the testable product, then the product post Product Acceptance Test. At each juncture, a unique record of authority will exist whose namespace is or can be different. These differences may be seen as the different names/element types that are applied within the scope of a nested or linear set of processes. The scheduling of processes, the binding of namespaces within these processes, an the publication of a final record of authority for acceptance are essential to contract based commerce. I note that commerce is not the only application but that it is a complex case which obviates simpler notions. 1. The Namespaces specification only assert the role of the namespace as a means to make a string unique within a scope. It goes no further. This does not make the spec wrong or inadequate but it limits its role as a record of authority in contracts to which it is applied. It also means the silence referred to in this thread is appropriate with regards to the spec if not to the principal authors (separate politics and law for the sake of progress). 2. A namespace is a URI/URN. The role of the URI/URN as a record of authority is defined by a separate specification by the IETF (Correct?). The role is as a means to locate a resource. The specification does not define the resource. Correct? 3. By a third agreement, it is possible to define the nature or use of the record of authority of a resource. Tim Bray and others are correct in stating that this cannot in all roles be a schema given that there are better alternatives in given processes (eg, use of applet, schema, other programs, natural language text, or even a registry or record that specifies any and all of these). In effect, this is negotiable or assertable in a record of authority. If the namespace is to assume a role (by dint of formal specification or local contract) as the identifier and means of locating a record of authority, it must be useful in a dynamic process and must be flexible with regards to the implementation of the tools used in that process. I suggest that the concept of negotiation (eg. MIME) is still the most effective means we have at this time for dealing with this. Definitiionally, HTML is the weakest case. It is a user interface/presentation language and its element types are only weakly associated with the semantics of the information if tightly associated with the semantics of presentation and navigation. Multiple namespaces in XHTML are not efficient but they are not unexpected. Any review of preexisting markup schemas such as MIL-M-28001 reveal that any schema applied to a very large domain over time by multiple contracting parties becomes very large, very cumbersome, and very difficult to apply. Because of this, it is more likely that the multiple namespaces as separate languages are more tractable if for no other reason to encourage the older and less useful languages to die off. This is a fundamental of information ecologies. 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 digitome at iol.ie Sat Sep 18 20:37:23 1999 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:15:13 2004 Subject: Another try on groves In-Reply-To: <37E1532B.82F3BB03@prescod.net> Message-ID: <3.0.6.32.19990918192423.00ab2850@gpo.iol.ie> [Paul Prescod] [...] > A frame is not an "element", it has no >"attributes". Now I claim that a frame is an object and that it has >properties. And any idiot knows that objects can be represented in XML >using a variety of techniques but think about the logic of doing it this >way: you are taking a thing that is "logically" an object, expressing it >in terms of a text file format so that another module in the same >process can re-interpret it as logical objects. > >The *only good reason* to dumb something down into XML elements and >attributes is to move the information between processes separated by >space, time or incompatibility. I believe it makes perfect sense to *think* of MPEGS, PDFs, whatever, in XML terms. I't does not of course, make sense to *store* them as XML owing to the enormous size bloat. But who said the XML needs to physically exist in disk? Case in point, I have written a SAX driver for the MySQL relational database. I have SAX software that can happily trundling through 1GB of records treating them as XML. The XML never physically exists but the entire API used to process the MySQL is SAX. I can get programmers who have never seen MySQL, or its API, to write MySQL processing apps using a purely XML API. I do not see why the same cannot apply to other formats such as graphics, sound etc. In fact, I am working on a BMP driver right now. > Using XML as the "universal API" is >madness because there *is no universal API*. I have shown above how a non-XML source (MySQL) can be programmed with an XML API using SAX. I see no reason why a virtual DOM could not be implemented as well. I do not see what XML cannot be a universal API. Reasoning that it cannot because of size restrictions does not hold water because there is nothing stopping an XML document being as virtual as you want it to be. The virtual-ness of an XML document does not stop you programming it with an XML API. > The idea is patently >ridiculous. (some Unix evangelists have claimed that open/read/write is >hte universal interface but actual Unix usage demonstrates that this is >not even close to true...look at the heavy usage of CORBA and IDL in >Unix GUIs) The Unix evangelists played with the idea that the concept of *lines* of data, flowing through pipes, was the universal API. I believe they were on the right track, but placed too much emphasis on the concept of a "line". Joining line-aware utilities into pipes worked brilliantly well -- for data that fits simply into a line-oriented structure. Things start to get bent out of shape when the data that needs to flow between apps is hierarchical... I believe it was the need to shunt hierarchical data around that caused the shift to data-specific APIs. I remember writing a C program on a Sun workstation many years ago to dump out information about the last time a particular user had logged on. I cannot remember what the file was called or what the record structure was, but I do remember being suprised that it was a lump of binary data and required its own API. This seems very un-Unix like to me. I do not think it is necessary to bend things out of shape now that XML is reaching meme status. A whole new vista of possibilities open up if you change the concept of a Unix "pipe" from a line-oriented data flow, to an XML-oriented data flow. Hierarchical data could then flow through pipes just as easily as flat data. Flat data would simply be the degenerate case of a hierarchy of depth 1. All the advantages of pipes in terms of blocking buffers, virtual data streams and so on remain! I see no reason why GUI data, user logging info, whatever, cannot be programmed with an XML API. Going the other way towards data-specific APIs is, for me, the bad old days of proprietary data formats, steep learning curves and low programmer productivity. I would love to see a Unix that could flow XML node, by node through a pipe. Just thinking about what you could do with it turns me into a giggling wreck:=) regards, Developers Day co-Chair WWW9, April 2000, Amsterdam http://www.www9.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 qub.com Sun Sep 19 02:27:20 1999 From: paul at qub.com (Paul Tchistopolskii) Date: Mon Jun 7 17:15:13 2004 Subject: W3C and 'small vendors'. Message-ID: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii> To whom it may concern. I hope that this letter wuld not be considered abstract, because it is actualy an explanation of one particular problem and suggestion for working that problem around. I'm not blaming the W3C, I just want to make things better for all of us with pointing to some particular problem. The problem could be solved with publishing just one paper on W3C site. My letter is a request for paper : "If you have no $15K and/or you have no ability and/or need to travel across the world, but you want to provide a feedback to W3C you have the following ways to participate in the activity of W3C: ... " I would never write this letter months before, because at that point I was thinking that W3C is doing realy great and the process is reasonable and efficient ( of course, nothing is ideal, but I saw no critical problems). Our ( www.renderx.com) particular experience with W3C shows that there *is* one ( realy, I think there is just one) problem with W3C. The problem is: "W3C does not care about small vendors / independend developers, and ignoring those groups of people usualy causes significant problems on a long run". Those of you who are reading XSL mailing list may know that for last months our group ( www.renderx.com) handled a big work in the area of XSL FO WD. We are one of top experts in that particular area, because we simply wrote ( at the moment ) the strongest implementation of that standard. More. We have published the "Validating DTD" with many comments ( because such a DTD was a show-stopper for many people, including ourselvs and the only feedback from WG was "we'l include it into the next WD") ( when???). As a result some developers wrote us that "shame on W3C - you are doing their work". Unfortunately, so far we got no feedback from W3C at all. I can not count a private email : "keep posting to the XSL-list" as a reasonable feedback on our materials, because we have spend days and weeks preparing our materials. I'm not concerned too much about this particular problem ( our DTD ). Probably, with some hidden/political steps we may establish some kind of relations with XSL WG. Maybe not. Does not matter. Also, I'm *not* saying that we have something very special with XSL FO working group. I have some e-mails that show that the same situation happens with almost every group in W3C. It's easy to understand - people are bisy with their work, there are some ( unknown ) procedures for making the descisions, there is a (maybe reasonable - I don't know) 'conspiracy' angainst the outher space e t.c. Once again - I greatly respect W3C efforts and the efforts of XSL WG in particular. The April draft of XSL FOs was a *great* step. However, it is the end of September now. The problem is that if W3C will threat us the way it is now - it could be easier for us to decide at some point : "OK, we don't care about your standard stuff. We are the only one who have the working implementation and we'l add our own proprietary workarounds to the problems you are ignoring for months. Well - maybe you are not ignoring - but with zero feedback from you and our real clients who want our engine right now - it would be OK for us to start with Netscape-alike 'spacer' tags e t.c. " Again - it is not the worstest thing. The worstest thing is that it appears that *many* small vendors / intependend developers are having the same problem with W3C. I got emails from different persons and it appears that most of people who are 'outside the W3C' are having the similiar problems. For years I was thinking that damn vendors who are introducing some proprietary extensions to some standards are doing it because of some political / marketing reasons. After vain attempts to get any feedback from W3C for months, following the procedures suggested by W3C ( posting to the XSL-list is the suggested procedure, right? ) now I think that I was just naive and perhaps some marginal whoes in comp.text.xml are not actualy stupid. I think that if it will go as it is going now with W3C and 'ordinary people' outside, it would cause some vendors to start with their own 'Linux' for XML and I don't think that it will be good. If asking me personaly: "whould you like to start with "Linux for XML"?" 3 months ago: My answer would be "Of course, no. It's stupid." If asking me about the same thing today my answer would be: "Can I get your e-mail / url? Just in case." It is a sad story. If after 3 months my answer would be: "OK, let's start a mailing list on it, we have our part ready, you have your part ready, we need to hack this and that place to make it work together - let's do it right now, it'l take us forever to understand when they will come with the next version of WD, because they are silent for 2 months again". It would be the worstest possible scenario for me and W3C, because I'l start working *aganst* W3C, but not *for* W3C. Of course just one small case is nothing. What I'm saying is that the *probability* of this scenario increases every day. More and more 'ordinary people' are gaining more expertize in XML, more and more small companies are coming with 'some' implementations and the last but not the least, it appears that most of W3C memebers realy think that keeping silence makes things better, blaming the 'rest of the world' with : "hey, we are doing important things - don't bother us". After constantly receiving such answers people like Linus usualy say: "OK. If you don't care about me, I'l kill you with my implementation. It's *not* a big deal to put together a bunch of code to get my own version of UNIX - I don't have to be a *very*big*structure* to make some temporary descisions, because the task itself is *not* that complex to spend years with designing it". The biggest problem and maybe the the only reason of Lunix was that a *lot* of FreeBSD developers decided that it's not worth their time to spend their *free* efforts to support the group of persons who are simply ignoring them. I don't think that at the beginning of Linux, advicing Linus with "Just spend $15K and join our FreeBSD team" could work. We should learn from Linux. We are geting closer to the same situation. There was one letter where the man told: "Hey! Give me one million and I'l invent the better XML". I don' think it'l work. The more probable scenario is: "Hey! Just give me 5-10 teams, like renderx.com who are frustrated with W3C - constantly rejecting them - and we'l invent the lXML ( for free, like Linux was created). lXML will *not* conform to W3C specs but will *work*right*now*". It may become possible. It's not a good thing to ignore 'ordinary people'. Just imagine what may happen if the army of people who were supporting Linux would join FreeBSD community. We could definately have the best possible Free OS. Unfortunately we have what we have. The reason was: rejecting ordinary people ( like Linus ;-) who are outside the 'elite' I predict that if W3C would not care about 'ordinary people' like it *is* doing now it may result in 'Linux of XML' initiative. The descision is up to W3C. The approach: "become an expert and everything will be fine with you" does not work with our group. We *are* experts in XSL FO, but we have no time for face-to-face meetings ( however, we spend a *lot* of time writing down our suggestions) and it appears that we don't want to spend $15.000. If W3C cares about 'ordinary people' it looks reasonable to publish some FAQ for those people. If W3C does not care - it may be better to be prepared for "Linux for XML" initiative. Maybe "Linux fo XML" would not be a bad thing. I don't know. For me it could be better ( and it was possible ) to have a perfect Free UNIX, if not splitting efforts and rescources between Free BSD and Linux. BTW - many ( if not the majority ) Linux participators came from 'non-English' world. English spelling is not the most important thing when it comes to applications. It *is* when it comes to writing papers. I respect both activities greatly. Your mileage may vary. Rgds.Paul. PS. My idea was not to start a discussion, because actualy there is nothing to discuss in my letter. I just told about my experience with W3C. I am an example of 'ordinary person' who has not enough time for politics, travel e t.c. because I need to write code. Actualy, this posting appears to be my last posting to this list, because I need to write a *lot* of code next 2 weeks. I came to the XML world in a hope to make things better. I tried hardly to prepare reasonable materials ( if you'l look at the comments to our DTD, you may understand what do I mean), instead of spending too much time on writing abstract things in mailing lists ( even I did posted some abstract things, but most of materials were not abstract ). Most of things have been ignored by W3C. However, the same things were greatly appreciated by 'ordinary people'. Also I had a chance to compare the efficiency of my working group with the efficiency of W3C working group, but it is another story. I consider our story to be the prefect experiment with W3C and 'ordinary person' . The experiment took more than 4 months. I already got some understanding and it would help me with planning my future steps. Now I'm providing W3C with the results of my experiment it hope that it would be useful for W3C. It is the only purpose of my letter. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= paul@pault.com www.renderx.com www.pault.com XMLTube * Perl/JavaConnector * PerlApplicationServer =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 19 02:31:17 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:15:13 2004 Subject: Signifiers/Namespaces (was Re: Another look at namespaces) References: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org><03ed01bf015a$dc243cb0$a60a1712@col.w3.org> <199909180251.WAA22043@hesketh.net> Message-ID: <005b01bf0236$96b99ee0$0300000a@cygnus.uwa.edu.au> > >But I didn't suggest that at all (sorry for any confusion) -- I merely > >suggested that the Namespace-qualified name itself is just a > >signifier. The signified is something and somewhere else. I'm fairly > >certain that we agree on this point. see .sig :-) James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net Ceci n'est pas une pipe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 19 03:22:49 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:15:13 2004 Subject: should FOP require JDK1.2.x? Message-ID: <011c01bf023d$c9c11c80$0300000a@cygnus.uwa.edu.au> I'd be interested in hearing people's views on the simple question: should FOP (my XSL formatter/renderer) require JDK1.2.x? At present it works with 1.1.x. What are other XML developers doing? Should I stick to 1.1.x compatibility? Or can I require 1.2.x without offending too many people? James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net Ceci n'est pas une pipe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From timbl at w3.org Sun Sep 19 04:21:07 1999 From: timbl at w3.org (Tim Berners-Lee) Date: Mon Jun 7 17:15:13 2004 Subject: W3C's 'Moral Majesty' Message-ID: <049001bf0246$036d3c40$a60a1712@col.w3.org> Don Park (donpark@docuverse.com) on 11 Sep 1999 19:06:05 -0700 In http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0635.html said: >1. F2F and weekly telephone conferences >Without a doubt, both forms of meetings are valuable. Faces and voices >encourage people to work closer and reduces extremism through bonding and >group behaviors. However, these meetings are not efficient enough to >justify the cost of participation to individual members. If the WG member >is an employee of a large company, then the cost is less and even enjoyable >to certain extent. If the WG member is an independent developer/consultant, >the cost is high enough to prevent participation unless the member also >happens to be the Chair. This a crucial point: whether the cost (and the unfairness that introduces) is worth the greater understanding and trust which builds in a face to face. It is not a question of membership in W3C - as there is a way (as you found) for non-members to come to meetings as invited experts - the criterion is commitment of effort and acceptance of the charter. This thread has had both points of the argument made closely and I am not going to resolve it here. I understand it very well: I used myself personally to go to IETF meetings, but I found the three week-long international trips per year was too much, and as a result I have not found it easy to keep track of what started life proud to be an electronic forum for just the reasons you mention. I even notice that IESG membership is chosen selected from physical meeting attendees, so one cannot be part of the steering of the IETF unless one travels. (You can be on the W3C advisory committee AC or AB without travelling. But I have to say, the twice yearly face-face AC participation is very valuable). When we realized a forum for all chairs would be really interesting, we started with a face-to-face. The problems of how to run groups well were so desperately important and fascinating and frustratingly deep that it was a really great meeting and everyone resolved to do it again. But when it came to find a time to do it, no one wanted to travel and we went to phone conference from then on. There is no easy answer. >I have been to only one WG F2F meeting and I found it painfully boring, >tiring, and also disgusting to certain extent. Creativity is discouraged, >progress is measured in number of easy decisions and issues raised, >difficult decisions are deferred without exception, myriad issues are chewed >enthusiastically only to be spitted out and left on the floor like cheap >gum, political complications are raised and usually dealt with sarcastic >jokes which leaves the conflict hidden and dangerous, dinner conversations >are laced with petty thoughts, bureaucratic whining, and blatant discussion >of personal gains. Discussion of F2F meeting location is not based on >reason but pleasure without regard to cost. A meeting at South of France is >great if your company is paying for it but not if it is coming out of your >pocket. (Or if you happen to be someone who does not live in the USA. That is another form of exclusion we have to battle with.) Yuck - that sound horrible. I hope that you didn't come to any general conclusions about all meetings of all working groups. I also hope that you brought this up first with the chair, in an effort to understand and together improve the situation. If that didn't work, I hope that you knew that the staff contact which every working group has is there as an alternative channel. The chairs meet regularly by teleconference and have an email list chairs@w3.org which the general problem of "the art of consensus" (as the member guidebook is called) are discussed. Other WG members concerned about how the groups work are welcome. Everyone is of course trying to make the process at once open, efficient, fair and of a high technical quality. There is no short answer, but there is a steady flow of suggestions though from the chairs forum (and others) via advisory board approval to the process document and the guide. There is also a trade-off between hoping that people will use their common sense of social sense to be fair and work together, or whether bureaucracy should be introduced to force them to and drive them crazy. I have seen on this list general outcries against W3C bureaucracy, along with requests for more administrative systems to be put in place to monitor working group accountability. >Telephone meetings are more efficient than F2F except there is no room for >in-depth discussions. It is a breeding ground for hasty decisions without >proper representation of the issues. Well, so telephone meetings are rejected, I suppose? By the way, some people can't afford those either unless they are called back. Working groups are largely free to chose the form in which they will meet simply because each working group contains a different mixture of people, financial resources, technical complexity, social pressures, time pressure and so on. This is not something which W3C process puts a lot of constraints on - apart from for example forbidding going for more than 3 months at a time without publishing their results. >2. Mailing lists >Both WG and IG mailing lists are great but unsearchable and private. That depends on the mailing list. The XML Signature list, for example, is open. >Confidentially is too broad and laced with political issues which ends up >reducing representation of the outsiders. Issues are raised, dropped by >inattention, and killed by time. Field of vision in mailing list >discussions is one dimensional (even with hyperlinks) which restricts >awareness and thus limits the level of complexity the WG can deal with. A call for open working group lists. Maybe we should move in that direction with new charters. If you open a group to the public, then you cut the set of things anyone will be prepared to say. For example, an employee of a large company will be concerned lest his personal engineering opinions be taken by the press and used out of context to stir up scandal. As you point out, making the group visible isn't much use unless it also responds to input - and opening up input with no filter can drive a group into the ground. What happens in the W3C - and needs to happen in the community - is that a common problem is identified, that the solution fits >All this is encouraged indirectly by W3C and its policies. W3C is a lot of people trying to get things right. It started with very few policies and was after a while slammed for not having any. Those people who were concerned spent a lot of time trying to improve it. >If W3C can change itself, it should first relax its policy to reflect public >opinions more formally rather than at mercy of WG members' kindness. Good point. Though to do something formally isn't to "relax" anything: it means a lot of hard work. More meetings. More rules - i.e. more bureaucracy. > It should also install policy of independence from W3C bureaucracy. What on earth do you mean by this? Install a policy of W3C (the good side of people working together) being independent of W3C (the bad side of people working together). You are asking for more bureaucracy: rules about WG accountability to public mailing lists. Who is going to be independent from this? >The >director should be stripped of his unspoken right to interfere with his >unfairly heavy hand. You have the shoe on the other foot, I think. It is a spoken right - nay, written. According to the way the original membership contracts were drawn up, formally the Director decides what becomes a Recommendation and what does not. In fact there is a process http://www.w3.org/Consortium/Process by which reviews are done, and the director as a person has very little part. There is also an ethos - discussed largely by chairs and at the AC meeting - that we do not count votes, but ideas: we do not simply override a minority opinion, but if it has not been addressed, it is recorded and passed up a level. At the final AC review, a comment in just one review can stop the whole process until it has been resolved. Only occasionally have the staff had to point out that a negative review comment was not technically sound - normally an analysis leads to either a change in the document or a withdrawal of the comment. Complaints about the heavy hand of the director (HHD) or for that matter the staff (who, no matter that they are giving up perfectly good and much more lucrative jobs in industry to be there and have very little reason to be arbitrary or capricious) being unreasonable have historically occurred when the staff have had the indeed heavy burden of ensuring that all the bits fit together in the long run. It is all to easy to design a wonderful and beautiful part of the machine in a working group, and there are documents to read and write, and meetings to go to, a-plenty without having to constantly review everyone else's work. Here we are for example with differences about how namespaces are going to be used. It's not just a question of designing a namespace spec, but it being one which the other XML groups and SMIL and RDF and P3P will find meets their expectations. This is hard work. It involves crossing boundaries of the use of vocabulary. It involves the same person being aware of a lot of projects at the same time. It tends as a result to be a full time job. When the full time person (a staff contact in a WG) has to try to bring two WGs together, it may look to the WG as though that person -- a minority in the WG -- is claiming some sort of divine priority. In fact the poor soul is bearing all the stress between two lively groups of independent creative thinkers. We really need common underlying philosophy about how the future web will work. I have joined in on this list from the technical point of view because I was staggered to find there seemed to be big holes in that common understanding. On my postings I have maintained the right to state my own personal opinion. > Second, W3C should start using and investing in >groupware tools that allows efficient and focused online meetings, >bookkeeping of issues and decisions so that status, factors, and >justifications can be seen at a glance. Oh boy, are you preaching to the choir! There is not a staff meeting which can't be derailed into a three hour rathole by talking about tools we need and how they should work. A breakout group in the face-face chairs meeting worked on "Tools" and filled a flipchart with a small print list of tools which we clearly essential. A tools group was formed but everyone is so busy. Volunteers didn't seem to do it. Actually, paid staff have gotten quite a way. We do have tools to - allow HTTP 1.1 write back so minutes and issues list can be edited directly during meeting; (Amaya/Jigsaw) - track changes so we can take chances, get messy make mistakes - and recover. (Jigsaw/CVS) - diff changes, validate, check links, etc - control access flexibly - so we can be flexible about group membership - create new documents from templates - to save time - bookkeeping issues: event tracking agent (ETA) This is a PHP3/mysql tool which allows issues to be created, edited, tracked. In its early days. - meeting registration; - phone bridge monitoring, caller identification for faster roll call - mailing list creation, management, audit, - mailing list archives we are adding functionality to the open source hypermail right now; - the mIRC author kindly added URI tracking for us; - and so on Of course we have limited staff effort - meeting organization and group coordination and running the website and stuff takes time, and there seems an infinite wish-list. And it is all funded from membership fees which even those who are committing many times that amount in their own effort seem to question. > We must change W3C to fit the >changing needs. Absolutely. That is why the process provides for its own evolution. > W3C must allow us to change it because it can not change >itself. If you change W3C then you add to W3C so you are W3C. >Most of all, W3C must stop being arrogant bureacratic fools with >grandeur self image of being THE innovative leader with THE right vision. >To me, W3C is Tim Berners-Lee. Thanks. I will keep both of those remarks for when my head gets too big next. Let's face it I have this title of being The Inventor Of The Web for some of the media and their chief concern is often why I don't want to drive around in big cars and tell everyone what to do. Let me tell you that W3C is not me any more than Australia is the Queen of England. We are all innovative leaders and none of us have the right vision. But we all try. And you and I reserve the right to tear each other's vision apart. > Tim, you must stop thinking that you have a >monopoly on the future vision. [BTW When you address me please include me in the To: line of the message too!] Actually I was pretty happy doing techy stuff and trying to build a good process. But in the Tokyo AC meeting among other places, people stated very clearly that one of the things they wanted was a consistent plan for the future, a vision of where we were going, coupled with a derivation from that of the work and relationship of the various groups - and that that was my job. I am philsophically very against the "One True Vision" idea and am very happy for others to write theirs. In fact we all refine each others ramblings into the best consistent framework we can make at one point. I try to deliver the result to not just the W3C fee-investing people but anyone who can grab a web browser or a Intl. WWW conference. And don't think that my personal vision thing is all that is going out of W3C. There are plenty of examples where I would have done it differently. Everyone knows that I think the web loses 10 points every time we solve something using a processing instruction -- but the community wants it that way and we have http://www.w3.org/TR/xml-stylesheet/ I still think an RDF property would have been better but there we are. > Instead of pushing your vision, try building >a place where visions of others from far abroad can come together and >interact so that the right vision can be born out of them. That is just what I would love to do. You put it so well. But --- do you mean come together ...by plane? or telephone? or mailing list? From dream to reality, from concept to deployment plan -- that is the difficult bit with social syetems as well as technical ones. > Be a mother, not a father. If you mean, nurture, don't dictate, that sounds like sound advice, though put in a rather gender linked way ;-) Regards, Tim Berners-Lee > Best,Don Park - mailto:donpark@docuverse.com >Docuverse - http://www.docuverse.com > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 19 04:19:06 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:15:13 2004 Subject: Another look at namespaces References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU> <199909181437.KAA05856@hesketh.net> Message-ID: <016701bf0245$a632a880$0300000a@cygnus.uwa.edu.au> Simon St.Laurent wrote: > We seem to have fallen into linguistics. And the problem with that is what exactly? :-) Rick Jelliffe wrote: > >> Again, Andrew is simply conflating schema and namespace. The idea that > >> he and Tim are putting forward is that a language is defined by a single > >> set of content models; this confuses "language" with "grammar" Paul Prescod wrote: > >What definition of language are you using that does NOT state that every > >language has one and only one grammar. Is there a book I can read that > >defines it? The SGML Cookbook doesn't count. Simon St.Laurent wrote: > I could start with H.L. Mencken's _The American Language_ (Fourth Edition > with Supplements, 1948), in particular a citation of Noah Webster, in 1789: > (second supplement, p. 333) Simon, you are talking about natural languages whereas Paul is talking about formal languages. A formal language is a set of valid utterances. A (formal) grammar is a collection of rules for generating that set of utterances. Mind you, the notion of a formal grammar for a natural language is largely due to Chomsky and you've already said you were never fond of him :-) But that aside, XML is a formal language, not a natural one. Likewise, HTML 4.0 is (despite what anyone says) three separate (formal) languages. In the case of HTML 4.0, the three share a common vocabulary, but they are separate languages.

        [...] > "They seem not to consider that grammar is formed on language, and not language on grammar." > That last sentence seems to summarize the problem we're having here. Both "grammar" and "language" as they are used in this quote predate formal notions by quite a few years! I think Noah Webster's point is merely that linguistics should be descriptive, not perscriptive (first lesson in Linguistics 101) However, that point is misleading at best when applied to formal languages. In particular: * XML is a language defined by a grammar. * The XML REC clearly says that a DTD is a grammar for a class of documents. In a formal language view, this class of documents is a set of utterances---a formal language. > Whether or not _The SGML Cookbook_ makes this claim that a language is not > constrained to a single grammar, I'll be making that claim in my next book, Depending on what you mean by "not constrained to" and what type of languages you mean, I either completely agree or completely disagree with you :-) James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net Ceci n'est pas une pipe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From whisper at accessone.com Sun Sep 19 05:50:30 1999 From: whisper at accessone.com (David LeBlanc) Date: Mon Jun 7 17:15:13 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <049001bf0246$036d3c40$a60a1712@col.w3.org> Message-ID: <3.0.1.32.19990918204907.0154bd60@mail.accessone.com> At 10:23 PM 9/18/99 -0400, Tim Berners-Lee wrote: Having followed this thread and others of it's kind here and in various other places, I would like to submit a modest proposal which might satisfy all parties. I believe that the real problem underlying the complaints aired in this thread is that those people who are expected to promote and adapt reccommendations issued by the W3C seem to have little voice in the development of those reccommendations. TB-L and others have pointed out that the participants of the WG, in many cases, are reluctant to have their opinions etc. made public. Reasons given are unimportant - resolving them is the issue I want to address. As I understand it, WG's are constituted from member's employees and non-member "invited guests or experts". It also seems that these WG's are themselves the ones who will develop the reccommendation they are charterd to create. If, instead of being a development group, WG's where more of a steering group that: outlined the goals; issued periodic progress notes; issued periodic requests for comment; published the replies to requests for comment; organized and prduced the final reccommendation; then I think we would all feel that we had made a contribution to and that we had some voice/influence in it's development. Someone is bound to point out that is precisely what WG's already do. There are two changes I propose. Firstly, that all WG's have a requirement to inform and consult with the interested community on a reasonably frequent basis. The community so informed has no formal status in the WG (i.e. no voting rights), but does have the right to comment and contribute on the development issues and drafts on a consistant basis. Secondly to implement this, that progress notes, requests for comment and drafts be put up on the W3C site in the form of a wiki - an interactive document that anyone can annotate. (Indeed, I would think that a private form of this would be a great tool for the WG's themselves for their internal development process(es)). I think the formation of this sort of auxilliary to the WG's solves many problems: the WG gets feedback from qualified interested individuals (ok some flakes will appear too), the WG ends up with a better product from all the additional time and expertise brought to the development; and the interested user community has an avenue of communication and influence on the recommendations that they will end up using. Sorry if any or all of this is ideas that have been previously proposed, but i'm not aware of any. Dave LeBlanc P.S. As long as i'm on a soapbox, how about creating a W3UG ("Wug") - The WWW User's Group. Perhaps members are the ones who participate in the so-called WG auxiliary. Fees (and if it is as big as one might hope, there would need to be) would be as low as possible and based on the W3C's actual costs in administrating membership in the group. (I would hope that annual fees would be less then $50 and hopefully $25 or less.) - dhl xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at qub.com Sun Sep 19 06:50:28 1999 From: paul at qub.com (Paul Tchistopolskii) Date: Mon Jun 7 17:15:13 2004 Subject: W3C's 'Moral Majesty' References: <3.0.1.32.19990918204907.0154bd60@mail.accessone.com> Message-ID: <019501bf025b$295fffe0$5df5c13f@PaulTchistopolskii> Well ... I can not resist... I should not cut the rest of your letter, because I agree with almost every *word*. Even it may sound like a dream... From: David LeBlanc > outlined the goals; > issued periodic progress notes; > issued periodic requests for comment; > published the replies to requests for comment; If just *one* of those things would become practice, we may get much better progress with FOs than we have now, when W3C is assuming that it is more efficient to drive some standard not making any 'space' for people outside the WG. > Someone is bound to point out that is precisely what WG's > already do. That's simply not always true. Unfortunately. Rgds.Paul. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= paul@pault.com www.renderx.com www.pault.com XMLTube * Perl/JavaConnector * PerlApplicationServer =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.sun.com Sun Sep 19 07:47:04 1999 From: Jon.Bosak at eng.sun.com (Jon Bosak) Date: Mon Jun 7 17:15:13 2004 Subject: You can't tell the players without a program Message-ID: <199909190550.WAA00522@boethius.eng.sun.com> For purposes of reference, here is a list of the Phase III W3C XML Working Groups and their chairs. Jon Bosak Chair, W3C XML Coordination Group ======================================================================== XML Linking Working Group Tim Bray, Textuality Bill Smith, Sun Microsystems W3C staff contact: Daniel Veillard XML Schema Working Group Dave Hollander, CommerceNet C. M. Sperberg-McQueen, W3C XML Query Working Group Paul Cotton, IBM W3C contact: Massimo Marchiori XML Core Working Group Paul Grosso, ArborText David Megginson, Megginson Technologies W3C contact: Dan Connolly xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Sep 19 13:25:18 1999 From: Daniel.Veillard at w3.org (Daniel Veillard) Date: Mon Jun 7 17:15:14 2004 Subject: W3C and 'small vendors'. In-Reply-To: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii> References: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii> Message-ID: <19990919072750.D32047@w3.org> > "Hey! Just give me 5-10 teams, like renderx.com > who are frustrated with W3C - constantly rejecting > them - and we'l invent the lXML ( for free, like Linux > was created). lXML will *not* conform to W3C > specs but will *work*right*now*". Not to be annoying, but I think there is a myth here. If you think that rolling your own standard is in anyway similar to the Linux approach (and hence expecting the wide acceptance it got) you're IMHO really wrong. Linux was successful partly because it did stick to the POSIX standard far better than most commercial OSes. I guess there is only one exception where Linus decided to change the behaviour from the spec because, well it was clearly broken ! I still think that the Linux project (which I have followed quite closely since Spring 92) is a reimplementation effort of something which is/was a very well known problem. On the other hand XML while building on quite some expertise coming from SGML, HTML and related standards is rather in a definition phase, the problem is rather creating the standard than implementing it. We are working at a semantic and syntactic level, not purely implementation. Another myth is that adding code to the linux kernel can be done by anybody, I can guarantee you that Linus is at least as selective in deciding who he trust for taking the responsability of subparts of the kernel code than W3C groups in selecting invited experts ! Probably far more selective actually... There is areas of the kernel code that nearly nobody else will be able to touch. And honnestly this very tight control is probably the best reason why the project did stay successful. The more the area is near the kernel or the core, the harder it is to get changes. I guess it simply makes sense. Anyway I wouldn't try to draw too much parallel between W3C process and Linux developement one, they are pertaining to rather different level, Yours, Daniel -- 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, XML, http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 docuverse.com Sun Sep 19 16:13:04 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:14 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <049001bf0246$036d3c40$a60a1712@col.w3.org> Message-ID: <000701bf02a9$9e07c0a0$8c1ecca1@w21tp> Tim, Thanks for your sincere reply. When I wrote the original message, I was beating the drum of frustration and did not expect you to answer directly. I applogize if you found my message too harsh; I tend to over do it sometimes (some would say all the time). Although I generally need two sampling to get a feel for the scale of quality in any particular area, I think the F2F I went to was average in quality and definitely not a horrible meeting to an average person. It was my first so I had higher expectation than most people in the meeting. I could tell that the Chair was working hard to make real progress and everyone was trying to get some work done. But, with my high expectation, inefficiency of it all loomed largely in my memory. While there is someone to take minutes, there is a great deal of work being lost between the lines of the minutes. There is only finite amount of time allocated for each topic so discussions are hurried and usually scratches only the surface. My point is that, no matter how hard one tries, such meetings are just not very efficient by its nature. IMHO, F2F meetings should be used only to resolve serious conflicts and to edit the spec. Telephone meetings should likewise be used only to resolve minor conflicts and to have straw polls. Since serious conflicts are political in nature and not of technical nature, I have nothing against having those minutes remain confidential. With confidential matters isolated to F2F and telephone meetings, there should be no reason to keep the technical discussions confidential. Technical discussions should take place fully in public using a web-based project management tool that keeps track of issues, tasks, schedule, people, and resources visually over the web and allows threaded searchable discussions. Such tools are starting to appear now in the market so it is just a matter of deciding to use it. While I have other complaints, I believe above changes I suggested can go a long way in improving the W3C. If I had to sum it all up, it is this: 1. Increase public participation by separating political and technical discussions. 2. Don't just create standards, put them into practice to solve its own problems. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ken at bitsko.slc.ut.us Sun Sep 19 17:04:15 1999 From: ken at bitsko.slc.ut.us (Ken MacLeod) Date: Mon Jun 7 17:15:14 2004 Subject: Another try on groves In-Reply-To: Sean Mc Grath's message of "Sat, 18 Sep 1999 19:24:23 +0100" References: <3.0.6.32.19990918192423.00ab2850@gpo.iol.ie> Message-ID: Sean Mc Grath writes: > [Paul Prescod] > [...] > > A frame is not an "element", it has no "attributes". Now I claim > >that a frame is an object and that it has properties. And any idiot > >knows that objects can be represented in XML using a variety of > >techniques but think about the logic of doing it this way: you are > >taking a thing that is "logically" an object, expressing it in > >terms of a text file format so that another module in the same > >process can re-interpret it as logical objects. > > > >The *only good reason* to dumb something down into XML elements and > >attributes is to move the information between processes separated > >by space, time or incompatibility. > > I believe it makes perfect sense to *think* of MPEGS, PDFs, > whatever, in XML terms. > > I't does not of course, make sense to *store* them as XML owing to > the enormous size bloat. But who said the XML needs to physically > exist in disk? > > Case in point, I have written a SAX driver for the MySQL relational > database. I have SAX software that can happily trundling through 1GB > of records treating them as XML. The XML never physically exists but > the entire API used to process the MySQL is SAX. > > I can get programmers who have never seen MySQL, or its API, to > write MySQL processing apps using a purely XML API. I do not see why > the same cannot apply to other formats such as graphics, sound > etc. In fact, I am working on a BMP driver right now. To think of data in XML terms implies a translation that is (generally speaking) non-obvious. If it were obvious we wouldn't have so many efforts trying to map XML to objects and vice-versa. You can make *a* translation that is easy to use, but it won't (yet) be a general solution. Correct me if I'm wrong, but that's probably the approach (a [singular] translation) you used to map MySQL to SAX. I believe many people would agree with the idea behind your point, that a common API goes a long way to making communication and programming tasks simpler. That's what is being suggested with the grove paradigm: a common API can be used that provides more direct access to the underlying data, without requiring a semantic translation to XML first. -- Ken MacLeod ken@bitsko.slc.ut.us xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 19 17:40:39 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:14 2004 Subject: Another look at namespaces In-Reply-To: <016701bf0245$a632a880$0300000a@cygnus.uwa.edu.au> References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU> <199909181437.KAA05856@hesketh.net> Message-ID: <199909191543.LAA26903@hesketh.net> At 10:20 AM 9/19/99 +0800, James Tauber wrote: >Simon St.Laurent wrote: >> We seem to have fallen into linguistics. > >And the problem with that is what exactly? :-) In computing discussions, it usually signals that an enormous communications breakdown either has occurred or is occurring. Alternately, it could mean that we're on the edge of a massive breakthrough, but I don't think that's true in this case. >[many quotes] >Simon St.Laurent wrote: >> I could start with H.L. Mencken's _The American Language_ (Fourth Edition >> with Supplements, 1948), in particular a citation of Noah Webster, in >1789: >> (second supplement, p. 333) > >Simon, you are talking about natural languages whereas Paul is talking about >formal languages. A formal language is a set of valid utterances. A (formal) >grammar is a collection of rules for generating that set of utterances. I think you're both (James and Paul) overstating the distinction between natural languages and formal languages, at least in the case of XML-derived languages. I'm not convinced any longer that 'designing' a language makes any sense outside of very small arenas. HTML's development has been a mixture of design and evolution, and I don't think trying to put it back on the Procrustean bed of design is going to help us get anywhere. >But that aside, XML is a formal language, not a natural one. Likewise, HTML >4.0 is (despite what anyone says) three separate (formal) languages. In the >case of HTML 4.0, the three share a common vocabulary, but they are separate >languages. I think I have to suggest that there is a difference between HTML 4.0 (the formally specified, designed-by-experts version) and HTML (the one that's used in real life) - and do what we can to improve HTML, the real-life version. If XHTML wants to design changes, they'd do well do consider what the public will actually adopt, not try to force an odd notion of formal grammars mapping to namespaces upon that public. Of course, I already heard Tim Berners-Lee claim that "We are designing this, not investigating it as a natural phenomenon." So maybe I shouldn't be too hopeful in that direction. >[...] >> "They seem not to consider that grammar is formed on language, and not >language on grammar." >> That last sentence seems to summarize the problem we're having here. > >Both "grammar" and "language" as they are used in this quote predate formal >notions by quite a few years! I think Noah Webster's point is merely that >linguistics should be descriptive, not perscriptive (first lesson in >Linguistics 101) See above. I think you're making too strong a claim about XML vocabularies as formal languages. I'd happily argue that they're a bunch of evolved conventions strung together - much like natural languages, though usually chopped down by a bunch of analysts. Where's Walter Perry when I need him? >However, that point is misleading at best when applied to formal languages. >In particular: > >* XML is a language defined by a grammar. XML provides a foundation - much like letters give English and alphabet to create words with. (Tim Bray: "XML is ASCII, etc.") >* The XML REC clearly says that a DTD is a grammar for a class of documents. >In a formal language view, this class of documents is a set of >utterances---a formal language. Except that in many cases there are multiple DTDs (for testing different claims), or, in fact, no DTD at all. Without a DTD, are we truly 'grammar-less'? I don't think so. >> Whether or not _The SGML Cookbook_ makes this claim that a language is not >> constrained to a single grammar, I'll be making that claim in my next >book, > >Depending on what you mean by "not constrained to" and what type of >languages you mean, I either completely agree or completely disagree with >you :-) I guess you'll have to buy the book and find out! (Gross sales pitch, eh?) Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sun Sep 19 18:04:24 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:14 2004 Subject: namespace for unparsed entity Message-ID: <199909191607.MAA27697@hesketh.net> This question deals with 'namespaces' as used by section 4 of the XML 1.0 recommendation, NOT namespaces as described by the Namespaces in XML recommendation. The paragraph below is from section 4 of the XML 1.0 recommendation: >General entities are entities for use within the document content.... >Parameter entities are parsed entities for use within the DTD. These >two types of entities use different forms of reference and are >recognized in different contexts. Furthermore, they occupy different >namespaces; a parameter entity and a general entity with the same name >are two distinct entities. This only describes the two kinds of _parsed_ entities, not the third possibility of unparsed entities. Do unparsed entities likewise have their own namespace? It seems like a processor could get confused if there were unparsed and general entities with the same name, making it potentially difficult to enforce the rules about referencing unparsed entities in content and general entities in attributes of type ENTITY or ENTITIES. I don't see any notes on this in the errata, so I'm hoping there's a good simple answer. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 boblyons at unidex.com Sun Sep 19 19:08:07 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:15:14 2004 Subject: should FOP require JDK1.2.x? Message-ID: <01BF02A0.542643C0@cc398234-a.etntwn1.nj.home.com> James Tauber wrote: "I'd be interested in hearing people's views on the simple question: should FOP (my XSL formatter/renderer) require JDK1.2.x? At present it works with 1.1.x. What are other XML developers doing? Should I stick to 1.1.x compatibility? Or can I require 1.2.x without offending too many people?" James, One advantage of sticking with 1.1.x is that IE 4.0 and IE 5.0 include Microsoft's Java VM, which supports Java 1.1.x, but not Java 1.2.x. I suspect that many of your users have IE 4.0 or 5.0 on their PCs, but not JDK 1.2.x. Also, the last time I checked (several months ago), IBM's Java virtual machine for AIX supported Java 1.1.x, but not 1.2.x. Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From srn at techno.com Sun Sep 19 19:18:39 1999 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:15:14 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <049001bf0246$036d3c40$a60a1712@col.w3.org> (timbl@w3.org) References: <049001bf0246$036d3c40$a60a1712@col.w3.org> Message-ID: <199909191719.MAA03613@bruno.techno.com> [Tim Berners-Lee:] > It is not a question of membership in W3C - as there is a way (as > you found) for non-members to come to meetings as invited experts - > the criterion is commitment of effort and acceptance of the charter. No, these are not the governing criteria, as you of all people know best, Tim. The actual criterion on which invitations are based is whether or not you're invited. No number of requests to be invited, presentations of credentials, commitments of effort, or acceptances of a charter can overcome the problem of not being invited. Today, the W3C process is not an open process, and it's not a system that ordinary people can get involved in and "change from within". The W3C process is the (rather unwieldy) tool of the dominant software vendors, balanced against the flawed personal vision and absolute veto power of its Director, a single human being named Tim Berners-Lee. The institutional structure of the W3C was not designed to serve the public interest, and even the most cursory analysis reveals that there is little reason to expect it to create standards that are optimized for serving the public interest. Everyone involved primarily serves special interests, and the public is neither invited nor involved in any meaningfully institutionalized fashion. The W3C is a software vendor consortium; people (including W3C members) who believe otherwise are deluding themselves. With the exception of XML 1.0 (which itself is rapidly being subverted via XML Namespaces, etc.), W3C standards always leave room for the products of software vendors to become indispensable to the usefulness of particular pieces of information. The idea that the role of software is the central organizing feature of information interchange standards is contrary to the public interest. Software is ephemeral, while information is eternal. Everyone owns information, while only software vendors own software. The idea of polluting all information with names from namespaces whose semantics and syntactic constraints are expressed by the behavior of a particular hunk of software is an idea that is consistent with the welfare of software vendors. It is not consistent with the welfare of information owners; they won't be able to buy software from the lowest bidder. The public consists of information owners, not software vendors. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 fax +1 972 994 0087 pager (150 characters max): srn-page@techno.com 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 ricko at allette.com.au Sun Sep 19 19:31:21 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:14 2004 Subject: Another look at namespaces Message-ID: <001001bf02c5$1022c430$42f96d8c@NT.JELLIFFE.COM.AU> From: Paul Prescod >There is a world of difference between saying that a namespace *is a >schema* and saying that there are a set of W3C specifications (including >XHTML) that have namespaces that have a one to one correspondance with >schemas. It's like saying that "p" doesn't have to be defined in a DTD >(because not every XML document has DTDs) but the *HTML* "p" *is* >defined in a DTD (which has been the stance since HTML 2). html:p 1) is an element for generic paragraphs (semantics); 2) is typically displayed as a block, and has sub-elements that are typically displayed inline (presentation); 3) is under the body element of an HTML document (schematic, but defined from descendnt to ancestor). That defines the html:p element type pretty completely, yet no grammar (in the sense of content models on child elements) is involved. IMHO DTDs/content-models actually disguise or fail to express the real schema in html:p, which is more like the three points above. What the content model gives is a way to validate a document, and a way to construct a document after the deep structures (classes/archetypes/extended containment/cohesion) have been abstracted away or ignored. That is a good enough model for a DTD, but hardly a good enough one for naming purposes; a name should express what a thing is, and to say that HTML has three namespaces because it has 3 DTDs is to get tripped up on a mere artifact of the modeling capabilities of DTDs. (And in any case, a strictly conforming XHTML document has to have a DOCTYPE declaration, so the namespace declarations don't actually provide any information in the document than could be found there already.) Why should blahblah have to use a different namespace to blah blah ? Lets allow extensibility from the start. 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 Daniel.Brickley at bristol.ac.uk Sun Sep 19 20:03:27 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:15:14 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <199909191719.MAA03613@bruno.techno.com> Message-ID: On Sun, 19 Sep 1999, Steven R. Newcomb wrote: [sniiiippppp] > [...] The W3C is a software vendor consortium; people (including W3C > members) who believe otherwise are deluding themselves. [...] I'm sorry, I can't let this one just slip past. As Bristol University's Advisory Committee representative to W3C, I can assure you that agendas other than software vending are represented. Bristol University may be many things, and there are many groups here who do produce saleable software, but we're not software vendors. We joined W3C to participate in the development of specifications that affect teaching, learning and research applications in our *.ac.uk environment. And we're not alone in this... Dan -- Daniel.Brickley@bristol.ac.uk University of Bristol, Bristol BS8 1TN, UK. phone:+44(0)117-9287096 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From boblyons at unidex.com Sun Sep 19 20:41:41 1999 From: boblyons at unidex.com (Robert C. Lyons) Date: Mon Jun 7 17:15:14 2004 Subject: should FOP require JDK1.2.x? Message-ID: <01BF02AD.681DE290@cc398234-a.etntwn1.nj.home.com> James, I just checked IBM's site. They now offer a preview release of Java 1.2 for AIX. (See http://www.alphaworks.ibm.com/tech/aixforjava2.) The other IBM Java virtual machines support 1.1.x, but not 1.2. I found the following list at http://www.ibm.com/java/jdk/download/index.html: - IBM Developer Kit for Linux ?, Java (TM) Technology Edition, alphaVersion 1.1.6 (June 1999) - IBM's port of Java 1.1.6 for AIX GA plus JIT (24 September 1998) with PTFs from 2 June 1999 - IBM's port of Java 1.1.8 for AIX Developer Release plus JIT (2 June 1999) - IBM Developer Kit for Windows, Java Technology Edition, Version 1.1.8 GA plus JIT (30 July 1999) - IBM's port of Java 1.1.8 for OS/390 GA plus JIT (30 July 1999) - IBM's port of Java 1.1.8 for OS/2 Warp GA plus JIT (30 July 1999) - IBM's port of Java 1.1.4 for VM/ESA plus NetRexx (28 August 1998) Bob ------ Bob Lyons EC Consultant Unidex Inc. 1-732-975-9877 boblyons@unidex.com http://www.unidex.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schen at falconwing.com Sun Sep 19 20:45:47 1999 From: schen at falconwing.com (schen@falconwing.com) Date: Mon Jun 7 17:15:14 2004 Subject: should FOP require JDK1.2.x? In-Reply-To: <011c01bf023d$c9c11c80$0300000a@cygnus.uwa.edu.au> Message-ID: Hi James, everyone, On Sun, 19 Sep 1999, James Tauber wrote: > I'd be interested in hearing people's views on the simple question: should > FOP (my XSL formatter/renderer) require JDK1.2.x? At present it works with > 1.1.x. > > What are other XML developers doing? Should I stick to 1.1.x compatibility? > Or can I require 1.2.x without offending too many people? Not all platforms have stable 1.2 support yet, in fact the only two platforms that seem to be ok are Windows and Solaris, with Sun's JVM. What features do you need out of 1.2 that are compelling enough to require the move? For both Swing and the collection classes, there are unbundled versions available for 1.1. On the other hand, if FOP is just targetting bleeding-edge users, it would make sense if you really need the 1.2 features. . . . Sean. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sun Sep 19 20:58:27 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:14 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: References: <199909191719.MAA03613@bruno.techno.com> Message-ID: <199909191900.PAA32396@hesketh.net> At 07:06 PM 9/19/99 +0100, Dan Brickley wrote: >On Sun, 19 Sep 1999, Steven R. Newcomb wrote: >> [...] The W3C is a software vendor consortium; people (including W3C >> members) who believe otherwise are deluding themselves. >[...] > >I'm sorry, I can't let this one just slip past. As Bristol University's >Advisory Committee representative to W3C, I can assure you that agendas >other than software vending are represented. Bristol University may be >many things, and there are many groups here who do produce saleable >software, but we're not software vendors. We joined W3C to participate >in the development of specifications that affect teaching, learning and >research applications in our *.ac.uk environment. And we're not alone >in this... While Dan is right - there are in fact customer organizations, even non-profit customer organizations, with representation and participation at the W3C - Steven's point still holds a lot of water, if not quite as much as before. One key area of 'consumers' that I don't see represented as W3C members is open source software developers, which almost by definition don't have the resources to pay the fees. (There are, admittedly, some very wealthy open source developers - I don't count myself among them.) Even more formal organizations like the Apache Group don't appear to be represented (last I checked). IBM develops some open source software, even important open source software, but I think they're something of a special case, to say the least. There doesn't appear to be any way to get into the W3C by sweat equity, unless of course a group wants to invite you into the process as an invited expert. Invited expert invitations don't have any direct connection to sweat, however - as Steven pointed out earlier, it's a matter of being _invited_, not of _earning_ a seat at the table. Also, as Tim Berners-Lee pointed out, invited experts must pledge "commitment of effort and acceptance of the charter". Acceptance of the charter implies accepting all the secrecy that goes along with the W3C's activities, something I wouldn't accept - and something that seems deeply incompatible with the open participation principle underlying most open source projects. If the 'top people' in a project can participate at the W3C, they're still hampered from taking advantage of the full power of their development base by the rules keeping them from sharing information on W3C activities. (I realize that the W3C itself operates several excellent open-source projects. Unfortunately, this work does not seem to have had an effect on the approach taken by the main body of W3C activities.) The tumult and chaos of the browser wars seem to have numbed many developers into accepting the W3C's status uncritically, but I don't know how long that acceptance will last. Opening participation significantly would seem to give the W3C a lot more legitimacy heading into the future, although it would certainly increase the pressure for accountability by the W3C. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Sun Sep 19 20:58:20 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:15 2004 Subject: W3C and 'small vendors'. In-Reply-To: <19990919072750.D32047@w3.org> References: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii> <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii> Message-ID: <199909191900.PAA32401@hesketh.net> At 07:27 AM 9/19/99 -0400, Daniel Veillard wrote: >Paul Tchistopolskii: >> "Hey! Just give me 5-10 teams, like renderx.com >> who are frustrated with W3C - constantly rejecting >> them - and we'l invent the lXML ( for free, like Linux >> was created). lXML will *not* conform to W3C >> specs but will *work*right*now*". > > Not to be annoying, but I think there is a myth here. > >If you think that rolling your own standard is in anyway similar to >the Linux approach (and hence expecting the wide acceptance it got) >you're IMHO really wrong. > Linux was successful partly because it did stick to the POSIX standard >far better than most commercial OSes. I guess there is only one >exception where Linus decided to change the behaviour from the spec >because, well it was clearly broken ! I think, actually, that 'reinventing XML' wouldn't be so difficult, in part because XML and SGML provide a similar foundation to POSIX. The problems are relatively well understood, and evolving XML in an open fashion is conceivable. Creating processors that use such evolution would require commitment from developers, but perhaps the ownership that comes with participation could spur such work, much as many of the early XML parsers came from people who were actually involved in the development of XML 1.0. Getting widespread support might be difficult, but there are plenty of ways to keep an 'Open XML' within the XML tent - by creating it as a subset, for instance, that would be interoperable. Tools like processing instructions can be used to insure that interoperability was maintained, while allowing 'Open XML' to go its own way on issues deemed important. I'm not sure I'm ready to support such a project, but feasibility doesn't seem to be a problem. The trademark on XML might be more of a problem, but Linux did find a way around that - by not calling it Unix(tm). Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical Sharing Bandwidth / Cookies http://www.simonstl.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Sep 19 21:08:28 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:15 2004 Subject: Another look at namespaces Message-ID: <006001bf02d3$3f75c120$42f96d8c@NT.JELLIFFE.COM.AU> From: Tim Berners-Lee >From: Rick Jelliffe > >>The only information that properly belongs in a namespace is a list of >>names. > >That is not useful. I realize that the word "Namespace" (as the end result >fo the discussions of modules or docuemnt types or vocabularies or...) >may be an english word which does not convey this, but a >a namespaces is a language: a set of names plus a set of syntactic >constraints plus - to be useful - a meaning shared by writer and recipient. A name is useful by being available for use in a schema, document, program, query, stylesheet or language. That use may be merely to disambiguate from where these unique elements are only used by a stylesheet to display some appropriate graphic. "The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists)." http://www.w3.org/TR/REC-xml-names/ s2 The spec clearly says that to be useful, a namespace URI does *not* have to identifiy anything. It only has to provide uniqueness and persistence. The first paragraph of the namespaces spec begins: "We envision applications of Extensible Markup Language (XML) where a single XML document may contain elements and attributes (here referred to as a 'markup vocabulary') that are defined for and used by multiple software modules. " Namespaces are concerned with vocabularies (lists with meanings, not schemas: the words "schema" and "language" were available and were *not* used). Schemas are constructed from vocabularies. >I have noone associated with W3C say that a "a namespace is a schema" Err, isn't that your position above? You say that a namespace cannot be merely a list of names but must be "a language: a set of names plus a set of syntactic contstraints" (sounds like a syntactic schema to me) plus "a menaing shared by writer and recipient" (sounds like a semantic schema). Indeed your whole first posting to XML-DEV on namespace concerned schemas and validity. "For example, you can run an xHTML document though any DTD you like if it suits your purposes, but if you want to check whether it is valid xHTML then you should use the xHTML schema which corresponds to the namespace URI." If the namespace URI is a schema URI, then the namespace is a schema. {In another posting} >Perhaps perception of it is clouded by the fact that XML 1.0 doesn't mention >namespaces at all, and XML NS does not mention schemas at all. >In other words, the specs -- having to only refer backwards in time -- >have not been good at pointing to how the future architecure will fit >together. No, perception is clarified by memories of how much effort and debate it took to get mentions of schemas taken out of the Namespace document. The early drafts were full of mentions of schemas. For example, http://www.w3.org/TR/1998/WD-xml-names-19980327 even says "local schema namespace", combining them. That the XML NS does not mention schemas is by intent: to avoid mixing up schemas and namespaces. When the XHTML draft uses three different namespaces for the same elements, it does just that. I note Shane P. McCarron's recent post "With regard to namespaces, IMO the work on Modularization is orthogonal to namespaces." If future modularized XHTML does not conflate schemas and namespaces, what is the "future architecture" that makes it so important to have three? 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 tbray at textuality.com Sun Sep 19 21:11:24 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:15:15 2004 Subject: Some notes on process: F2F & telcon & email Message-ID: <3.0.32.19990919121402.00cc2620@pop.intergate.bc.ca> Just data points, to help fuel this (useful) discussion. I'm particularly impressed by contributions that contain proposals for change that are concrete and achievable in the real world, particularly unimpressed by w3c-is-the-empire-and-Berners-Lee-is-Darth flames. 1. XML 1.0 was developed by email and telecon almost completely without benefit of face-2-face meetings. Both modes of communication were essential. 2. XML 1.0 was a guerilla project by a bunch of people who'd known each other for years and very few of whom had management that understood what it was really about. 3. The DOM makes heavy use of face-2-face meetings. 4. The DOM WG is largely populated by senior engineers who are totally overcommitted and find difficulty, when at work, focusing on anything not about work. 5. Don Park's characterization of a WG face-2-face runs strongly counter to my experience. What was your sample size, Don? 6. The heaviest rudeness and the highest level of bad behavior and time-wasting take place in email. 7. It is ethically unacceptable to have all the f2f meetings in North America, and insanely costly (in money and person-time) to have them elsewhere. 8. Wide variance in dynamics and work style from WG to WG is the rule, not the exception. 9. The personality and style of the chair, W3C contact, and editors has a strong influence on dynamics and work style. 10. The #1 problem in the process is lack of bandwidth from key people. 11. People who first show up in the public mailing lists regularly graduate to IG membership, WG memership, and chair/editor status. Examples without thinking too hard would be David Megginson, John Cowan, and James Tauber. 12. 2 or 3 years ago, most WGs had chairs and editors who were W3C staff. These days (particularly in the XML activity) the chairs and editors come from the membership, and to a disproportionate degree, from the ranks of invited experts. -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 Sun Sep 19 21:11:28 1999 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:15:15 2004 Subject: W3C's 'Moral Majesty' Message-ID: <3.0.32.19990919115750.0120e420@pop.intergate.bc.ca> At 12:19 PM 9/19/99 -0500, Steven R. Newcomb wrote: >The W3C process is the (rather unwieldy) tool of the dominant software >vendors, balanced against the flawed personal vision and absolute veto >power of its Director, a single human being named Tim Berners-Lee. This is simply not the case. The idea of Michael Sperberg-McQueen or James Clark or David Megginson or Ann Navarro as a "tool of the dominant software vendors" is laughable. > Everyone involved primarily serves >special interests... This is simply not true. Fortunately, those of us who are not software vendors and have been doing pro-bono work in this process have pretty thick skins, or we wouldn't still be doing it. >The idea of polluting all information with names from namespaces whose >semantics and syntactic constraints are expressed by the behavior of a >particular hunk of software The notion that the complete semantics of an element or attribute can be captured in software is just as silly and limiting as the idea that those semantics can be captured entirely by a schema or a stylesheet or human-readable prose. The latter comes closest in my opinion, but all are necessary in the real world. Namespaces are a facility to make names universal, no more, no less. If we had no computers, generalized markup would be a silly idea. Generalized descriptive markup is a consequence of the fact that we want to enable (unpredictable, non-proprietary) processing of structured content. Making the names that populate that markup universal, so that vocabularies can freely be mixed, simply adds robustness to the system in the face of the fact that the days of the Great Centralized Committee-Built DTD In The Sky are over (good riddance). -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 ricko at allette.com.au Sun Sep 19 21:21:12 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:15 2004 Subject: W3C's 'Moral Majesty' Message-ID: <00af01bf02d5$084d0c60$42f96d8c@NT.JELLIFFE.COM.AU> From: Tim Bray >...Making the names that populate that markup universal, so that >vocabularies can freely be mixed, simply adds robustness to the system in >the face of the fact that the days of the Great Centralized Committee-Built >DTD In The Sky are over (good riddance). -Tim Except for the 3 XHTMLs! 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 jmbolles at ThoughtWorks.com Sun Sep 19 22:15:43 1999 From: jmbolles at ThoughtWorks.com (jmbolles@ThoughtWorks.com) Date: Mon Jun 7 17:15:15 2004 Subject: On a more pleasant note Message-ID: If I understand the problem correctly, this is an ideal place to use XSLT - use pattern matching as necessary to distinguish your xml tags from html tags, and apply templates appropriately. Jack Bolles Thoughtworks, LLC PS: In the XML I'm sending out from the server, I am embedding some human readable text encoded, obviously enough, in HTML. What would be a good way to distinguish it from my own XML tags so that I can extract it and feed it to the HTML renderer? Any suggestions? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Sep 19 22:17:16 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:15 2004 Subject: W3C's 'Moral Majesty' Message-ID: <00c201bf02dc$daf84e70$42f96d8c@NT.JELLIFFE.COM.AU> Before I start, I should say again that I hope that we can keep this away from sounding like attacks on individuals. Already some W3C people apparantly think that people raising serious questions are "agitated" or conspiracy theorists (though of course GBS's aphorism along the lines that "Every profession turns into a conspiracy against the public" should be salutory to us all). From: Dan Brickley >On Sun, 19 Sep 1999, Steven R. Newcomb wrote: >> [...] The W3C is a software vendor consortium; people (including W3C >> members) who believe otherwise are deluding themselves. >[...] > >I'm sorry, I can't let this one just slip past. As Bristol University's >Advisory Committee representative to W3C, I can assure you that agendas >other than software vending are represented. Bristol University may be >many things, and there are many groups here who do produce saleable >software, but we're not software vendors. We joined W3C to participate >in the development of specifications that affect teaching, learning and >research applications in our *.ac.uk environment. And we're not alone >in this... (My employer, Academia Sinica, has also recently joined W3C.) It is clear from (public) member lists that non-commercial interests do not dominate numerically or financially. Rick Jelliffe Not speaking privately, not on behalf of my employer. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Sun Sep 19 22:20:40 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:15 2004 Subject: an unfilled need Message-ID: <00c701bf02dd$571ed690$42f96d8c@NT.JELLIFFE.COM.AU> I note Ann Navarro's call for "An unfulfilled need" earlier this month, on a subject I also have been calling for for 2 years+: the need for a mechanism to bind information to names: "definitions, semantics, and other data that may be necessary to complete their operations." This looks to me like a case of two non-commercial voices being lost to more important voices. I wonder if the reason can be found in Tim B-Ls recent post: > Rick Jelliffe: >>There is no W3C method to declare which schema should be >>used, akin to the stylesheet declaration. > Yes there is: resolution of the schema URI. Tim is saying that using the namespace URI to specify a schema is the official W3C method. But there is nothing about this in any W3C spec; no working group has decided this or put it out in a public draft or spec. On the contrary "It is not a goal that it [the namespace URI] be directly usable for retrieval of a schema (if any exists)" says XML NS. That is a major architectural decision implied on top of namespaces; the only parties I see that can benefit from hardcoding schema URIs into namespace URIs are vendors, who could use this mechanism and only provide schemas in languages which they controlled or provided tools for: I don't think this is far-fetched-- Biztalk mandates XDR schemas only. 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 michael_champion at ameritech.net Sun Sep 19 23:10:59 1999 From: michael_champion at ameritech.net (Michael Champion) Date: Mon Jun 7 17:15:15 2004 Subject: should FOP require JDK1.2.x? References: Message-ID: <004101bf02e3$aababde0$3ebdb3c7@mccdell> ----- Original Message ----- From: To: James Tauber Cc: XML-Dev Mailing list Sent: Sunday, September 19, 1999 2:47 PM Subject: Re: should FOP require JDK1.2.x? > Not all platforms have stable 1.2 support yet, in fact the only two > platforms that seem to be ok are Windows and Solaris, with Sun's JVM. > > What features do you need out of 1.2 that are compelling enough to require > the move? For both Swing and the collection classes, there are unbundled > versions available for 1.1. > > On the other hand, if FOP is just targetting bleeding-edge users, it would > make sense if you really need the 1.2 features. I suspect that FOP is targeting users for the forseeable FUTURE; if there is anything tangible in 1.2 that would make the spec cleaner and more powerful, I'd say to use it, even at the cost of some short-run inconvenience. Today's bleeding edge is next year's plain old ordinary stuff, and the year after that's "legacy code". Mike Champion xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 docuverse.com Sun Sep 19 23:39:06 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:15 2004 Subject: Some notes on process: F2F & telcon & email In-Reply-To: <3.0.32.19990919121402.00cc2620@pop.intergate.bc.ca> Message-ID: <000001bf02e7$d9ec34a0$8c1ecca1@w21tp> Tim, There is no such thing as a perfectly efficient process. There is always room for improvement and there are always more than one way to do it. If one solution does not work, another should be tried. That is all I am trying to do between my whining sessions. If I stayed quiet, would W3C or TimBL have come out and answered the questions? I don't think so. Even if suggestions for improvements come packaged in barbs, value of the content still stands, and if W3C is wise enough to see it, it will benefit from it. I am not saying my solution will work for W3C; it could be full of holes. I am saying W3C should not think it has a perfectly working system. Based on TimBL's reply, I am more hopeful than before that something good will come out of all this. Confidentiality is a problem for the public and a necessity for W3C. This is just a problem to be solved in my view, so I am hacking at it. Even if a solution can not be found, we would have gained more understanding. As I stated in my other recent message, I believe confidentiality can be reduced without hurting W3C by limiting them to F2F and telephone conferences which should mainly deal with non-technical conflicts and not to be used for technical discussions. I also believe that WG/IG mailing lists should be replaced with web-based tools and made available to the public. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schen at falconwing.com Sun Sep 19 23:41:59 1999 From: schen at falconwing.com (schen@falconwing.com) Date: Mon Jun 7 17:15:15 2004 Subject: should FOP require JDK1.2.x? In-Reply-To: <004101bf02e3$aababde0$3ebdb3c7@mccdell> Message-ID: On Sun, 19 Sep 1999, Michael Champion wrote: I wrote: >> Not all platforms have stable 1.2 support yet, in fact the only two >> platforms that seem to be ok are Windows and Solaris, with Sun's JVM. [ ... ] >> On the other hand, if FOP is just targetting bleeding-edge users, it >> would make sense if you really need the 1.2 features. > I suspect that FOP is targeting users for the forseeable FUTURE; if > there is anything tangible in 1.2 that would make the spec cleaner and > more powerful, I'd say to use it, even at the cost of some short-run > inconvenience. > Today's bleeding edge is next year's plain old ordinary stuff, and the > year after that's "legacy code". Of course that is true, but if James is hoping for a wide array of beta-testers and co-developers, then it doesn't make sense to move to 1.2 completely unless there is a compelling case where complicated code that is limited by 1.1 capabilities can be reduced in a single stroke by moving to 1.2. Many times a migration can be put off or at least 1.2-dependent functionality can be modularized. For example, I found it advisable to use the 1.2 Java collection classes, but I'm fortunate in that Sun released a version of those for 1.1 users. Swing is similar in that fashion. On the other hand, dependence on features such as Java 2D, printing, and Media would mandate a move to 1.2. We could make a more concrete determination if James outlined the features he's looking to use in 1.2. . . . Sean. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From francis at redrice.com Mon Sep 20 00:13:20 1999 From: francis at redrice.com (Francis Norton) Date: Mon Jun 7 17:15:15 2004 Subject: Another try on groves References: <37E1532B.82F3BB03@prescod.net> <37E20A5C.75E79B93@redrice.com> Message-ID: <37E560B1.8B0B7E12@redrice.com> Ken MacLeod wrote: > > Francis Norton writes: > > > Now that I have some feeling for the rationale behind Groves, I'd be > > very interested in knowing what this might mean for implementations. > > > > Could one come up with a language independent API like the DOM, to > > which Grove compliant APIs would conform? Presumably there is more > > complexity in that the DOM has a closed set of underlying object > > types whereas each Grove interface would would have different > > underlying object types. In Java terms, would this be an interface > > (a totally abstract class which guarantees a core functionality in > > any object which implements it)? Has anyone in fact built CORBA IDL > > or a Java interface defining the Grove API, or am I coming in at the > > wrong level? > > I'd like to believe you're coming in at the wrong level. Many > languages have built-in syntax to access ``members of objects'' or > ``fields of records'' that can often be applied to accessing > ``properties of nodes''. In this case, the grove API is the > language's native syntax. > > Where native syntax is not applicable, groves most closely resemble > container classes (dictionaries, mappings, hash tables; lists, arrays, > sequences). Again, a language's standard container class interface or > protocol can be used. > I've gone back to my copy of Paul Prescod's short tutorial (which I can no longer find on the 'net - does anyone have a live URL for it?) and found in section 2.2 a case against the DOM approach of defining an API in IDL, "... We have found this very limiting in the Python and Perl worlds. With these high level languages there are more convenient ways of mapping the high level XML concepts into APIs than the ways dictated by CORBA. ..." So what *is* a grove implementation? For instance I think of a DOM implementation as a program that includes or harnesses an XML parser and provides DOM bindings for a language or protocol (such as COM). I know that it is a DOM implementation because it follows the pre-defined DOM API - how will I know if something is a Grove implementation? To extend the Mozilla analogy, would a Grove-compliant world offer our switched-on programmer (1) a language-dependent but notation-independent API, so that her clever features could operate, at run-time, on media that she hadn't specifically supported at build-time; or (2) would it simply become much simpler for her to support new media at build-time, even though each new notation would still require explicit coding to exploit its grove features? If (2) am I just confusing matters by talking about APIs when perhaps the real Grove implementation effort is in defining the Grove-compliant information set for each notation? Francis. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 20 00:18:28 1999 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:15:15 2004 Subject: W3C's 'Moral Majesty' In-Reply-To: <00c201bf02dc$daf84e70$42f96d8c@NT.JELLIFFE.COM.AU> Message-ID: On Mon, 20 Sep 1999, Rick Jelliffe wrote: > Before I start, I should say again that I hope that we can keep this > away from sounding > like attacks on individuals. Already some W3C people apparantly think > that people > raising serious questions are "agitated" or conspiracy theorists (though > of course > GBS's aphorism along the lines that "Every profession turns into a > conspiracy against > the public" should be salutory to us all). > > From: Dan Brickley > > >On Sun, 19 Sep 1999, Steven R. Newcomb wrote: > > >> [...] The W3C is a software vendor consortium; people (including W3C > >> members) who believe otherwise are deluding themselves. > >[...] > > > >I'm sorry, I can't let this one just slip past. As Bristol University's > >Advisory Committee representative to W3C, I can assure you that agendas > >other than software vending are represented. Bristol University may be > >many things, and there are many groups here who do produce saleable > >software, but we're not software vendors. We joined W3C to participate > >in the development of specifications that affect teaching, learning and > >research applications in our *.ac.uk environment. And we're not alone > >in this... > > (My employer, Academia Sinica, has also recently joined W3C.) It is > clear from (public) member lists that non-commercial interests do not > dominate numerically or financially. This is true. Non-commercial organisations rarely dominate financially. I would also be suprised for non-commercial organisations to dominate a forum such as W3C. But that wasn't the point I was responding to. Although vendors dominate, W3C isn't a vendor-only forum. There are a number of us from other environments. I guess I'm just reacting against the word 'delusional' above which seemed a little too strong. It is expensive to put resources into any standards process. When Bristol joined W3C, it cost us roughly the same as buying, equiping and maintaining a PC. I think we've had a good run for our money. While I didn't (and don't) like paying membership fees for this work, when looking at the budgets, it's not so vastly different from what it would cost us to participate in other activities eg. flying off to biannual IETF meetings or whatever. My only point here is that it is quite possible for organisations such as ours to have a voice, and that in my experience the financial cost of membership fees is overshadowed by the cost of having researchers' time dedicated to working on this stuff (either in a W3C context or simply in a research / product development context). By characterising W3C as a vendor-only environment, this sort of involvement by other balancing voices is discouraged. Personally I would like to see a lot more *.ac.uk and *edu organisations play an active role in W3C work. While the fees are_ a barrier, a bigger barrier is the self-fulfilling notion recently circulated here that W3C is vendor-only. Dan -- Daniel.Brickley@bristol.ac.uk University of Bristol, Bristol BS8 1TN, UK. phone:+44(0)117-9287096 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Sep 20 02:04:00 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:15 2004 Subject: W3C and 'small vendors'. In-Reply-To: <19990919072750.D32047@w3.org> References: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii> <19990919072750.D32047@w3.org> Message-ID: <14309.31363.477992.969459@localhost.localdomain> Daniel Veillard writes: > Another myth is that adding code to the linux kernel can be done > by anybody, I can guarantee you that Linus is at least as selective > in deciding who he trust for taking the responsability of subparts > of the kernel code than W3C groups in selecting invited experts ! > Probably far more selective actually... There is areas of the > kernel code that nearly nobody else will be able to touch. > > And honnestly this very tight control is probably the best reason > why the project did stay successful. The more the area is near the > kernel or the core, the harder it is to get changes. I guess it > simply makes sense. To balance this analogy, it's important to remember that Linus sticks to the kernel and leaves the other layers alone (he doesn't try to tell Richard Stallman how to run the Gnu project, for example). XML should work that way (and the naming mechanism described by Namespace in XML takes us partway there), but there is an annoying co-dependency between developers -- who both expect the W3C to define everything XML-related and blame it for trying to do too much and/or taking too long -- and the W3C itself, who likes the attention, positive or negative. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Sep 20 02:09:41 1999 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:15:15 2004 Subject: should FOP require JDK1.2.x? In-Reply-To: References: <011c01bf023d$c9c11c80$0300000a@cygnus.uwa.edu.au> Message-ID: <14309.31704.125439.459475@localhost.localdomain> schen@falconwing.com writes: > Not all platforms have stable 1.2 support yet, in fact the only two > platforms that seem to be ok are Windows and Solaris, with Sun's > JVM. JDK 1.2 behaves very well on Linux as well, at least as far as I've pushed it over the past few months. 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 bckman at ix.netcom.com Mon Sep 20 02:42:26 1999 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:15:15 2004 Subject: Re xml-dev Digest V1 #348 Message-ID: <001101bf0301$aba79340$19acdccf@oemcomputer> It seems as though you seriously suggest that the lack of documentation of the technical process of creating the spec (specifically, the issues, the alternatives, and the rationale for the adopted solutions) is "OK" since one can simple E-mail some WG member and ask him to explain it for you. After all, it works so well for you! There is usually a requirements document, followed by several public working drafts working drafts, followed by a propoaed recommendation, followed by a recommendation. Public input is invited at every stage of this process. At any rate, I don't have the E-mail addresses of the XHTML WG members. I can't officially get these addresses AFAIK. The addresses of the editors are usually on the document. Even if I could, it would not be practical for them to answer my questions - because they'd be swamped with the questions of every other interested reader of the draft. I have never failed to get a response when I've written, and the times any one has called me, I have always replied. did somehow manage convey the rationale to all people writing to them, and I wouldn't agree with the rationale for some specific decision, I could not go to "another" discussion list - because there typically isn't one, or if there is it is as full of complaints about the W3C process as this one is. try the W3c html list. And yes, this mailing list _is_ about "my beefs with every (XML related) W3C spec", between other XML related things, unless someone creates a more appropriate list for the purpose. If you are aware of one, I'd appreciate the address. The more this thread continues, the more I'm getting convinced there's something wrong with the W3C. Obviously there is a reason why proper process documentation is not being provided. The problem is that the simplest reason is "to hide any shady politics between member companies". I think you've been reading too many conspiracy novels!:>) The w3c works by consensus!, The documentation that is not publically available is for the most part not worth reading! Many of the internal mailing lists make this list look like the embodiment of decorum and lucidity! Another reason is "because it would harm the quality of the resulting recommendation" - obviously absurd, or maybe "it would slow things down too much" It's very difficult to get 16 people to agree, yet alone a whole mailing list Frank Boumphrey (Speaking for myself) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990920/7f691926/attachment.htm From david-b at pacbell.net Mon Sep 20 03:02:42 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:16 2004 Subject: should FOP require JDK1.2.x? References: <011c01bf023d$c9c11c80$0300000a@cygnus.uwa.edu.au> <14309.31704.125439.459475@localhost.localdomain> Message-ID: <37E58835.A56E0810@pacbell.net> David Megginson wrote: > > schen@falconwing.com writes: > > > Not all platforms have stable 1.2 support yet, in fact the only two > > platforms that seem to be ok are Windows and Solaris, with Sun's > > JVM. > > JDK 1.2 behaves very well on Linux as well, at least as far as I've > pushed it over the past few months. Ditto. The only thing I'd really say against JDK 1.2 is that most of the non-licenced versions of Java (notably the GCC/GCJ one) are sticking to the JDK 1.1 APIs for now. Everyone's working on getting licensed versions of JDK 1.2 available on all the other platforms. Given that they're not all there yet, I tend to be cautious about hard-wiring in dependencies on JDK 1.2 APIs. However, 1.2 is my primary development platform (on Linux and NT). - 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 nmanson at livepage.com Mon Sep 20 03:20:52 1999 From: nmanson at livepage.com (Nick Manson) Date: Mon Jun 7 17:15:16 2004 Subject: A compromise? In-Reply-To: <002301bf0190$d00a0820$dceefea9@w21tp> Message-ID: <002d01bf0306$b9e87690$ea8f92d1@livepage.com> Don, > Here is a possible (and not necessarily the best) rendition of such a > mechanism: > > xml:schema="http://www.w3.org/TR/xhtml1/DTD/strict.dtd"> > xml:schema="-//W3C//DTD SVG July 1999//EN"> > > > > Comments? I like the mechanism and think it could be useful in other places. One comment: If this compromise was accepted by the W3C, I would prefer reserving 'xml:schema' for W3C xml schemas (whatever their final form) and using 'xml:doctype' for DTD files. This side-steps the issue of relying on magic file extensions and/or proper HTTP server behaviour. Perhaps the 'LocalPart' could be tied to mime type? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sep 20 05:07:49 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:15:16 2004 Subject: should FOP require JDK1.2.x? References: Message-ID: <008d01bf0315$66441e40$0300000a@cygnus.uwa.edu.au> Thank you to everyone so far who has contributed suggestions both on the list and directly to me. I hope people don't mind this discussion being on the list. I figure it is of some relevance to a number of XML developers (where *it* is the whole question of 1.2 vs 1.1, *not* the specific question of what Fop should do :-) > We could make a more concrete determination if James outlined the features > he's looking to use in 1.2. None in particular. I have a couple of ideas though: 1. The collections framework. Although I could use that with 1.1 as a couple of people have pointed out. My only concerns with that are: (a) for convenience for those that don't already have collections with 1.1 it would be better for me to include it with Fop (b) I might not be allowed to include it with Fop (I haven't checked the licence) (c) if I do bundle it, I would have to include a distribution of Fop without it for those people that already have it 2. Other libraries that require 1.2. For example, some of the stuff that I'd like to do might be nice to try out with MDSAX2 but that requires 1.2 3. Java 2D / Printing. I'd like Fop to be able to print and display on screen directly without PDF as well as with and Java 2D / Printing would be the obvious way to do this. The modular nature of Fop would enable me to perhaps distribute a separate 1.2 application to do this and leave the core as 1.1 Incidently, from 0.10.0 I've been compiling with a 1.2.2 compiler but only using 1.1 libraries. Does anyone know if this will still cause problems for people using 1.1. (ie should I go back to using a 1.1 compiler). Thanks James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net Ceci n'est pas une pipe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Sep 20 05:44:31 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:15:16 2004 Subject: W3C's 'Moral Majesty' References: <3.0.32.19990919115750.0120e420@pop.intergate.bc.ca> Message-ID: <37E5A8D4.36A0@hiwaay.net> Tim Bray wrote: > > Making the names that populate that markup universal, so that > vocabularies can freely be mixed, simply adds robustness to the system in > the face of the fact that the days of the Great Centralized Committee-Built > DTD In The Sky are over (good riddance). -Tim Putting the technical issues that in general, working toward a universe of freely mixable names is probably not achievable (too much domain noise and that noise is valuable because it is the engine of evolution), the issue at the bottom of the angst is the publication of technical rationale on a timely basis so that non W3C members can use the specifications without competitive penalties. The excellent aspect of this debate is that most of you appear to be looking for a solution so the community is functional. 1. Publish the rationale. 2. Use tools that make that easier. Enjoy. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Mon Sep 20 05:44:36 1999 From: cbullard at hiwaay.net (Len Bullard) Date: Mon Jun 7 17:15:16 2004 Subject: W3C's 'Moral Majesty' References: <049001bf0246$036d3c40$a60a1712@col.w3.org> Message-ID: <37E5AD44.1A97@hiwaay.net> It is a hard thing to be the moral authority standing between the king and the object of his desire. No sane man wants the job, and if by proclamation, he gets it, he would do well to find some means to let the king have his kate and edith too. The crux of the issue is that technical rationale for changes to the specification should be made public. Not the discussion itself, but the rationale. Talk to the ISO editors about how they handle it. If I were you, I'd have a long heart to heart with Charles Goldfarb as well. He has a rather good record for making it work and keeping his skin throughout. I have found him to be a deep and very resourceful man and he has an excellent stereo. If we are involved this deeply in a discussion of morality on a technical list, we cannot deny the depth of the concern of the community. We can recognize: 1. SGML made for years in face of disregard. XML has to survive a little too much regard. That's the job. It can't be avoided. 2. The W3C WGs can't do it all. The coalition of vendors large and small, multiple standards groups (IETF, ISO, MPEG etc) all have a stake and a say. 3. It is impossible for one man to be the focus of that much firepower for a long time. To paraphrase Byron, the sword wears out the scabard. Any long term solution to these problems require a long term view to the process of specifying and getting the contracts in place which get the system from phase to phase. If there is a need for a vision, it is not the technical vision, but the vision of how these contracts will be made and executed. It is dry work. It is a great achievement, one for which some are remembered long after the current issues are forgotten. If this discussion is to suggest a goal, Mr. Berners-Lee, perhaps it is time to stop, take some of the MacArthur money, go to whatever refuge, ashram, Mom's garden, wherever you contemplate best, and draw up that vision of how the W3C can work with the lists, the vendors, and the leaders of the other standards and specifications organizations to prepare for the time when the W3C and the web must evolve without need of a Director. This is not to say that you, personally, have not achieved something of worth, but that the best leaders eventually solve the problem of their own press. Then, you get to go fishing and let the prarie dog farm do its thing. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Mon Sep 20 05:59:08 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:15:16 2004 Subject: Another look at namespaces References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU><199909181437.KAA05856@hesketh.net> <199909191543.LAA26903@hesketh.net> Message-ID: <009c01bf031c$a8c65100$0300000a@cygnus.uwa.edu.au> > >> We seem to have fallen into linguistics. > > > >And the problem with that is what exactly? :-) > > In computing discussions, it usually signals that an enormous > communications breakdown either has occurred or is occurring. Alternately, > it could mean that we're on the edge of a massive breakthrough, but I don't > think that's true in this case. I think you meant something different by "linguistics" than what I was thinking. I realise now you probably meant "discussions about language" and not the actual field of study. > I think you're both (James and Paul) overstating the distinction between > natural languages and formal languages All I was trying to do was point out that there is a definition of "language", which is the one normally used by computer scientists, more accurately called a formal language, which requires a grammar. This is the sense of the word I think Paul meant. I think it is entirely acceptable for him to use the term in that sense. Most introductory CS books and I would guess almost all books on compilers and parsing would use the word "language" in that way. As an aside, I'm a linguist by training (with an emphasis on formal syntactic theories) and find it refeshing to be accused of *overstating* the distinction between natural and formal languages! :-) [...] > I think I have to suggest that there is a difference between HTML 4.0 (the > formally specified, designed-by-experts version) and HTML (the one that's > used in real life) - and do what we can to improve HTML, the real-life > version. If XHTML wants to design changes, they'd do well do consider what > the public will actually adopt, not try to force an odd notion of formal > grammars mapping to namespaces upon that public. "Odd notion of formal grammars"? What is odd about the EBNF in XML 1.0? What is odd about a DTD? What is odd about a DDML document? What is odd about an XML Schema Description? These are all called "grammars". They all define things called "languages". They are not "grammars" and "languages" the way Noah Webster used those words or the way you seem to use them. They are "grammars" and "languages" the way computer scientists use those words. Paul wasn't overstating any distinction between formal and natural languages, he was merely using the words "grammar" and "language" in their formal sense. Rick and you were using those terms in perhaps a different sense. No one is more right that the other, you were just using different senses of the words. [...] > I think you're making too strong a claim about XML vocabularies > as formal languages. Note: I never said XML *vocabularies* were formal languages. I said (1) XML itself is a formal language (do you disagree?) (2) DTDs define formal languages. They are grammars (do you disagree?) I don't equate the term "XML vocabulary" with "DTD". > >* XML is a language defined by a grammar. > > XML provides a foundation - much like letters give English and alphabet to > create words with. (Tim Bray: "XML is ASCII, etc.") I think you missed my point. All I was saying was that XML is an argument against your contention that languages aren't defined by grammars. XML *is* a language defined by a grammar. > >* The XML REC clearly says that a DTD is a grammar for a class of documents. > >In a formal language view, this class of documents is a set of > >utterances---a formal language. > > Except that in many cases there are multiple DTDs (for testing different > claims), or, in fact, no DTD at all. Without a DTD, are we truly > 'grammar-less'? I don't think so. Again, I think you missed my point. DTDs are grammars (do you disagree?) They define languages (do you disagree?) That was my point. DTDs are another example of grammars being used to define languages. > >> Whether or not _The SGML Cookbook_ makes this claim that a language is not > >> constrained to a single grammar, I'll be making that claim in my next > >book, > > > >Depending on what you mean by "not constrained to" and what type of > >languages you mean, I either completely agree or completely disagree with > >you :-) > > I guess you'll have to buy the book and find out! (Gross sales pitch, eh?) You know I plan to buy the book anyway, Simon! :-) If by language you mean a formal language in the sense meant by computer scientists and the L in XML, and by "not constrained to" you mean that it is not possible, given a language, to produce a single grammar that generates that language then I'm afraid you are wrong. I don't actually think you mean "language" in this sense otherwise this thread wouldn't have started. But Paul did, and there is nothing wrong with that sense. James -- James Tauber / jtauber@jtauber.com / www.jtauber.com Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net Ceci n'est pas une pipe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Sep 20 06:00:29 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:16 2004 Subject: should FOP require JDK1.2.x? References: <008d01bf0315$66441e40$0300000a@cygnus.uwa.edu.au> Message-ID: <37E5B1DD.96DDE9B4@pacbell.net> James Tauber wrote: > > 3. Java 2D / Printing. I'd like Fop to be able to print and display on > screen directly without PDF as well as with and Java 2D / Printing would be > the obvious way to do this. The modular nature of Fop would enable me to > perhaps distribute a separate 1.2 application to do this and leave the core > as 1.1 I certainly like the idea of direct Java2D output! > Incidently, from 0.10.0 I've been compiling with a 1.2.2 compiler but only > using 1.1 libraries. Does anyone know if this will still cause problems for > people using 1.1. (ie should I go back to using a 1.1 compiler). I'd encourage using the 1.2 compiler; there were some code generation bugs with the 1.1 compiler that cause problems in various cases you really don't want to have to debug. - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david-b at pacbell.net Mon Sep 20 06:18:34 1999 From: david-b at pacbell.net (David Brownell) Date: Mon Jun 7 17:15:16 2004 Subject: A compromise? References: <002301bf0190$d00a0820$dceefea9@w21tp> Message-ID: <37E5B61B.C504A617@pacbell.net> Don Park wrote: > > >I'm also curious why the HTML WG should care, since (X)HTML has > >only DTDs (currently three of them) for which there's already > >a standard association technique: > > But the current XML to DTD association mechanism has following problems: > > 1. Only one DTD per document > 2. Can not specify at element granuarity > 3. Can not replace DTD inline I know what you're getting at, but addressing all of those is for the future, right? An XHTML specification for today should just use today's standards (excluding schemas) and try to avoid creating waves (which is a problem with using three namespaces). There's a whole range of design spaces to play with. My point was more along the line of "schemas aren't here yet, let's not try to design them into a standard that's supposed to ship in the next month or so". That said, I concur that those points you raise need addressing in the Grand and Glorious Future World of Schemas. But I can't see how that would fit into the notion of a near-term compromise on how to fix the XHTML bugs ... - 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 murata.makoto at fujixerox.co.jp Mon Sep 20 07:35:00 1999 From: murata.makoto at fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:15:16 2004 Subject: Another look at namespaces Message-ID: <199909200538.AA02029@archlute.fujixerox.co.jp> Simon St.Laurent" writes: > At 08:30 AM 9/16/99 -0700, Andrew Layman wrote: > >[Someone] wrote that, although a schema may be somehow associated with a > >namespace, the "meaning" of markup will be determined in a number of ways > >such as style sheets, or procedural code, or maybe the schema. I believe > >this understates the importance of the schema. A schema makes a > >contribution to the Infoset. [snip] > > With all due respect to Andrew Layman, I find this to be a gross > overvaluation of schemas, and a substantial contrast with both the XML 1.0 > approach (which doesn't require validation) and with Tim Berners-Lee's > comments, which included: I believe that schemata should *not* contribute to the document information at all. An XML document without schemata or DTDs is a perfectly good citizen in the chaotic WWW. Very often, we simply cannot make valid documents, either because schemata or DTDs are too restrictive (or old) or they do not exist at all. Most of the upcoming XML documents (as opposed to XML data) on the WWW will be sometimes valid and sometimes invalid. Just like the semistructured database, application programs should never rely on schemata. If they do, they would discriminate invalid documents, which are a lot more common in the WWW. Let' use schemata only for sanity-checking. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata.makoto@fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Sep 20 07:52:18 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:16 2004 Subject: Another look at namespaces In-Reply-To: <009c01bf031c$a8c65100$0300000a@cygnus.uwa.edu.au> References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU> <199909181437.KAA05856@hesketh.net> <199909191543.LAA26903@hesketh.net> Message-ID: <199909200555.BAA18874@hesketh.net> At 11:59 AM 9/20/99 +0800, James Tauber wrote: >> I think you're both (James and Paul) overstating the distinction between >> natural languages and formal languages > >All I was trying to do was point out that there is a definition of >"language", which is the one normally used by computer scientists, more >accurately called a formal language, which requires a grammar. This is the >sense of the word I think Paul meant. I think it is entirely acceptable for >him to use the term in that sense. Most introductory CS books and I would >guess almost all books on compilers and parsing would use the word >"language" in that way. So we're having problems connecting the signifier 'language' to a meaning common across the participants of this list. >> I think I have to suggest that there is a difference between HTML 4.0 (the >> formally specified, designed-by-experts version) and HTML (the one that's >> used in real life) - and do what we can to improve HTML, the real-life >> version. If XHTML wants to design changes, they'd do well do consider >what >> the public will actually adopt, not try to force an odd notion of formal >> grammars mapping to namespaces upon that public. > >"Odd notion of formal grammars"? What is odd about the EBNF in XML 1.0? What >is odd about a DTD? What is odd about a DDML document? What is odd about an >XML Schema Description? The odd notion is of "formal grammars mapping to namespaces", not of "formal grammars", which range from useful to utterly useless. Some of them are indeed odd, but it's not 'formal grammar' I'm questioning here. >These are all called "grammars". They all define things called "languages". >They are not "grammars" and "languages" the way Noah Webster used those >words or the way you seem to use them. They are "grammars" and "languages" >the way computer scientists use those words. Meaning one grammar + vocabulary -> language? Where the quantities are all one? I think in practice you may find multiple grammars used within the same language, even a formal one, and (yuck for some) not just subsets (once you let ANY in the door, it all goes). Trying to keep it all exclusively singular seems to be a common dream throughout computing, but one I hope we can leave behind more and more over time. >Paul wasn't overstating any distinction between formal and natural >languages, he was merely using the words "grammar" and "language" in their >formal sense. Rick and you were using those terms in perhaps a different >sense. No one is more right that the other, you were just using different >senses of the words. Well, perhaps Paul should have left Chomsky out of it... I think we might do well to ponder whether XML is really about creating formal languages or for encoding information already represented in natural languages. If it's the latter, the results might be more interesting. Simon St.Laurent XML: A Primer (2nd Ed - September) Building XML Applications Inside XML DTDs: Scientific and Technical 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 donpark at docuverse.com Mon Sep 20 08:57:51 1999 From: donpark at docuverse.com (Don Park) Date: Mon Jun 7 17:15:17 2004 Subject: A compromise? In-Reply-To: <37E5B61B.C504A617@pacbell.net> Message-ID: <000401bf0336$0ee6fe80$8c1ecca1@w21tp> Nick Manson wrote: >If this compromise was accepted by the W3C, I would prefer reserving >'xml:schema' for W3C xml schemas (whatever their final form) and using >'xml:doctype' for DTD files. This side-steps the issue of relying on >magic file extensions and/or proper HTTP server behaviour. Perhaps >the 'LocalPart' could be tied to mime type? That should work too but the transport layer could provide the mime/type easily enough to differentiate between XML schema and DTD. I also think 'xml:schema' should not be limited to 'the' XML Schema but all others out there. David Brownell wrote: >I know what you're getting at, but addressing all of those is >for the future, right? An XHTML specification for today should >just use today's standards (excluding schemas) and try to avoid >creating waves (which is a problem with using three namespaces). Right. I made the proposal because I believe the ability to embed XHTML fragments within arbituary XML documents without losing the ability to validate is the key point of contention for XHTML WG. If the 'validatable embedded XHTLM fragment' problem is solved with one namespace, we are that much closer to putting this episode behind us. >There's a whole range of design spaces to play with. My point >was more along the line of "schemas aren't here yet, let's not >try to design them into a standard that's supposed to ship in >the next month or so". Right again. My proposal outlines just one point of the design space. An interesting point my proposal makes is that it is a general solution and XHTML can use it later when and if it is adopted without having to worry about it now. I think the whole thing started when XHTML group started looking too far into the future. Sometimes it works, sometimes it doesn't especially if your view is obstructed by unfinished work such as XML Schema. >That said, I concur that those points you raise need addressing >in the Grand and Glorious Future World of Schemas. But I can't >see how that would fit into the notion of a near-term compromise >on how to fix the XHTML bugs ... Once you read the official rationale from XHTML WG, you will understand. As always, I am jumping the gun. Best, Don Park - mailto:donpark@docuverse.com Docuverse - http://www.docuverse.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gdm at step-dpsl.co.uk Mon Sep 20 10:37:32 1999 From: gdm at step-dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:15:17 2004 Subject: Groves, IsNess and the Generic Data Object. [was.. Another try on Groves] In-Reply-To: <37E560B1.8B0B7E12@redrice.com> Message-ID: <000201bf0343$eba1b9c0$6d01a8c0@gdm.step-dpsl.co.uk> I have a ramble that I constructed the other day and some additional comments about other postings. Comments: --------------------- ************************* --------------------------------- I saw the following from Sean >>I believe it makes perfect sense to *think* of MPEGS, PDFs, >> whatever, in XML terms. This is NOT what groves are about. Groves are about thinking about the 'IsNess' of things. XML is one thing you could get as a serialisation of a grove model. Consider.. root node | ----- named prop 1 - type node | ----- named prop 2 - type basic | | ----- named prop 3 - type basic | | ----- named prop 4 - type node | ----- named prop 5- type basic | | ----- named prop 6 - type basic Above is the abstract data model for a thing. It could be any thing. There is NO XML I have just captured the 'IsNess' the first class properties of the thing. I have not thought about XML I have thought about the properties of the thing. Now, if I decided that I need a serialisation of my grove then I need to choose a mechanism for that. Section A1.4.5 of HyTime 2nd Edition provides us with the canonical representation for doing such a thing. Obviously the canonical representation is defined in terms of an SGML DTD and thus I could create XML and SGML instances for my grove model. Equally though I could serialise the model as an S-Expression. I think the point is that the grove paradigm should not get people to think in terms of XML but in terms of better appreciation of the properties of the notations they are dealing with. I agree that the concept that groves can be seen as a way to add tags to untaggable data as very powerful. But the more general case is that the grove paradigm gives names and first classness to otherwise unaddressable properties. --------------------- ************************* --------------------------------- Domain: how about www.grove-paradigm.com In essense there is more to the grove paradigm than just the model, e.g. the notation processor that constructs the model, the property set defintion, the grove plan, application conformance, suggested API's. --------------------- ************************* --------------------------------- Ramble: I think paul should be applauded for making groves more accesible in his last few mails. I wanted with this mail to re-iterate some of what Paul said and add what I feel is the essence of the grove paradigm. In addition I wanted to present the Generic Data Object concept and its role in the grove paradigm. I also wanted to give some concrete explanation and focus as to the power of the grove paradigm. It is the concrete focus that I want to start with, The most striking difference between XML and a Grove Model is that in the domain of 'cars' an Grove will let you access the value of the 'door' property, the grove for the XML representation of the car will let you access an 'attribute' of an element that is a serialisation of the object 'door'. As Paul said, Groves remove a level of redundant indirection. Why did I give the above example? I feel that this is such a **fundamental** concept that it is worth exemplifying as much as possible. Secondly I need it to lead on to the essence of of the grove paradigm and the power it brings. Object Oriented development is now established, we identify our entities, they have properties and we implement them using our favourite OO langauge. Now it happens that most peoples favourite OO lanaguge is not a dynamic beast such as Scheme, Python or CLOS but a strongly typed langauage such as Java or C++, there is nothing wrong with this. We construct these classes for specific roles - see UML and the fact that classes are assigned roles within a system. We value this as it gives us robust design, better error handling etc etc. Now, what if we still had some of the rigour of the typed system but one that could be dynamic and applicable to a variety of applications. Very nice but how does this apply to the grove paradigm. 1) When you build a grove model it adheres to a property set this is in effect equivalent to a set of UML class definitions. So this gives us our rigour. 2) When you build a grove model it is typically constructed in memory as an object model. This model is constructed by a 'Notation Processor'. A Notation processor is aware of the property set and is also aware of a Notation or number of Notations. A Notation is a ***'thing'***. This thing could be a Network, a Car, a Document, An application, a person, any given data notation. Thus given a networks property set and given a network instance a Notation processor can construct a Grove Model that allows access to all the properties of the network as first class objects. Before we come onto first classness and isness how can we build these heterogenous object models. As was pointed out in a previous mail heterogeneous collections play a big role in computing. The grove paradigm perceives that Objects are just containers with a generic collection of key, value pairs. The grove paradigm works at a fundamental level of computing, values associated with names. This is achieved by having the Generic Data Object. The GDO has closure in that it always returns a value which could be another GDO, it is dynamic as new values can always be added. These properties ensure that no matter what the notation is a notation processor can create a grove model that can contain the named property values of that notation. The Power of Groves.... The value of OO is in having something, an entity, that is malable, touchable, something that can be manipulated. Many systems are not empowered as they do not have their assets, their properties as first class objects. The grove paradigm provides the ability to make everything first class. e.g. the thread on the bolt on the door of a car becomes a node - a malable object - within the grove paradigm. Now, in the world of groves we only ever have nodes and properties thus if we have 1000 notations that have notation processors for them then we have a abstract data model for *all* these notations. We can interchange these nodes at the abstract level, we can link bewteen nodes at an abstract level without needing to know about the details of the underlying notation. I can link from my thread on the bolt on the car to the procedure of screwing on the nut in a technical manual. Note - that the thread on the bolt IS the thread on the bolt not a *document* about the thread on the bolt. Why the confusion with Groves and XML It appears that the dynamism and extensibility of XML and Groves provides a good match. The thing to remember is that the Property set for every XML document is the same. I never have the property 'colour' on a grove node for an XML document I only ever have 'attribute', 'name', 'value', 'gi' e.g. given this XML doc I can only say if I have a grove of the XML doc print node.attribute.name colur print node.attribute.value red Now, if I have a grove that represents the object car I can say print node.colour red The general grove model provide *IsNess* you talk about the thing as it IS, you talk about something in terms of the properties that help form its instance identity [identity obviously exists beyond the properties and their value]. The IsNess of an XML document is about attributes, elements and their values. The IsNess of a car is parts, colour, engine power etc. Summary The grove model enables a level abstract playing field in which to bring all notations - things. This is possible through the use of Generic Data Objects and their inherent dynamism and closure property. The grove paradigm helps us understand the essence of a notation so that we may manipulate *any* aspect of it. Kind Regards, Graham. *------------------------------------------ * Graham Moore * Consultant STEP-DPSL * gdm@step-dpsl.co.uk *------------------------------------------ ________________________________________________________________________________ This message has been checked for all known viruses by the Star Screening System http://academy.star.co.uk/public/virustats.htm xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Mon Sep 20 10:46:08 1999 From: jtauber at jtauber.com (James Tauber) Date: Mon Jun 7 17:15:17 2004 Subject: Another look at namespaces References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU><199909181437.KAA05856@hesketh.net><199909191543.LAA26903@hesketh.net> <199909200555.BAA18874@hesketh.net> Message-ID: <001d01bf0344$a8740b20$0300000a@cygnus.uwa.edu.au> > So we're having problems connecting the signifier 'language' to a meaning > common across the participants of this list. Indeed :-) > The odd notion is of "formal grammars mapping to namespaces", not of > "formal grammars", which range from useful to utterly useless. Some of > them are indeed odd, but it's not 'formal grammar' I'm questioning here. Oh good. > >These are all called "grammars". They all define things called "languages". > >They are not "grammars" and "languages" the way Noah Webster used those > >words or the way you seem to use them. They are "grammars" and "languages" > >the way computer scientists use those words. > > Meaning one grammar + vocabulary -> language? Where the quantities are all > one? You don't actually need the "vocabulary". The alphabet of a formal language is part of the grammar. > I think in practice you may find multiple grammars used within the > same language, even a formal one Ahh. But now you are using "language" in a way other than "the set of utterances generated by the grammar" right? Unless you mean that sometimes the same syntactic rules can be expressed two different ways eg a+ versus a a* > and (yuck for some) not just subsets (once you let ANY in the door, it all goes). Trying to keep it all > exclusively singular seems to be a common dream throughout computing, but > one I hope we can leave behind more and more over time. Let me stress again, I am not saying you can always have a single grammar for a particular "language". I am saying that you can have a single grammar for a particular "formal language in the sense used by Paul". > I think we might do well to ponder whether XML is really about creating > formal languages or for encoding information already represented in natural > languages. If it's the latter, the results might be more interesting. Why can't it be both? Isn't that the whole point of write schemata (including DTDs)? Isn't it about formalising the encoding of this information. 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 mtbryan at sgml.u-net.com Mon Sep 20 10:50:05 1999 From: mtbryan at sgml.u-net.com (Martin Bryan) Date: Mon Jun 7 17:15:17 2004 Subject: an unfilled need Message-ID: <00fd01bf0345$73f62080$97c566c3@unet.com> Rick Jeliffe wrote > I note Ann Navarro's call for "An unfulfilled need" earlier this month, on a subject I also have been calling for for 2 years+: the need for a mechanism to bind information to names: "definitions, semantics, and other data that may be necessary to complete their operations." This looks to me like a case of two non-commercial voices being lost to more important voices. This view has also been expressed by The XML/EDI Group, and the recently formed CEN/ISSS Defining and Managing Semantics and Datatypes project team, but in this case they have been discussing them in terms of the semantics of electronic commerce. >I wonder if the reason can be found in Tim B-Ls recent post: > Rick Jelliffe: >>There is no W3C method to declare which schema should be >>used, akin to the stylesheet declaration. > Yes there is: resolution of the schema URI. >Tim is saying that using the namespace URI to specify a schema is the official W3C method. But there is nothing about this in any W3C spec; no working group has decided this or put it out in a public draft or spec. >On the contrary "It is not a goal that it [the namespace URI] be directly usable for retrieval of a schema (if any exists)" says XML NS. >That is a major architectural decision implied on top of namespaces; the only parties I see that can benefit from hardcoding schema URIs into namespace URIs are vendors, who could use this mechanism and only provide schemas in languages which they controlled or provided tools for: I don't think this is far-fetched-- Biztalk mandates XDR schemas only. One of the techniques the XML/EDI community have been propounding is the use of namespaced attributes to point to semantic specifications using the XLink mechanism or an application specific mechanism. Basically the namespace of the attribute points to the rules for interpreting the attribute value and the value of the attribute points to the definition of the semantics that are to be applied to the element. This way you do not need to rely on the namespacing of the element name - you simply indirect your element name into the name space of the semantics definer. Using this technique you can decouple the model language used for the message from any model associated with the semantics. This means that it does not matter how the semantics have been defined (XML-Data, RDF, text, etc) you can still use a DTD or a Schema to model your message. To me this gets over the problems that would arise if W3C tried to define formal mechanisms for the linking of namespace URIs to schemas, etc. Martin Bryan Warning: As I only have time to look at the weekly XML-DEV archive, and will be out of the country for the rest of this week, I may not reply in a timely function to any reactions to this message. ----------------------------------------------------------------- Martin Bryan, 29 Oldbury Orchard, Churchdown, Glos GL3 2PU, UK Phone/Fax: +44 1452 714029 E-mail: mtbryan@sgml.u-net.com For more information about The SGML Centre contact http://www.sgml.u-net.com For more information about the European Commission's Open Information Interchange (OII) initiative contact http://www.echo.lu/oii/en/oiistand.html For more information about the ISIS XML/EDI Project contact http://wwe.tieke.fi/isis-xmedil.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 ricko at allette.com.au Mon Sep 20 12:05:07 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:17 2004 Subject: Another look at namespaces Message-ID: <009f01bf0350$92a66a70$41f96d8c@NT.JELLIFFE.COM.AU> From: Paul Prescod >Rick Jelliffe wrote: >> >> Again, Andrew is simply conflating schema and namespace. The idea that >> he and Tim are putting forward is that a language is defined by a single >> set of content models; this confuses "language" with "grammar" > >What definition of language are you using that does NOT state that every >language has one and only one grammar. The distinction between language and grammar is one of common English usage (refer to any dictionary) and does not need justification. To fixate on that subsiduary phrase is to ignore my point. My meaning would have been clearer if I said: >> The idea that he and Tim are putting forward is that a (markup) >> language is (completely or primarily or fundamentally) defined >> (as distinct from partially described) by a single set of content >> models; this confuses "language" (as common used) with >> "grammar" (as commonly used). My evidence for this was that they said that because HTML 4 has three DTDs, it should have three namespaces. Only the superficial aspects of a markup language (i.e., its syntax) can be defined with a content model. Its semantics cannot. I could have the same content models as HTML but with completely different semantics; they are not the same language (as commonly used), even though they may have the same grammar (as commonly used). (This distinction, that the Document Type Definition is not the same as the markup declarations, is as old as SGML. I have never heard anyone claim that markup languages are pure syntax with no semantics (where "semantics" is used not in the sense of in opppsition to "structure" or "denotation" but in the sense of in opposition to "syntax".) (Actually, Tim BL has clarified that he can go along with the idea that content models "describe" rather than "define" a language.) Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon Sep 20 12:08:43 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:17 2004 Subject: an unfilled need Message-ID: <00a201bf0351$035268f0$41f96d8c@NT.JELLIFFE.COM.AU> From: Martin Bryan >... Using this technique you can >decouple the model language used for the message from any model associated >with the semantics. This means that it does not matter how the semantics >have been defined (XML-Data, RDF, text, etc) you can still use a DTD or a >Schema to model your message. To me this gets over the problems that would >arise if W3C tried to define formal mechanisms for the linking of namespace >URIs to schemas, etc. To find the schema applicable for a namespace, we should not have a function: fetch-resource(namespace-URI) Instead, there it should go through some service: get-resource(namespace-URI, namespace-resolver-service-URI, preferred-syntax, resource-type) where resource-type could be "syntactic-schema", "semantic-schema", "documentation", etc. 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 digitome at iol.ie Mon Sep 20 12:13:31 1999 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:15:17 2004 Subject: Groves, IsNess and the Generic Data Object. [was.. Another try on Groves] In-Reply-To: <000201bf0343$eba1b9c0$6d01a8c0@gdm.step-dpsl.co.uk> References: <37E560B1.8B0B7E12@redrice.com> Message-ID: <3.0.6.32.19990920110001.00977330@gpo.iol.ie> Graham, Thanks for this post. I think this is a useful discussion... [Graham Moore] >I saw the following from Sean > >>>I believe it makes perfect sense to *think* of MPEGS, PDFs, >>> whatever, in XML terms. > >This is NOT what groves are about. Groves are about thinking about the >'IsNess' of things. > >XML is one thing you could get as a serialisation of a grove model. > >Consider.. > >root node >| >----- named prop 1 - type node > | > ----- named prop 2 - type basic > | > | > ----- named prop 3 - type basic >| >| >----- named prop 4 - type node > | > ----- named prop 5- type basic > | > | > ----- named prop 6 - type basic > > >Above is the abstract data model for a thing. It could be any thing. There >is NO XML I have >just captured the 'IsNess' the first class properties of the thing. I have >not thought about XML I have thought about the properties of the thing. In the above you have done what any intelligent, carbon based life form known to man would have done -- you have structured a domain model into a *hierarchy* of objects. I look at your diagram and in my head I see nodes called "named prop 1" and "named prop 4". I see other nodes that are contained within these nodes called "named prop 2" and so on. That level of abstraction -- nodes -- is all I need to process this data -- given some simple API. XML provides such a simple API. I need to simply mentally map the nodes and arcs into XML terminology of elements and attributes. This done, I can write software apace using SAX, DOM or any other XML API. Lets pretend the above data is in a data format known as FOO and accessible in CORBA land via a FOO-API. You seem to be asserting that I need a "grove" for this because the property set mechanism of the grove paradigm allows me to work in terms of an object API rather than an XML API. In other words this: # Access instance variable "named prop 5" # of object "named prop 4" named prop 4.named prop 5 instead of this: (or its equivalent (ontological arguments aside)) ... I don't buy it. I personally do not find the prospect of programming the latter rather than the former in any way daunting or limiting. It is a trivial transformation to take a hierarchy of typed nodes and associated attributes and create an object hierarchy if I really want to be able to use "object.instance attribute" syntax. > >Now, if I decided that I need a serialisation of my grove then I need >to choose a mechanism for that. Section A1.4.5 of HyTime 2nd Edition >provides us with the >canonical representation for doing such a thing. > >Obviously the canonical representation is defined in terms of an SGML DTD >and thus I could >create XML and SGML instances for my grove model. Equally though I could >serialise the model as >an S-Expression. > Agreed. >I think the point is that the grove paradigm should not get people to think >in terms of XML >but in terms of better appreciation of the properties of the notations they >are dealing with. This is where I think you have misunderstood my position. As human beings we have a cognitive pre-disposition to thinking in terms of hierarchies. There are many, many ways to represent such hierarchies syntactically - C++ programs, SGML, S-Expressions, tortuously inter-linked relational database tables, CODASYL, STEP and of course XML. They are all basically syntactic sugar. The hierarchy exists independently of any syntactic form used to give it a digital rather than cognitive form. XML has a nice simple syntactic representation for hierarchies. It uses certainly terminology to do that - elements and attributes. This terminology leads naturally to an API for hierarchies that uses terms like: startElement attributeList and so on. This API is all you need to process arbitrary hierachies of data. It is *not* a pre-condition of programming to this API that the data must have been previously serialized in XML notation! Earlier in talking about "IsNess" you say: >There is NO XML This is exactly my point! XML is syntax for representing a hierarchy. This syntax leads naturally to an API that is couched in terms of elements/attributes. This API is the key. You do not *need* to serialize data to XML syntax in order to use this API. > >I agree that the concept that groves can be seen as a way to add tags to >untaggable data as >very powerful. But the more general case is that the grove paradigm gives >names and first >classness to otherwise unaddressable properties. > I see it as a trivial transformation to convert a hierarcy of elements and attributes into a collection of objects with associated instance variables. I believe this has been done on numerous occasions in the SGML world. I think it was Bob duCharme who wrote a paper about transforming SGML instances into object hierarcies using Smalltalk as the implementation language. Some time ago, I prototyped an algorithm to do it in Python but I never got around to implementing it because I never saw the benefit of it for my work. Having said that, I do not work with STEP or CAD system data where I guess such a model transformation would be more useful. [...] >It is the concrete focus that I want to start with, > >The most striking difference between XML and a Grove Model is that in the >domain of 'cars' an Grove will let you access the value of the 'door' >property, the grove for the XML representation of the car will let you >access an 'attribute' of an element that is a serialisation of the object >'door'. As Paul said, Groves remove a level of redundant indirection. But this transformation is trivial! I guess I am having difficult seeing why I need to employ the vast edifice of abstraction that is the "grove paradigm" in order to do this. Somewhere along the line someone seems to have had an "Aha!" moment which went like this "...ergo we need groves". It is the "..." bit that I do not see. regards, Developers Day co-Chair WWW9, April 2000, Amsterdam http://www.www9.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 philipnye at freenet.co.uk Mon Sep 20 13:13:03 1999 From: philipnye at freenet.co.uk (Philip Nye) Date: Mon Jun 7 17:15:17 2004 Subject: Another try on Groves References: <000201bf0343$eba1b9c0$6d01a8c0@gdm.step-dpsl.co.uk> Message-ID: <37E619C3.50DB364A@freenet.co.uk> Graham Moore wrote: > I can > link from my thread on the bolt on the car to the procedure of screwing on > the nut in a technical manual. Note - that the thread on the bolt IS the > thread on the bolt not a *document* about the thread on the bolt. This is where I get lost - my Unbrako catalogue does not make any mention of links when I buy a box of M5 screws. I've just got the box out and checked and try as I might I cannot get the screw to do anything remotely resembling following a link. I cannot even find such a link in a car stuffed full of microprocessors. Is this because General Motors and Unbrako haven't bought into the Grove paradigm? Or do you mean that the grove takes you from some internal (computer) model of the thread to a (computer) model of the procedure for screwing without an intermediate document format? What I have still failed to grasp about groves, is what is missing? Why aren't we all using them? By this I mean, what work needs to be done in the real world to start the ball rolling. Does some enabling code need to be written (parser, compiler, class definition or whatever)? Does a notation need to be developed and formalised? Does an ISO, ANSI, IEC, IETF, W3C or whatever task force need to be appointed to make it happen? Or do we all simply need to think groves while designing whatever we were going to design anyway? I have a real application now where I am puzzling over the best way to express links between objects which sit very well in a hierarchical tree. Some of these objects are XML documents, while some are properties of other devices. Where should I start applying groves to this problem if at all? Philip Nye Engineering Arts 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 Sep 20 13:12:45 1999 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:15:17 2004 Subject: Another look at namespaces Message-ID: <00c901bf0359$f186cfe0$41f96d8c@NT.JELLIFFE.COM.AU> From: James Tauber Simon St.Laurent wrote: >> Whether or not _The SGML Cookbook_ makes this claim that a >> language is not constrained to a single grammar, I'll be making >> that claim in my next book, > >Depending on what you mean by "not constrained to" and what type of >languages you mean, I either completely agree or completely disagree with >you :-) My book, "The XML & SGML Cookbook", which is the only book in print AFAIR on the subjects of markup schemas in general (Eve Maler's book is a methodology of creating DTDs and also contains much in this regard, Dave Megginson's book looks at specific DTDs and similarly has much thought on these issues). I am looking forward to Simon's book too, and I am sure that many new ideas will come out of the XML Schema development effort. If other authors have books on schemas in general (i.e., not the syntax) then I am sure that the XML-DEV readers will appreciate a notification of its existence. My book has nothing on the subject of formal language theory, though it certainly mentions that architectural forms allow parallel content models which work together to describe the syntax of a language. (I.e., we could say that a document satisfies a language if it is both valid against the direct DTD and valid when validated against the architecture.) This is a clear example of a language requiring more than one content model. I think Paul's original comment mentioning my book is because IMHO markup languages and DTDs are not currently about data modeling but instead are concerned with software engineering. So in my chapter on this I mention that Yourdan and Constantine's ideas of "cohesion and coupling" of software modules also applies well to DTDs, to guide when to make elements sub-elements or siblings. (People who need XML to be concerned with data-modeling will naturally be confised when to use an attribute or element, etc.) So in another post I took this cohesion/coupling idea one step further to say that schema languages should be modeling these cohesion/coupling relationships; superficial grammars such as content models hide these, no matter how much we valiantly use PEs to document them. The example I gave was the html:p element. IMHO defining and namespace-naming the html:p element in terms of its content model elevates the content model to an importance in describing the actual schema of HTML too much. An html:p element is a block element found in the body element of an HTML document whereever general block elements can be placed, and it can contain mixed content, with any of the inline elements that are found in mixed content underneath the body element. That is the deeper syntax for html:p, as far as I can see. Now you could model this using a grammar by introducing productions to name content models: html:p ::= ( $generic-text-elements )* $generic-text-elements ::= #PCDATA | html:em | html:a |... This reflects the deeper structure better. Also, it makes it clear that a change in generic-text-elements does not bubble up to require some change in our understanding of html:p. The html:p element type is highly cohesive to the html:body element and to general-inline-text element types. But the general-inline-text element types are not highly cohesive to paragraphs: they can also appear in many other elements. There is an asymmetry to the cohesion that reveals that there is an intermediate layer; a schema describes couplings not cohesion, but it is good software engineering practise to only couple highly cohesive modules. Otherwise you over or under-specify the structure. An appropriate schema language allows fine-enough grained coupling of highly cohesive modules (element types, here): for example, the use EBNF by RDF. To go back to my orignal statement that Paul was responding to: it disputed "the idea..that a language is defined by a single set of content models". Paul just wanted me to avoid repeating the cohesion/coupling line and try to explain my viewpoint w.r.t. formal languages (grammars) I think. To reiterate, content models (i.e., the specific technology in XML, regular expressions on the child axis where there is no first-class way to label parts of content models) desribe superficial syntax only. They can describe the superficial syntax, and define validation. But content models do not necessarily define a markup language: they may hide as much as they describe. Rick Jelliffe The XML & SGML Cookbook: Recipes for Structured Information Charles F. Goldfarb Series on Structured Information Management Prentice Hall, 650 pages + CD-ROM ISBN 0-13-614223-0 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From digitome at iol.ie Mon Sep 20 13:29:09 1999 From: digitome at iol.ie (Sean Mc Grath) Date: Mon Jun 7 17:15:17 2004 Subject: Groves, IsNess and the Generic Data Object. [was.. Another try on Groves] Message-ID: <3.0.6.32.19990920121630.00ac8d50@gpo.iol.ie> Graham, Thanks for this post. I think this is a useful discussion... [Graham Moore] >I saw the following from Sean > >>>I believe it makes perfect sense to *think* of MPEGS, PDFs, >>> whatever, in XML terms. > >This is NOT what groves are about. Groves are about thinking about the >'IsNess' of things. > >XML is one thing you could get as a serialisation of a grove model. > >Consider.. > >root node >| >----- named prop 1 - type node > | > ----- named prop 2 - type basic > | > | > ----- named prop 3 - type basic >| >| >----- named prop 4 - type node > | > ----- named prop 5- type basic > | > | > ----- named prop 6 - type basic > > >Above is the abstract data model for a thing. It could be any thing. There >is NO XML I have >just captured the 'IsNess' the first class properties of the thing. I have >not thought about XML I have thought about the properties of the thing. In the above you have done what any intelligent, carbon based life form known to man would have done -- you have structured a domain model into a *hierarchy* of objects. I look at your diagram and in my head I see nodes called "named prop 1" and "named prop 4". I see other nodes that are contained within these nodes called "named prop 2" and so on. That level of abstraction -- nodes -- is all I need to process this data -- given some simple API. XML provides such a simple API. I need to simply mentally map the nodes and arcs into XML terminology of elements and attributes. This done, I can write software apace using SAX, DOM or any other XML API. Lets pretend the above data is in a data format known as FOO and accessible in CORBA land via a FOO-API. You seem to be asserting that I need a "grove" for this because the property set mechanism of the grove paradigm allows me to work in terms of an object API rather than an XML API. In other words this: # Access instance variable "named prop 5" # of object "named prop 4" named prop 4.named prop 5 instead of this: (or its equivalent (ontological arguments aside)) ... I don't buy it. I personally do not find the prospect of programming the latter rather than the former in any way daunting or limiting. It is a trivial transformation to take a hierarchy of typed nodes and associated attributes and create an object hierarchy if I really want to be able to use "object.instance attribute" syntax. > >Now, if I decided that I need a serialisation of my grove then I need >to choose a mechanism for that. Section A1.4.5 of HyTime 2nd Edition >provides us with the >canonical representation for doing such a thing. > >Obviously the canonical representation is defined in terms of an SGML DTD >and thus I could >create XML and SGML instances for my grove model. Equally though I could >serialise the model as >an S-Expression. > Agreed. >I think the point is that the grove paradigm should not get people to think >in terms of XML >but in terms of better appreciation of the properties of the notations they >are dealing with. This is where I think you have misunderstood my position. As human beings we have a cognitive pre-disposition to thinking in terms of hierarchies. There are many, many ways to represent such hierarchies syntactically - C++ programs, SGML, S-Expressions, tortuously inter-linked relational database tables, CODASYL, STEP and of course XML. They are all basically syntactic sugar. The hierarchy exists independently of any syntactic form used to give it a digital rather than cognitive form. XML has a nice simple syntactic representation for hierarchies. It uses certainly terminology to do that - elements and attributes. This terminology leads naturally to an API for hierarchies that uses terms like: startElement attributeList and so on. This API is all you need to process arbitrary hierachies of data. It is *not* a pre-condition of programming to this API that the data must have been previously serialized in XML notation! Earlier in talking about "IsNess" you say: >There is NO XML This is exactly my point! XML is syntax for representing a hierarchy. This syntax leads naturally to an API that is couched in terms of elements/attributes. This API is the key. You do not *need* to serialize data to XML syntax in order to use this API. > >I agree that the concept that groves can be seen as a way to add tags to >untaggable data as >very powerful. But the more general case is that the grove paradigm gives >names and first >classness to otherwise unaddressable properties. > I see it as a trivial transformation to convert a hierarcy of elements and attributes into a collection of objects with associated instance variables. I believe this has been done on numerous occasions in the SGML world. I think it was Bob duCharme who wrote a paper about transforming SGML instances into object hierarcies using Smalltalk as the implementation language. Some time ago, I prototyped an algorithm to do it in Python but I never got around to implementing it because I never saw the benefit of it for my work. Having said that, I do not work with STEP or CAD system data where I guess such a model transformation would be more useful. [...] >It is the concrete focus that I want to start with, > >The most striking difference between XML and a Grove Model is that in the >domain of 'cars' an Grove will let you access the value of the 'door' >property, the grove for the XML representation of the car will let you >access an 'attribute' of an element that is a serialisation of the object >'door'. As Paul said, Groves remove a level of redundant indirection. But this transformation is trivial! I guess I am having difficult seeing why I need to employ the vast edifice of abstraction that is the "grove paradigm" in order to do this. Somewhere along the line someone seems to have had an "Aha!" moment which went like this "...ergo we need groves". It is the "..." bit that I do not see. regards, Developers Day co-Chair WWW9, April 2000, Amsterdam http://www.www9.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 Mark.Birbeck at iedigital.net Mon Sep 20 13:34:20 1999 From: Mark.Birbeck at iedigital.net (Mark Birbeck) Date: Mon Jun 7 17:15:18 2004 Subject: Groves, IsNess and the Generic Data Object. [was.. Another tr y on Groves] Message-ID: I feel a bit sorry for the grove guys, because as is usual in our nerd-world, we never have discussions that go: A: Hey, how about this? B. Wow, great idea but 'fraid it will have to wait. A: That's no problem. Nice talking to you. We always have: A: Hey, you must do this or your edifice will collapse. B: No, who needs it, it's only for geeks. A: You're only saying that because you are: (a) a member of the establishment (b) funded by Microsoft B: You're only saying that because you are: (a) a member of the establishment (b) funded by Microsoft A: Why doesn't anyone listen to me? B: Pardon? And so on. It seems pretty straightforward to me that if you can accept a paradigm that abstracts collections of data into nodes, then you can accept an abstraction that allows those nodes to be manipulated in a manner that is closer to the structure of the original data. In other words, if you can accept that the transformation of: Fred 25/12/0000 into: sName = doc.children.item(1).children.item(1) is useful - because you can begin to generalise solutions, hide the parsing, and so on - then why not accept that: sName = doc.author(1).name is even more useful? And what about?: iAge = doc.author(1).age() If you were writing a serious bullet-proof application you would probably put a layer over the DOM which allows you to manipulate 'author' objects in this way anyway. You'd create some Java or C++ classes that sit on top of the DOM, and have to invoke the right one depending on the element type of the node you were currently manipulating. As far as I can tell from a quick reading, all the grove fans are saying is that just as you give everyone a parser and node walker in the API, now let's give them access to the objects, 'as objects' and not as nodes. This extra layer of code would then become much simpler. Now, I don't think this should hold up the onward march of XML; there is no way that everyone is ready for this 'paradigm shift' anyway. But whether we are ready or not shouldn't prevent us from having a useful discussion. People are being a bit lazy by dismissing the approach with "I'm quite happy walking the DOM" and "It's not that difficult to use the XML API". It doesn't seem that radical (or scary) to me, to say that at some point in the future an approach like groves will be an extremely common way of manipulating data. But I also don't think I'll lose my shirt if I bet that for now though, the initial advances made by XML and nodes will be more than enough to keep us going. Best regards, Mark xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simonstl at simonstl.com Mon Sep 20 13:38:31 1999 From: simonstl at simonstl.com (Simon St.Laurent) Date: Mon Jun 7 17:15:18 2004 Subject: Another look at namespaces In-Reply-To: <001d01bf0344$a8740b20$0300000a@cygnus.uwa.edu.au> References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU> <199909181437.KAA05856@hesketh.net> <199909191543.LAA26903@hesketh.net> <199909200555.BAA18874@hesketh.net> Message-ID: <199909201140.HAA27411@hesketh.net> At 04:46 PM 9/20/99 +0800, James Tauber wrote: >> Meaning one grammar + vocabulary -> language? Where the quantities are all >> one? > >You don't actually need the "vocabulary". The alphabet of a formal language >is part of the grammar. In XML-based languages that rely on DTDs or schemas, yes. But in all formal languages? Seems that it wouldn't be hard to create a formal language that had classes of vocabulary (like noun, verb, adjective) and fit them into patterns (subject[noun]-verb[verb]-object[noun]) that were separate. Hopefully, it wouldn't look like English, but it does seem like a practical solution to a lot of problems. >> I think in practice you may find multiple grammars used within the >> same language, even a formal one > >Ahh. But now you are using "language" in a way other than "the set of >utterances generated by the grammar" right? Unless you mean that sometimes >the same syntactic rules can be expressed two different ways eg > >a+ > >versus > >a a* It's that, but it's also worse. Suppose you have a nice modular DTD that expresses most of the vocabulary a user will need to create documents of a certain type, but has ANY sections so that users can organize it any way they like. Users build sets of DTDs to see what exactly it is they're getting or producing, but all of the possibilities are actually open. Is the language described by the 'master' DTD, which doesn't get you very far? Or is the language described by the particular DTDs? Or do we measure interoperability? A 'master DTD' containing all possibilities will quickly grow obese. Then there's the simpler case of well-formed documents, for which we can _derive_ grammars, but can't make definitive statements above the level of XML 1.0 conformance. >> and (yuck for some) not just subsets (once you let ANY in the door, it all >goes). Trying to keep it all >> exclusively singular seems to be a common dream throughout computing, but >> one I hope we can leave behind more and more over time. > >Let me stress again, I am not saying you can always have a single grammar >for a particular "language". I am saying that you can have a single grammar >for a particular "formal language in the sense used by Paul". I think 'formal language' in