From peter at ursus.demon.co.uk Mon Jun 1 00:10:13 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:46 2004 Subject: What are schemata In-Reply-To: <3.0.32.19980531130051.00b92100@pop.intergate.bc.ca> Message-ID: <3.0.1.16.19980531230340.71ef4bc4@pop3.demon.co.uk> At 13:00 31/05/98 -0700, Tim Bray wrote: [...] >Hmm, this line of thought may be perpetuating what I see as one of >the shortcomings of DTDs, namely that the DTD has to describe the >whole document, i.e. a class of languages. What about partial >validation/constraints? I think it's important that child-of-DTD >support compond documents & partial validation. So in the terms above, >maybe these things define sets of elements and attributes, rather >than whole documents. -Tim Yes - I have always seen a DTD as a collection of element/attribute constraints. It only describes a document if the document structure happens to fit the root element. But very often the it will describe the individual elements (including their children) and not the whole document. Of course a parser will regard that as an error at present, but the element-based approach has still a great deal of value - especially in a namespace context. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Mon Jun 1 01:31:04 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:01:46 2004 Subject: What are schemata Message-ID: <002401bd8ceb$1d0c7200$2ee044c6@arcot-main> Tim, >Hmm, this line of thought may be perpetuating what I see as one of >the shortcomings of DTDs, namely that the DTD has to describe the >whole document, i.e. a class of languages. What about partial >validation/constraints? I think it's important that child-of-DTD >support compond documents & partial validation. So in the terms above, >maybe these things define sets of elements and attributes, rather >than whole documents. -Tim Also, in the realm of persistant data streams (i.e. TV), there is no way for DTD to be updated by inlining DTD. I can not add new elements or change containment rules once the stream has started without shutting down the broadcast and restarting again. I guess this sort of falls into the question of "is a document always finite?". A document that takes an entire day to process is practically infinite in my opinion. Don Park http://www.docuverse.com/personal/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Mon Jun 1 01:51:57 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:01:46 2004 Subject: What are schemata References: <3.0.32.19980531130051.00b92100@pop.intergate.bc.ca> Message-ID: <3571ECE9.55D2323B@allette.com.au> Tim Bray wrote: > Hmm, this line of thought may be perpetuating what I see as one of > the shortcomings of DTDs, namely that the DTD has to describe the > whole document, i.e. a class of languages. What about partial > validation/constraints? I think it's important that child-of-DTD > support compond documents & partial validation. So in the terms above, > maybe these things define sets of elements and attributes, rather > than whole documents. I would have thought that support for compound documents and partial validation would involve much more than the relatively simple current goals of Xschema. It seems that you would have to build in the ability to map the relationships and dependencies between documents to support compound documents and the ability to locate a particular occurrence of an element from an otherwise unvalidated soup for partial validation. As the exact contents of the documents or fragments may not be known until processing time, wouldn't this be better handled dynamically by an application than more statically by Xschema? Also, by describing the entire structure, aren't you describing the smallest (as well as the biggest) fragment. I would have thought this was the most flexible coverage - am I missing something? -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Mon Jun 1 02:12:50 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:46 2004 Subject: What are schemata Message-ID: Marcus Carr wrote: >I would have thought that support for compound documents >and partial validation would involve much more than the >relatively simple current goals of Xschema. Will XSchema, by itself, provide support for compound documents and partial validation? No. Will XSchema make such things easier? Yes. As long as we stay out of the morass of questions like 'what is a document?', we don't need to worry about root elements and other charming relics. I think that moving from a DTD-based system, where behavior has been prescribed for SGML parsers and is effectively unchangeable (the glories of the installed base), to a new system that will necessarily require a different mechanism for connecting to documents, will require a reconsideration of the questions regarding the connection of a schema to its documents. In short, XSchema itself won't answer the question - all it defines is elements and attributes, with no grave concern for which one is the root. The declaration connecting the schema to the document (or whatever mechanism makes that connection) has the opportunity to present partial schemas for partial documents, compound schemas for compound documents. That intelligence must reside in the application, and I hope it will be specified in a different standard. I don't see us defining any more than a very simple mechanism (if indeed we define a mechanism) in XSchema 1.0, however. All we've committed to doing is providing a schema with a transformation to a DTD. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From stevew at access.com.au Mon Jun 1 02:31:54 1998 From: stevew at access.com.au (Steve Withall) Date: Mon Jun 7 17:01:46 2004 Subject: att="sé1" Message-ID: <3.0.32.19980601103220.00f613c0@pop.access.com.au> Patrice, The DOM itself clearly does not support getting back the original value - but Attribute (in Java) is just an interface, so implementations of it can add extra features. DOM appears to be designed for relatively simple end user manipulation of a document, not the more complex tasks involved in, say, authoring. I have just modified an 'Attribute' class of my own to implement the DOM interface, and my class does more than the DOM interface (for example, it stores the whitespace in and around the attribute.) It seems to work quite well: you can use purely the DOM interface if you wish, and call the extra methods if you need to do more. Regards, Steve. At 18:38 30/5/98 +0200, Patrice Bonhomme wrote: > > > >An Attribute value, within the DOM interface, is a String. But i could have >this : > > >And i want to restore the original attribute value (sé1) when i save my >file. > >Is it possible for the Attribute class to extend either the ContainerNode >class or the NodeList class ? > >Anyone investigate this feature ? Need some help. > >Thanks, > >Pat. >-- > ============================================================== > bonhomme@loria.fr | Office : B.228 > http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 > -------------------------------------------------------------- > * Serveur Silfide : http://www.loria.fr/projets/Silfide > * Projet Aquarelle : http://aqua.inria.fr > ============================================================== > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > ________________________________________________________________________ Steve Withall Systems Architect Tel: 61 2 9957 1036 Access Systems Research Pty. Limited Fax: 61 2 9959 5111 Level 10, 20 Berry Street North Sydney NSW 2060 Email: stevew@access.com.au Australia http://www.access.com.au xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 1 03:23:47 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:01:46 2004 Subject: What are schemata References: Message-ID: <35720271.5762E0A5@allette.com.au> Simon St.Laurent wrote: > I think that moving from a DTD-based system, where behavior has been > prescribed for SGML parsers and is effectively unchangeable (the glories of > the installed base), to a new system that will necessarily require a different > mechanism for connecting to documents, will require a reconsideration of the > questions regarding the connection of a schema to its documents. I'm still having a bit of a hard time getting my head around what the new mechanism for connecting to documents might involve. Are suggesting the schema (or multiple schemata) would be invoked numerous times based on the existence of a particular element, for instance? That would certainly make sense for processing fragments in an otherwise only well formed document. > In short, XSchema itself won't answer the question - all it defines is > elements and attributes, with no grave concern for which one is the root. The > declaration connecting the schema to the document (or whatever mechanism makes > that connection) has the opportunity to present partial schemas for partial > documents, compound schemas for compound documents. That intelligence must > reside in the application, and I hope it will be specified in a different > standard. The ability to feed multiple documents with arbitrary root elements to a persistent process combined with the ability to pick an element out of an otherwise only well formed document is already available with OmniMark. I agree that it would open things up if you could move some of the intelligence out of the application and into the data/XSchema, but I'm still not clear how XSchema will accomplish this without becomming very complex. If the intention is to support such things as multiple "XSchemettes" for fragments as well as an overall XSchema that may be applied to the document as a whole, aren't we flying awfully close to SUBDOC? Would the generation of the XSchema sometimes be the result of validating the documents (for want of a better phrase) against the DTD and combining information that with some other logic? I hope this doesn't sound too disjointed; I'm just trying to understand when, where and how in the process the XSchema may be implemented. -- Regards Marcus Carr email: mrc@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 9262 4777 fax: +61 2 9262 4774 _______________________________________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon Jun 1 06:31:03 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:01:46 2004 Subject: What are schemata In-Reply-To: <3.0.32.19980531130051.00b92100@pop.intergate.bc.ca> Message-ID: <000301bd8d16$4f7b75d0$aebc38cb@NT.JELLIFFE.COM.AU> > From: Tim Bray > Hmm, this line of thought may be perpetuating what I see as one of > the shortcomings of DTDs, namely that the DTD has to describe the > whole document, i.e. a class of languages. What about partial > validation/constraints? I think it's important that child-of-DTD > support compond documents & partial validation. So in the terms above, > maybe these things define sets of elements and attributes, rather > than whole documents. -Tim I think Tim is making a very useful point here. I think provable interconvertability with XML markup declarations is vital, but the future of Web documents is going to include documents cut and pasted from multiple fragments: not just fragment linking but physical editing too. Some of these source fragments will have come from documents with XML markup declarations, some with XSchema presumably, and some with none. So I think, at least in the backs of our minds and preferably in the foreground, we should enable such partially-declared documents with XSchema. (This is actually not so contraversial: XML-data provides this, the HyTime "Architectural Form" mechanism supports it, and WebSGML supports it to some extent too. Elliot Kimber has posted in the past (words to the effect of) that he thinks markup languages should move toward the view that markup declarations in the prolog are really only the front part of an overlapping, interlaced web of architectures (schemas). This is definitely the way the XML on the Web is moving. HyTime already supports declarations using different notations. ) Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Mon Jun 1 07:51:30 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:47 2004 Subject: What are schemata In-Reply-To: <35720271.5762E0A5@allette.com.au> References: Message-ID: <3.0.1.16.19980601064553.0bc74436@pop3.demon.co.uk> At 11:22 01/06/98 +1000, Marcus Carr wrote: [...] >I hope this doesn't sound too disjointed; I'm just trying to understand when, >where and how in the process the XSchema may be implemented. I hope at this stage (XSchema 1.0) that we tackle only some very simple and (hopefully) non-controversial things. I am off the air for a day or two but have sent some suggestions to SimonStL. Although we have called the process 'XSchema' I think we shouldn't try to define the variety of ways in which it should be used. We have a similar position to those developing namespaces - at this stage adopt a very simple solution that will not prejudice the future. Essentially that must be an: element attribute contentSpec *documentation* approach and nothing more adventurous. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gfrer at luna.nl Mon Jun 1 09:17:15 1998 From: gfrer at luna.nl (Gerard Freriks) Date: Mon Jun 7 17:01:47 2004 Subject: What are schemata In-Reply-To: Message-ID: To give an example. As far as I can think we might end-up with a framework of Context's. Each Context is a sub-domain model with its own set of Concepts, Terms and rules. In any (medical) document each one data item will be surrounded by Tags relating to each of the 6 Context subdomains. Several parts of the sub-domains can be coded according to several codingsystems. Each with its own DTD. SO it can be that there is one FrameWork-DTD and several optional DTD's in each subdomain model. In general I can see a FramWork of 6 SubDomains (Context's) - Real World Place, things, people, etc - Document World author, owner, etc , etc - Narrative World the way we tell or write stories - Topic Model World In the case of medine : diagnosis, findings, complaints, etc - Legacy systems - Business world Protocols, worlkflow Greetings gerard Freriks ps: In the case of medcine I would call it : MeSpeak At 20:23 +0000 31-05-1998, Simon St.Laurent wrote: >Tim Bray wrote: >---------------------------- >Hmm, this line of thought may be perpetuating what I see as one of >the shortcomings of DTDs, namely that the DTD has to describe the >whole document, i.e. a class of languages. What about partial >validation/constraints? I think it's important that child-of-DTD >support compond documents & partial validation. So in the terms above, >maybe these things define sets of elements and attributes, rather >than whole documents. >----------------------------- > >I think focusing on elements and attributes is an excellent idea. I'd >like to >see XSchemas applicable to fragments as well as to documents. I've been >pondering this in connection to some object store ideas I had while writing >that Building the Filesystem into the File paper a few months ago. > >'Documents' in the traditional sense are still popular, but I don't know how >much longer we'll really be working with them. I think fragments, subsets, >and combinations are going to be much more popular in the reasonably near >future. > >Compound documents and partial validation are a fact of life, or will be once >XML, XLink, and XPointer receive more widespread usage. I think we can >prepare XSchemas to support these (partial validation is easier) without >turning somersaults and cartwheels simultaneously. > >Simon St.Laurent >Dynamic HTML: A Primer / XML: A Primer / Cookies > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) ProRec- Nederland Gerard Freriks,huisarts, MD C. Sterrenburgstr 54 3151JG Hoek van Holland the Netherlands Telephone: (+31) (0)174-384296/ Fax: -386249 Mobile : (+31) (0)6-54792800 ARS LONGA, VITA BREVIS xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Mon Jun 1 12:08:30 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:01:47 2004 Subject: Entities and namespaces in XSchemata In-Reply-To: Peter Murray-Rust's message of "Fri, 29 May 1998 23:14:07" References: <3.0.1.16.19980529231407.383f3e1e@pop3.demon.co.uk> Message-ID: Peter> Peter Murray-Rust => In article <3.0.1.16.19980529231407.383f3e1e@pop3.demon.co.uk>, => Peter wrote: Peter> I am not an XML/SGML theorist, but it seems to me that anything Peter> that PEs can do for DTDs can be mirrored by entities in Peter> XSchemata. This extends to content specs, and - this could be Peter> exciting - namespaces. Watch: Peter> Peter> Peter> ]> Peter> Peter> Peter> Peter> &cml;atoms Peter> Peter> Peter> &cml;bonds Peter> Peter> Peter> Wouldn't limit one's ability to constrain (e.g.) GIs to reasonable values. I envisioned , where the attribute "Name" was constrained to be a NMTOKEN, to mirror the constraint in ordinary XML DTD language. Am I mistaken in thinking that entities are not expanded in NMTOKEN values? OTOH, I'd be happy with asking a XSchema -> DTD transformer to add or change namespace prefixes as part of the translation process. [BTW, your use of implies either assumption of the WebTC or not constraining the values to a token group. I'd go for in the traditional idiom. Or maybe use minimum/maximum occurance specifiers.] -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 1 12:10:45 1998 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:01:47 2004 Subject: XSchema Question 3: Internal/External subsets Message-ID: <01bd8d45$25b9df00$020b0ac0@xerius.ini.cz> IMO: No. By allowing linking of element type definitions (cf. my previous post) this can be done more cleanly by extending the element type in a separate schema. This could work in a similar way to "drawing in" an element type description from another schema, by including the link on the ElementTypeDef: person This leads to the question of how the new content affects the old one. The most conservative approach would be to do exactly the same thing that SGML/XML does with the internal subset: replace the entire content model and/or attribute list, as appropriate. A better but more ambitious approach would be to enable some kind of extension of the existing definition (leading us back into our inheritance/subtyping discussion, but perhaps with more chance of a concrete outcome). Even if the general opinion is that these issues should be left for later, one the more fundamental aspects of XSchema have been ironed out, it might still be helpful to keep them in mind to ensure that more powerful mechanisms such as these fit into the model. BTW: Now that I think about it, there is absolutely no reason why the above definition could not be included in a document, if the schema anticipates this by adding an optional "xschema" child to certain elements. This is both more rigorous and more powerful than the internal subset (which is always allowed, but only once in a specific location). I suspect that we are only beginning to discover the power that a unified schema/document syntax offers... Matthew -----Original Message----- From: Simon St.Laurent To: Xml-Dev (E-mail) Date: Saturday, May 30, 1998 7:00 PM Subject: XSchema Question 3: Internal/External subsets >This was actually one of the questions I was planning for the end, but Peter's >recent examples have made me move it to the front. > >Should XSchema provide internal and external subsets, as do XML DTD's? > >Note: Please keep in mind that answering no at this stage does not imply that >internal subsets will be banished for all time. It simply means that XSchema >1.0 would not support internal subsets. (We could banish external subsets, >but I doubt that makes sense to anyone.) > >Simon St.Laurent >Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matthew at praxis.cz Mon Jun 1 12:10:44 1998 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:01:47 2004 Subject: What are schemata Message-ID: <01bd8d45$442e0b50$020b0ac0@xerius.ini.cz> Let me say first of all that (after wading through the gazillion messages posted during and after SGML/XML Europe) this is an incredibly exciting and valuable effort. It was fascinating to see the discussion evolve from an abstract debate into a concrete effort to actually produce something of (at very least exploratory) value. Hats off to everyone who helped initiate this! Anyway, in regard to partial validation: this seems very much bound up with the question of what to do about entities (in general) and parameter entities (in particular). Entities are one of the things I wish had never been included in XML (along with CDATA, notations, etc.). There have been a few excellent postings about why a single, unified linking mechanism is desirable. As I understand it, Simon envisioned this as one of the advantages of using XML syntax for the schema definition (this was implied but not explained in detail in his original paper). In any case, XLink/XPointer are more than adequate to do this in a structured way. If simple text substitution is needed then a separate orthogonal mechanism should be used, as Paul pointed out. So if we postulate that parameter entities will be replaced in XSchema by a more generic linking mechanism, the problem of partial validation seems to be simply and elegantly solvable. For example (modifying one of Peter's previous posts): person (I changed the outer element type name from "ElementType" to "ElementTypeDef". Do we want the GI to be the same for both the definition itself and for references to other element types within the content model?) Instead of using an entity reference, the link attributes point to the appropriate definition of the content type for the "person" element. This is way better than parameter entities because it uses a unified link syntax *and* is far more flexible. I can whip up a quick schema just by throwing together a few elements and pointing to their appropriate definitions using URIs of whatever flavor. Certainly better than copying and pasting parameter entities. Another interesting factor is that these links could just as easily be included in the document itself. So if I have a document which lacks a schema, but want to validate the "greetings" portion (for which I have a schema), I could link into the schema at that point: Dear John Doe ... ... In this case, only the "greetings" element and its content would be validated. This is really incredibly powerful considering its simplicity: the content in question actually gets validated against two separate schemas (actually just bags of element type definitions) in two different files. This does complicate the spec a bit, although the principle is actually very simple. The only real decision is whether it is kosher to use XLink/XPointer in a schema definition. To me it would seem a crying shame not to allow this, whatever the implications for the "layering" of the architecture. Of course, for this we need a linking engine, but at least the effort can be leveraged for both schemas and documents, demonstrating why a unified syntax makes sense in the first place. 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 1 13:06:14 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:01:47 2004 Subject: XSchema Question 1: RDF In-Reply-To: Message-ID: <000001bd8d4d$85f05400$8bbc38cb@NT.JELLIFFE.COM.AU> It looks like RDF is no-where near the stage where XSchema could do much to support it yet. There is still the big fat warning on its header. In particular, section 3. "Transporting RDF" mentions "embedding" (this seems to mean an element reference), "along-with" (external markup), service bureau" (external markup) and "wrapping" as the four ways of associating descriptions and resources. But the current spec only considers wrapping. I guess this is because these other parts of RDF rely on X-Link. (Embedding and external markup could be done using ISO Topic Navigation Maps.) Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Mon Jun 1 14:00:46 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:47 2004 Subject: What are schemata References: <01BD8C2D.6A7D3790.jarle.stabell@dokpro.uio.no> Message-ID: <35729719.9F92E074@technologist.com> Jarle Stabell wrote: > > So by 'schema', you mean basically what is also known as 'type'? Here are a few of my concerns with the word type: * I think that it implies a set of legal operations, (e.g. the boolean type has logical operations, the integer type has integral operations, etc.) But in generic markup, we want the set of operations to be open-ended. In type systems, operations are "open-ended" in the sense that you can build up complex ones (e.g. power) from basic ones (addition), but in generic markup, you work directly on the data. * Each XSchema document will probably contain many types -- one per element, perhaps some data types and attribute types also. * As with DTDs, you will probably be able to use any element type in an XSchema as the "top", so any particular XSchema will not itself define a particular document type, but one per possible "root element" -- again several conceptual types. * Your sentence above conflates levels. Even if we use the word type, the schema is not a type. The schema *defines* a type. But at some level, yes, schemas define types. They define subtypes of the type "XML document". Some subset of all XML documents conform to a particular schema. I just don't think that the word is intuitively applied here. The types *in* the schema (element type, attribute types, document types) will get confused with the type the schema defines (a subtype of XML document). Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things see no end: A loop with exit code done wrong A semaphore untested, and the change that comes along http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Mon Jun 1 14:00:52 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:47 2004 Subject: What are schemata References: <1.5.4.32.19980531101327.008c42f4@gpo.iol.ie> Message-ID: <35729724.CD347B17@technologist.com> Sean Mc grath wrote: > > To my mind, a schema is an assertion about the structure of a unit > of data. I disagree a little. The schema itself is not the assertion. The HTML DTD does not assert anything. Some other declaration *points to* (or in the DOCTYPE case, includes) the schema. That declaration is the assertion. > Parsing w.r.t. to a schema both tests the veracity of the > assertion and generates a "view" of the data as an abstract > data strcture. I agree 100% with the first statement. I'm not sure about the second. It is certainly *convenient* for a schema to in some way massage the input to generate a new "view" of the data, (e.g. DTD's can add extra defaulted attributes, and strip away ignorable whitespace). But should view-generation actually be the responsibility of the schema? I don't know. In the database world, a view is something explicit and distinct from a schema. The view has its own schema, in fact. Since for XSchema we are experimentally stripping the schema concept down to its minimal core, I think that we should remove the view-creating responsibility from schemata, at least temporarily. Practically speaking, that would mean that XSchema processors would not be responsible for annotating or changing the parse tree in any way. They would only be responsible for verifying conformance or not. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things see no end: A loop with exit code done wrong A semaphore untested, and the change that comes along http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Mon Jun 1 14:01:04 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:47 2004 Subject: Names and schemas Message-ID: <3572977C.39E55C2@technologist.com> Through discussions on XML=DEV, I believe that I have clarified my own thinking on names, namespaces and schemas quite a bit. The fog is lifting. I believe that through a careful agreement upon and application of definitions, we can get rid of most complaints about the namespaces proposal and remove all overlap between that proposal and things like architectural forms and XSchemas (under development). Of course my definitions are context=based. Semioticians might disagree with them, but I think that they are sufficient for those of us in the markup language design business. Definitions =========== Name: (for our purposes) A unicode string that refers to something. Example: FOO Real object: (f.o.p.) A resource the computer can process. Example: a Java class or XML entity. Conceptual object: (...) A resource the computer cannot process (yet). Example: the meaning of the English word "ship" Namespace: A function that maps names to real or conceptual objects. Examples: The domain name system. A file system. A particular directory in a file system. Declaration: An assertion that a real or conceptual object exists (in reality or as a concept!). Example: Element type declaration. Definition: An assertion of what an object *is*. Definitions make things real to the computer. Examples: Java class definition. External entity definition. Directory: (or dictionary, vocabulary) A document that declares objects and/or defines real objects. Examples: A DTD. /usr/dict Schema: A document that defines a set of data objects (and thus implicitly defines a truth value: "is object X in the set.") Note that schemata do not necessarily (and, in generic markup, will not usually) DEFINE objects...it defines a set. All it does for individual objects is report whether they are in the set or not. Alternately, you could say that it constrains them. Implications ============ When I teach or write about SGML DTDs, I always says: "The DTD declares what elements are allowed and what are the contraints on how they can be used." It is only today that I recognize that these are two different responsibilities. The first is the role of a *directory* and the second of a *schema*. There is nothing wrong with the same language performing both tasks. It can be very convenient. But we must be clear that they are two tasks. Note that these definitions have the potential to sweep away the confusion about "multiple definitions" and "multiple inheritance" in the namespaces proposal. It only makes sense to *declare* each name once. Once it has been declared it has been declared. The software knows it exists. It only makes sense to *define* each name once for the same reason. A name can be bound to only one object. But it makes perfect sense to have multiple schemas for a particular object. The same object could be constrained in a hundred different ways. It's content model could be check by a DTDs. RDF schemata could check that it fits into a reasonable logical meta-data framework. A linking schema could check that if it is a link, it is a "correct" one. etc. etc. This is why you can attach multiple SGML architectures to a document (they are achemas) but you can only attach one DTD (it is both a directory AND a schema). This is also why the namespaces proposal and architectures need have no overlap. The one is about combining directories. The other is about constraining the named objects. Here is an example of a directory (dictionary) that would not be a schema: Here is another: abc def ghi jkl Of course, a directory *could be* a schema. As I said before, combining them can be quite convenient. But a schema could also exist which did not constrain names at all! For instance, a Java class that mapped document instances to truth values would be a schema (albeit a hard to work with schema!). Note that declarations for objects will be the norm in XML applications. Definitions will be quite rare. Very few of the things that must be expressed in markup will be expressed in terms that the computer can understand. This is why XML does not have "element type definitions", but rather declarations. The definition, if it xists, is in the brain(s) of the author(s). An exception would be where an element is "defined by" a Java class or RDF schema. Implications for the namespaces draft ===================================== The namespaces proposal was always supposed to be about "naming things accurately" and not about competing with schema languages. Nevertheless, this separation of church and state is not complete. The namespace proposal *does* promote the idea that an object should have a single schema. It should not. Luckily, this is easily fixed. All we need to do is take all normative references to the word "schema" out of the spec. In some cases, they can be easily eliminated. For instance the SRCDEF could be eliminated entirely. The role of the namespaces proposal is simply not to point to schemas. If the SRCDEF is to be retained, then it should point to a *directory* (or dictionary) which is not necessarily a schema. (but I think that the FIRST URI should point to the directory) Here's another example of what must be changed: "We envision applications of Extensible Markup Language [XML] where a document contains markup defined in multiple schemas, which may have been authored independently. One motivation for this is that writing good schemas is hard, so it is beneficial to re-use parts from existing, well-designed schemas. Another is the advantage of allowing search engines or other tools to operate over a range of documents that vary in many respects but use common names for common element types." The two sentences should be reversed and modified slightly. Verifying that a document conforms to one or more schemas is simply a special case of "allowing tools to operate over a range of documents that vary in many respects but use common names." It need not (and probably *should not*) be priviledged in the namespaces proposal. It is this type of language that makes people think that namespaces are a competitor to, or replacement for, architectural forms and other schema languages. Similarly, Section 2.5 presumes that every element is constrained by a single schema. But we know that many will live in multiple schemas. Rather, it should refer to "directories" (or one of the synonyms). It makes sense for an element to be declared in, or defined in, a single directory. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things it is far better that only you should know: How much you're paid, the schedule pad, and what is just for show xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Mon Jun 1 14:15:23 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:47 2004 Subject: What are schemata References: <3.0.32.19980531130051.00b92100@pop.intergate.bc.ca> Message-ID: <35729BBA.209D602A@technologist.com> Tim Bray wrote: > > >> | So is a schema a function that maps a document to a truth value? > >> > >> I'd rather say that it is a definition of a set of documents, just as > >> a formal language is usually considered to be the set of sentences > >> that are well-formed in that language. > > Hmm, this line of thought may be perpetuating what I see as one of > the shortcomings of DTDs, namely that the DTD has to describe the > whole document, i.e. a class of languages. What about partial > validation/constraints? I think it's important that child-of-DTD > support compond documents & partial validation. So in the terms above, > maybe these things define sets of elements and attributes, rather > than whole documents. -Tim This is all true. But at the end of the day, a complete document either conforms to a schema or it doesn't, even if only half of its elements or attributes are verfied, and even if they are only verified piece-wise. So a schema definitely maps a document to a truth value. (You could also say that it defines a set of documents...the statements are equivalent) The question is: should it also map sub-document fragments to truth values? And what should the granularity of those fragments be? Must they be well-formed? Should it also define a set of "XML fragments"? I am completely comfortable with the simple notion of piece-wise verification (e.g. ignore what you don't understand). I am not yet comfortable with the more complex notion that a schema should be able to map an arbitrary XML fragment to a truth-value. We would have to define "XML fragment" so that it makes sense. We would also have to discuss the interaction between the application and the schema language that would give rise to this situation. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things it is far better that only you should know: How much you're paid, the schedule pad, and what is just for show xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Mon Jun 1 15:10:24 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:47 2004 Subject: Piece-wise verification Message-ID: <3572A818.A4548E23@technologist.com> Presume XSchema rules are similar to XSL rules, and are of the form: ... Patterns would be very simple in the first version. (e.g. just the element type name) Later versions could be aligned with XSL so that that code could be reused. Constraints would also be simple and get more and more advanced with subsequent versions. Here is a definition of piece-wise verification: An attribute is verifiable if it matches the pattern in some rule. If it does, the attribute verifies if its value conforms to the attribute value type in the rule. An element is verifiable if it matches the pattern in some rule. If it does, the element locally verifies if its verifiable attributes verify and its content matches its content model. Example (DTD syntax, for now): An element verifies if it locally verifies and each of its sub-elements either recursively verifies or is not verifiable. (note: by default, verification is recursive, but some sub-elements could be undeclared) An element completely verifies if it locally verifies and each of its attributes and sub-elements is verifiable and verifies. An XML document verifies if its root element verifies and completely verifies if its root element completely verifies. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things it is far better that only you should know: How much you're paid, the schedule pad, and what is just for show xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Mon Jun 1 15:11:54 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:48 2004 Subject: Entities and namespaces in XSchemata Message-ID: [Forwarded for Peter Murray-Rust] [Toby Speight] >Wouldn't limit one's ability to constrain (e.g.) GIs to reasonable >values. I envisioned , where the attribute >"Name" was constrained to be a NMTOKEN, to mirror the constraint in >ordinary XML DTD language. Am I mistaken in thinking that entities >are not expanded in NMTOKEN values? [PMR] I think this is exactly the sort of question that we shall be debating in 2-3 days. I hadn't thought of NMTOKEN - I can see the attraction of it. But it wouldn't allow the namespace tweaking. >OTOH, I'd be happy with asking a XSchema -> DTD transformer to add or >change namespace prefixes as part of the translation process. >[BTW, your use of implies either >assumption of the WebTC or not constraining the values to a token group. >I'd go for in the >traditional idiom. Or maybe use minimum/maximum occurance specifiers.] I have no preconceived ideas :-) This was just to concentrate our minds on the sort of level the discussion will be at. IOW we are deciding (a) whether we stick with the DTD limits ('', ?, *, +) or allow more. We MUST allow translation to/from DTD, so if we allow occurrence="42", it will get translated to '+' in DTDs. [Mathew Gertner] >So if we postulate that parameter entities will be replaced in XSchema by a >more generic linking mechanism, the problem of partial validation seems to >be simply and elegantly solvable. For example (modifying one of Peter's >previous posts): > > > >href="http://www.xschema.org/library/person.xsc#id(person)">personype> > > > > >(I changed the outer element type name from "ElementType" to >"ElementTypeDef". Do we want the GI to be the same for both the definition >itself and for references to other element types within the content model?) Again, a point for us to resolve >Instead of using an entity reference, the link attributes point to the >appropriate definition of the content type for the "person" element. This is >way better than parameter entities because it uses a unified link syntax >*and* is far more flexible. I can whip up a quick schema just by throwing >together a few elements and pointing to their appropriate definitions using >URIs of whatever flavor. Certainly better than copying and pasting parameter >entities. Yes. This simply requires us to make sure that the appropriate XLink attributes are added to certain ElementTypes in the XSchema. I would *strongly* suggest that we did not - at this stage - attempt to define what is at the other end of the link (any more than namespaces). In fact I wouldn't be surpried if we could borrow the namespace semantics for this :-) >Another interesting factor is that these links could just as easily be >included in the document itself. So if I have a document which lacks a >schema, but want to validate the "greetings" portion (for which I have a >schema), I could link into the schema at that point: [... good example snipped ...] >In this case, only the "greetings" element and its content would be >validated. This is really incredibly powerful considering its simplicity: >the content in question actually gets validated against two separate schemas >(actually just bags of element type definitions) in two different files. You are discovering, as we all are, that XLink is a very exciting and powerful tool. Note that the links don't have to be in the XSchema OR the document! [They can be extended OOL links.] So simply creating XSchemas as XML documents - without any semantics - allows anyone to add them later with XLink. [BTW I think we should just note the power of what is unleashed here and not try to work out all its possibilities.] I also expect that where we write XLink and where we write RDF may be a matter of style of syntax rather than fundamental differences. I gather from private conversations at Paris that it is expected that RDF will be (or at least can be) implemented with XLink. >This does complicate the spec a bit, although the principle is actually very >simple. The only real decision is whether it is kosher to use XLink/XPointer >in a schema definition. To me it would seem a crying shame not to allow >this, whatever the implications for the "layering" of the architecture. Of >course, for this we need a linking engine, but at least the effort can be >leveraged for both schemas and documents, demonstrating why a unified syntax >makes sense in the first place. I think we should allow for it, because it can always be added by other means, but not constrain its use. Exactly like namespaces. 'the XLink attributes is provided to locate/identify the semantic resource [if we like that phrase].' This allows for experiments just like namespaces allow(ed) experiments. P. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mcc at arbortext.com Mon Jun 1 15:50:25 1998 From: mcc at arbortext.com (Mike Champion) Date: Mon Jun 7 17:01:48 2004 Subject: att="sé1" In-Reply-To: <199805301639.SAA00581@chimay.loria.fr> Message-ID: <98Jun1.094514edt.26881@thicket.arbortext.com> At 12:38 PM 5/30/98 -0400, Patrice Bonhomme wrote: > > > >An Attribute value, within the DOM interface, is a String. But i could have >this : > > >And i want to restore the original attribute value (sé1) when i save my >file. > >Is it possible for the Attribute class to extend either the ContainerNode >class or the NodeList class ? This is admittedly not at all clear in the April 15 draft of the spec, but the children of an Attribute are the values (the String methods are conveniences for the HTML world, in which attribute values can't contain entity references). So, an attribute could have a single Text node as a value (in the simple case), or a sub-tree of text nodes and whatever entity references expand to. This is being re-worked and clarified for the next draft. 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Mon Jun 1 16:05:02 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:48 2004 Subject: Piece-wise verification Message-ID: [Forwarded for Peter Murray-Rust] [Paul Prescod] >Presume XSchema rules are similar to XSL rules, and are of the form: [... XSL-like rule/pattern clipped ...] >Patterns would be very simple in the first version. (e.g. just the element >type name) Later versions could be aligned with XSL so that that code >could be reused. Constraints would also be simple and get more and more >advanced with subsequent versions. I like this proposal. As Paul hints, we shouldn't attempt more than the equivalent of a DTD in V1.0, and I suspect we might end up making the rule optional (and thereby defaulting to the element). It strengthens the XSL-like language as being useful for more than stylesheets [i.e. schemas, and presumably transformations.] I suspect that it gives us a good deal of the power we shall need 'for free'. For example if we want an element to occur between 5 and 8 times the pattern could be: descendant(5,FOO) descendant(9,FOO) CDATA #IMPLIED #PCDATA I am a molecule! This tells us: - there is a beast called which we might encounter - it might have an attribute 'convention' of type CDATA - we can validate its content as PCDATA - it is linked to a (specific) Java class If we have a document starting like: This says that *any* element starting with CML: belongs to the above namespace - we all agree, I think. The namespace is defined by the ns field (we shall soon get an official site for CML :-) That says *who* owns the namespace - again I think we agree. [This is what the namespace proposal says]. Now we start getting adventurous. We are allowed to peek inside the file src="http://some.where/cml/schema.xml Clearly we need some semantic conventions to tell us what we have found, but we are going to have to have those anyway (even if they are archforms, perl, etc.) I have been very daring and suggested that there is a PI which tells us this is an XSchema file (we'll have to have something, I assume - it's a bit hairy to deduce it from the URI). So we agree that this is an xschema file we have found and that we can read it with an XML parser. I think we are still agreeing. Now we have to have some implied semantics, and this is what we are discussing here. Just as AFs make special use of fires whenever an element FOO is found in the document instance. Thus our application (could be SAX) trundles through the document, skipping until it finds: CC(=O)Oc1ccCcc1C(=O)) when it records a match. It might simply validate it (in which case a traditional DTD+parser will do - and it's valid) or it might use the semantics in MolNode.class. This would read the formula and tell us that we had a validation error (the 12th character should be 'c' not 'C' assuming the aspirin molecule was intended). Note that we don't have to add additional dataTyping here. ***We haven't *typed* it as a molecule***. We have simply said that we are using a particular algorithm to validate it. So nowhere have we made large leaps of credibility. I hope I have outlined the areas where we need to specify our semantics exactly. Of course if we do not wish to use a preformed algorithm (MOLNode) we have so set those rules out *in the Xschema*. I think this is where our main problem lies - it isn't easy to develop a flexible robust extensible language for this task within a week. That's why we should leave the actual language (dataTyping, constraints, etc) to V2.0 [AF Note. From what I've picked up about AFs, I suspect this is similar to a very simple use where the meta-DTD consists a single element. And I use a different syntax.] P. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Mon Jun 1 19:22:48 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:01:49 2004 Subject: Metadata (was XSD: Proposed Goals, Rev. 3) Message-ID: <035b01bd8d82$1650c960$1e09e391@mhklaptop.bra01.icl.co.uk> >>As I use the terms, "metadata" means descriptive information summarizing or >>supplementing a document... The term "metadata" has for a long time been used in completely different senses by different communities. In the document world, metadata often means information about instances that is not part of the "content" of the instance. In database theory, metadata is usually information about types. The term is generally wider than "schema": for example an entity-type life history might be part of the metadata but not part of the schema. In the data warehousing world, the term "metadata" is also widely used, and I suspect its meaning there is slighltly different again, though I am not an expert. To enable XML to achieve its potential to unify the worlds of documents and databases, I suggest we avoid using terms that these communities will interpret differently. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jackpark at thinkalong.com Mon Jun 1 19:33:54 1998 From: jackpark at thinkalong.com (Jack Park) Date: Mon Jun 7 17:01:49 2004 Subject: Adobe and XML Message-ID: As a long time Mac user, I stumbled across this URL today: http://macworld.zdnet.com/pages/july.98/News.4395html The page discusses Adobe's application to W3C to standardize their use of XML for graphics. Cheers Jack Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dgulbran at vervet.com Mon Jun 1 19:55:47 1998 From: dgulbran at vervet.com (David Gulbransen) Date: Mon Jun 7 17:01:49 2004 Subject: Press Release: Vervet Logic Releases XML Pro v.1.0 In-Reply-To: Message-ID: Vervet Logic Announces the Release of XML Pro v1.0 BLOOMINGTON (June 1) - Vervet Logic, a leading XML Tools development company, announced the release of their XML editor XML Pro, version 1.0. The editor allows users to create and edit documents using XML, a new Internet document standard recently ratified by the W3C. XML Pro is the first visual XML editor to released to the Internet community. XML Pro offers the features of an advanced XML Editor with an intuitive interface that allows XML experts and novices alike to create valid, well-formed XML documents. Priced at $149.95, XML Pro delivers a professional XML editing solution at a consumer price. "We are using Vervet's XML Pro editor because it is more cost-effective and higher quality than building our own tools, "said Peter Cousins, a Level 8 Systems consultant for Prudential, "They have found a sweet-spot of price/functionality that is perfect for us." XML Pro features: o An easy, intuitive graphic user interface o A unique document tree outline view to preserve document structure o XML validation support with Document Type Definition (DTD) integration o Element Wizard for easy element creation and management o Attribute Wizard for easy attribute creation and management o Support for entities, CDATA and XML Comments o XML code preview and printing support o XML Pro supports the XML 1.0 specification from the W3C. "We're pleased to see companies using Microsoft technologies for innovation in XML " said Adam Denning, Group Program Manager of the XML group at Microsoft. "Microsoft is working hard to help software developers usher in new XML technology, and Vervet Logic has created a solid, useful XML tool." By combining the features expected in a professional XML solution with the pricing expected from consumer products, XML Pro is a perfect tool for XML developers, content providers, and authors. XML Pro provides the quick, functional editing solution missing from many high-end packages, and fits well into any XML toolkit. XML Pro is available for purchase now from Vervet Logic at www.vervet.com. XML Pro is currently available for the introductory price of $99.95US, which will continue until July 1. Site licensing and volume purchase discounts are also available. Founded in 1997, Vervet Logic is a leader in XML Tools development, providing consulting for XML deployment in the enterprise. Vervet Logic is located in the mid-west, and is a privately held company. Windows, Microsoft, and MSXML are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries. For more information about XML Pro and Vervet Logic, please visit the Vervet Logic web site at: http://www.vervet.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Mon Jun 1 21:37:08 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:49 2004 Subject: Names and schemas References: <3.0.32.19980601093741.00b92100@pop.intergate.bc.ca> Message-ID: <35730342.A6CB485C@technologist.com> Tim Bray wrote: > > I don't really agree with Paul Prescod's argument that the current > namespace draft invades schema turf. It does state that presumably > namespaces will in general have associated schemas (surely no-one here > disagrees?), but it bends over backward to avoid relying on the existence, > availability, or format of these schemas. Namespaces will, in general, also have associated stylesheets. Maybe in 10 years, they will, in general, also have associated Java classes and Yahoo categories. I don't think that schemas should be separated out from all other types of processing specifications. I especially don't think that we should priviledge a view that says that every element should have a *single* schema, which is the issue that really annoys the architectural form people (and with good reason!). > At the moment, based on some > off-line experimentation, I do think that the namespace facility will > lend itself quite elegantly to the construction of partial composable > schemas, the need for which is not in doubt. -Tim The namespace facility will also lend itself to the construction ofpartial composable stylesheets, Java rendering specifications, and perhaps "Yahoo ontology descriptions" (I made that one up). Once again, the separation out of schemas just leads to confusion. Plus, the fundamental problem is in the very first line: "We envision applications of Extensible Markup Language [XML] where a document contains markup defined in multiple schemas" Schemas do not define markup. If they did, then the idea of an element type being constrained by multiple schemas at the same time would be impossible. But it is not. Schemas constrain markup. Schemas define classes of markup. Schemas do not define markup (or elements, or element types). Even SGML never claimed that DTDs defined element types. I consider this a fundamental error. SRCDEF is just the technical manifestation of the error. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things it is far better that only you should know: How much you're paid, the schedule pad, and what is just for show xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at ACADCOMP.SIL.ORG Mon Jun 1 23:14:06 1998 From: robin at ACADCOMP.SIL.ORG (Robin Cover) Date: Mon Jun 7 17:01:49 2004 Subject: Names and schemas Message-ID: <199806012121.QAA20900@ACADCOMP.SIL.ORG> When Paul Prescod says: > Schemas do not define markup. If they did, then the idea of an element > type being constrained by multiple schemas at the same time would be > impossible. But it is not. Schemas constrain markup. Schemas define > classes of markup. Schemas do not define markup (or elements, or element > types). Even SGML never claimed that DTDs defined element types. I > consider this a fundamental error. SRCDEF is just the technical > manifestation of the error. I'm made to feel more in doubt than ever about the level of abstraction that's envisioned for "schema" (and XSchema) in this discussion. It's not clear to me that the principal goal of a new schema language would be to define classes of markup, with (syntactic?) constraints, though certainly that could be one role. >From what realm(s) of discourse are these definitions being drawn? I have taken for granted that a "schema" is intended to offer something like a class definition for an object, or like a formal notation for an attribute definition, but at some level higher than necessarily commits to a particular markup model, and at a level which would ideally abstract over markup languages which proclaim disinterest in object semantics. If this is the case, I see no reason why a schema could not define one or more markup models: "I am a BLORT (object) and I know how to generate a view of myself that conforms to the SGML FARBLE-DTD, as well as a view corresponding to the the XML FARBLEX-DTD", etc. Also, if schemas are for defining object (element) and attribute models, and not particular sets of such definitions, then the notion of a document root should fade into the background, and provide room for namespace semantics that do not privilege the document itself as dictating a namespace scope. If the goal of XSchema is to support the expression of semantic constraints, with respect to which XML is said to have express disinterest, then I see some potential for interesting work here. Not to discount mechanisms recently designed in the corresponding WG4 effort, of course, which indirectly or directly support a whole range of notations not allowed under 8879:1986. When I say "semantic constraints," I'm talking about something like Tim Bray's "Strong Data Typing" (everyone has read it?) and not "processing semantics" such as might be defined in methods in particular programming languages. However: once a schema does address itself to primitive relational semantics and data-type semantics, and admits of virtual attributes that exploit a notion of "self" and simple inheritance, the lines blur. I don't think that's a reason to be afraid of the territory, but a reason for XSchema to embrace something more interesting and useful than simply the design of an instance syntax for XML (for which any number of proposals already designed might work suitably well -- see the logs from the past two years). That said (and perhaps too much), I welcome clarifications from Paul and others on what is meant by "schema" and what authorities (domains) are being used for the definition. and (especially) the extent to which it's agreed that a schema should (not) be constrained by the notions of particular markup models. -rcc ------------------------------------------------------------------------- Robin Cover Email: robin@acadcomp.sil.org 6634 Sarah Drive Dallas, TX 75236 USA >>> The SGML/XML Web Page <<< Tel: +1 (972) 296-1783 (h) http://www.sil.org/sgml/sgml.html Tel: +1 (972) 708-7346 (w) FAX: +1 (972) 708-7380 ========================================================================= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Mon Jun 1 23:46:55 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:01:49 2004 Subject: Why not RDF for XSchema References: Message-ID: <357327E6.616EF52D@finetuning.com> Ok here we go: crash course in RDF -- what i learned while participating in the RDF Schema WG (DISCLAIMER IN ADVANCE -- no secrets divulged here) But first, an introduction: Simon said :-) > I'm still conducting my own full-scale investigation of RDF. I'm very > concerned about several issues: > > 1) I don't want this discussion limited to the relatively small number of > people who have figured out RDF. First of all I need to say that I'm very much in favor of RDF and what it proposes to eventually accomplish. (and I know I'm gonna catch some flack for some of my opinions below - but I'm just trying to save the rest of you time -- no one has the time to bone up on RDF real quick -- not even over the weekend. I'm not trying to be critical as much as trying to explain my experience and understanding of it and/or be corrected and enlightened about whatever I may be confused about - (thanks in advance tim and andrew) So here we go: > > 2) I don't want XSchema to need to make drastic changes if RDF moves suddenly > - it isn't complete. (From what little I've heard, this doesn't sound likely.) > I number my points from here... 1) actually, it is highly likely...almost guaranteed IMHO (you're gonna see me saying that a lot in this mailing ...) Until the syntax solidifies -- and don't hold your breath for that to happen anytime soon -- and really I think it's a good thing to wait and let RDF evolve as we figure out what we need it for -- sure beats pumping something out in a timely fashion that ultimately is neither extensible or useful -- and organizing bookmarks -- I don't care if they are the smartest bookmarks you ever did see -- doesn't count in my book as an implementation of an extensible semantically-enabled data content model -- complete with meaning and understanding...an ideal, granted, but we must reach for the stars, yes?) And nothing against either WG -- others have made comments about how slow the RDF progress is moving, but I doubt if the people making these comments realize the huge task that the RDF syntax and schema groups have before them: they have been presented with the ambitious task of integrating numerous existing semantic content models into a single unified conceptual syntax for expressing semantics in a way that is ultimately language-and implementation-independent. Another confusing item, particularly when using RDF for writing schemas, is that the various existing KR communities use many of the SAME WORDS when they mean ENTIRELY different things, which is poetically ironic considering we are trying to define a model for conveying meaning in the first place. For starters, there are something like 8 or more meanings just for the word "schema". Then we've got "inheritance". And what about classes and types -- which word do we use even though we are just trying to pick one --so the people that had a solid understanding of the properties involved say "oh, type, class, what does it matter? We know what we are talking about." and for some people, that is certainly true. But life is just so much easier if you pick one so there is no ambiguity. Ambiguity will inevitably manifest -- all we can do is systematically eliminate it as soon as such ambiguity recognized, yes?(especially syntactic ambiguity, which can be immediately remedied :-) To go on to the next layer of semantic understanding without fully comprehending the meaning of the "scope" (right word?) of the concepts underneath -- it's like getting back to the foundation of a house or getting around to grounding your electricity after you're all moved in. (insert metaphor for lacking a corelevel structure here) Anyway, taking all of the above into consideration (even the stuff Tim is going to correct me about ;-) Using RDF for anything other than an example of an example of an RDF Schema of an XSchema would be downright irrational. I'm not going to emphasize the synctactical instability except to say that it is unstable - which like i said before - is a positive and correct path of action at this ever so formative stage of the semantic conceptual game. 2) In many ways, it is almost a backwards concept to consider using RDF to define XML Schemas. This is because RDF is unique, compared to other XML implementations because, for one thing, it is *not* an XML implementation per se, although it CAN be implemented in XML (and in my opinion, should be and will be if it is ever going to be useful). So to talk about defining an XML-based application something or other using RDF doesn't mean a whole lot, and because RDF itself is a conceptual model, without a specifically-defined syntax OR model at this point...(I realize that this flexibility was designed to be one of RDF's "features", but at this early stage of its core development it simply complicates just about every aspect of actually implementing it.) EBNF (sp) notation is what's used in the spec (syntax). UML has been attempted for use in the graphical representation of its data structures, but it got messy quickly... RDF Schemas were going to used XML-compliant syntax in the beginnings of the WG, but we soon fell into a trap attempting to "wing it" (translation: we made guha and andrew do all the work :-) One could say that XML itself is unstable considering the (admittedly few...but still...) parts of it that have still yet to be defined, or are defined in an experimental manner (such as namespaces). Nevertheless, it's the best we got: RDF syntax will be most useful when it is strictly defined in XML-complaint syntax -- especially if we wish for our RDF and XML implementations to complement each other without restricting the expressiveness or interoperability of the other -- on my own site or anyone elses. IMHO 3) ...and this is a personal beef of mine The current RDF WD spends almost more than half of its "ink" defining numerous ways for authors to abbreviate their RDF syntax. Not only are the various varieties of abbreviation equally confusing (especially to those that are trying to initially learn RDF for the first time) but there doesn't seem to be really anything to gain in doing so, especially if we are in agreement that, ultimately (in a perfectly structured, gui interfaced world :-) Authoring tools will be generating the RDF after the functionality is determined. So we're not going to save any time or effort using abbreviated syntax....and we're going to screw up the interoperability of the data used in our RDF applications if everybody is abbreviating all over the place and those abbreviations are not clearly specified and accessible somewhere where we can find it when it's time to let our data mingle -- thus annihilating ANY benefit to abbreviating our rdf syntax Not to mention the obvious counterproductive nature of abbreviating a syntax that IS NOT FINISHED BEING COMPLETELY DEFINED :-) I understand how, at first glance, RDF seems to be SCREAMING to be abbreviated due to its often redundant and seemingly unnessarily verbose syntax -- verbose syntax that, at first glance now (she said cautiously) RDF doesn't seem to be really doing anything with its verbose syntax. Its syntax insists on being immediately complex, without providing a solid structure from which we can extend -- and it doesn't always map very well (algorithmically is what i think i mean, so someone CAN go from an RDF schema to a DTD -- not that they would want to, but it should someone want to, doing so should be a syntactical exercise, and not a painful one... --a systematic one! Frankly, if my implementations aren't completely interoperable with the data of the rest of the free world, they are of no use to me -- another potentially casualty of using lazy or inconsistent abbreviations. 4) The existence of the above mentioned syntax ambiguity makes it hard to construct the structure of its conceptual model -- and since the nature of RDF's design is precisely to provide a means for constructing a conceptual data model from which meaning can be derived (if my understanding is correct) -- there quickly becomes a sort of chicken and egg thing -- but using only a wing and a yolk (a wing and a prayer :-) Especially to those (like myself perhaps) currently unskilled in the field of semantics and knowledge representation. (It's kinda like a rosetta stone -- a puzzle -- except that RDF has yet to ever exist completely in one piece -- so one can burn a lot of time looking for pieces that you may NEVER find and often you realize you don't even need to find what you were looking for...) 5)Datatypes are a rather "funky" (maybe "tricky" or even "complex" is better) right now RDF has its own set of RDF-centric primitive datatypes (why the set used for XML -- as defined in XML Data -- couldn't have simply been adopted outright, I'll never know) RDF Schema too, in theory, is scheduled to have ITS own RDF Schema-specific datatypes as well as a set of primitive datatypes, which are currently not provided, last I checked) This issue is another, seemingly fundamental "core" requirement that the powers-that-be writing the spec somehow felt we could get back to, later, while continuing to moving forward despite the structural ambiguity. I figure as long as there is a means for providing a mechanism to define whatever datatypes you want whatever kind using whatever structure to define them -- as long as they can be referenced and parsed from within an RDF application -- what does it matter? (And I still feel this way.) But others -- people that know more than me about structuring semantics and sets of conditional rules that will most likely be accessed via one or more inferencing engines -- whose expressive syntax and semantic, conceptual structure WILL most likely be language and application and implementation and maybe even domain-specific and potentially fussy and inflexible-- Veterans tell me that these things can sometimes be handled more effectively using a set of built-in complex sorta-relational/conceptual datatypes) I still say give me a way to define these externally and we're in business but really, when it comes to this stuff -- to say my experience with defining semantic conceptual complex datatype structures -- defined externally or otherwise -- quite the understatement -- bordering on an embellishment! But I do understand that creating "built-in" datatypes into an ambiguious conceptual model would seem to make the uses for that datatype equally ambiguious (ie equally useless) 6) Another issue is that RDF and RDF Schema, at this point in time, (unless things have changed recently) have unique namespace prefixes -- even when addressing identical conceptual properties that the two share. (i suspect that considering this a "flaw" is perhaps required in some way -- making this item merely a case of my schema naivity rearing its ugly head) But at one point I researched the alternatives and it seemed like separating the two would only add to the already remote possibility of interoperability with other applications and that the potential for ambiguous, redundant resources could also become an issue -- somewhere down the road. 7) Another Kavetch: RDF will sometimes use more than one colon in its namespaces -- and i have seen an inconsistency across the examples provided by both specs and inconsisties between the spec examples and within the specs themselves with regard to when and under what conditions might require its lack of compliance -- another peeve of mine due to my hopeless dependence on the accuracy of such specifications. 8)RDF Schemas, at this time, do not contain a means of referencing metadata registries other than manually using URIs/namespaces (uuid won't help much with universal access) It seems to me that this would be one of those features that would be very worth while to take the time to "build-in." And also a requirement for a authoring schemas that can be useful. > 3) I don't want readers of the XSchema spec to have to bounce between it, the > RDF spec, and the XML spec to figure out what's going on. Rigorous definitely > made it into the goals, but readable and clear remains an important target. 9) RE: The having to go back and forth between specs issue: Boy! You really hit the nail on the head with that one. In order to deal with RDF in any kind of cohesive fashion -- which I figured I'd better be doing if I were to be of any use to the schema effort I found myself immersed in the following topics/resources: *Dublin Core see digression... (VERY helpful -- perhaps they have always had the right idea in terms of starting simple and agreeing on some agreed upon meanings and going from there step by step...however painful -- at least they suceeded in clearly defining the semantic concepts, however limited/simplistic -- when something is expressed its meaning clearly understood, referencible, translatable, and, eventually....extensible *Warwick Meeting of something or other *A lot of great metadata theory from that big conference in 96 *AI background stuff *Content Algebra automata theory classics *RDF syntax *RDF schema *PICS Labels (according to the charter RDF Schemas must be able to express PICS labels -- what a pain that is (currently does not do so) *MCF (the origin of many of RDF's ambiguities, in my opinion -- although it had some very progressive ideas, in its day) *MCF Tutorial (immensely helpful) *Aristotle's categories (not kidding -- thanks andrew) *XML Data *XML 1.0 *Daniel Dardiller's neato transformation paper from last fall *Nicolaus Wirths stepwise refinement paper *Mime spec, URI spec, HTTP spec (IETF) **Semantic query ontology stuff (it is NOT a tangent dammit!) **Object-oriented programming books (not just java, but C++ and component-based OO stuff in general -- another example of one of the KR worlds requiring integration into RDF's conceptual model) **Database theory and structure came into play somewhere in here (another "community") **Distributed Computing Basics (mostly machine-level considerations -- but I can see some incredible semantic possibilities utilizing DC -- but not if I can't parse my bogusly-doubly-coloned resource identifier, or find my ambiguously-defined device identifier -- or my OS-specific uuid: or yadda yadda...got I hope this all makes sense....or my dynamically-generated style sheet and/or my desired datatype reference - or SMIL streaming media source, or my architectural form....etc. etc. there are ways to always name things in what I am starting to define as an ANDROGENOUS manner -- not homogenous, or even heterogenous, but androgenous -- initially bland but ultimately dependable...) **Pattern theory and stuff written by that architect guy whose name escapes me **Organic-based information systems -- (like SGML...) And by then I realized I had come full circle. And still didn't know what schema was :-) 10) There are accessibility issues with RDF if it is not expressed in XML (and maybe even then...) that I don't think either RDF WG has been able to begin to address. (see WAI Accessibility spec) 11) Let me try to say that another, perhaps more structured way :-) At this point, RDF is half-baked ok? And we're not even sure if we have all of our ingredients yet, and all these different KR communities already have their own cookbooks that work just fine for them that don't seem to translate into more general kinds of syntactical expressions without having to compromise on the semantic meaning that can be derived from such expressions. In a consistent syntax it would make sense that this would happen, but when it happens in RDF, it does not do so in anykind of a structured way. It's harder to find holes in a wall that's already opaque, yes? Ultimately, this is a good thing, because defining RDF at the molecular level will ultimately enable the creation of complex derived semantic structures that will allow us to convey bonified deep and rich and associative and contextual CONCEPTUAL MEANING at an (ideally gracefully-degradable...) machine-readible, "smart" seamless and automatic level. Which would make sense except the problems that you run into do not occur in a uniform way. Not good for a language designed to be language and application and implementation-independent with the goal of enabling the interoperability of data between domain-specific semantic content models. unified expressive which really has some complex and intense semantic models it has been asked to somehow integrate into a unified conceptual language capable of satisfying the needs of several KR communities (databased programmers, dublin core, AI, etc...) without being to verbose (a goal that I fear is often disregarded ;-) The long and short of it is that, when I was in the RDF Schema WG, and admittedly struggling with the conceptual model of a "schema" in general -- I thought it was my own fault for not understanding schema, but once I stopped trying to learn schema in RDF and wrote schema using, say, xml data, or even a DTD...which IS a type of schema...the concept of defining a data content model was not complex at all....which has led me to believe that (DISCLAIMER: IMHO...drumroll please...) There's something casually ambiguious, inconsistent, and unquestionably about RDF's structural model. Why do so few understand RDF? Because at this point in the game, one can only conceive of the KINDS of things we WILL be able to do with it -- not much can be done now until the syntax is finished and it's conceptual (syntactical-not semantic mind you) model is completely defined. How can we even begin to construct a semantic model without a consistent and complete framework for the syntax? We can't. At one point (i don't think i am divulging any top secret WG info here ;-) guha offered to translate any existing schemas into rdf for us because none of the other WG members could figure it out either -- and we're talking after months of trying. I think this is significant. How come almost nobody understood it? How come so many of you stated that you didn't understand it, when you are able to "grasp" so many other complex and abstract ideas. Even tried and true dublin-core and database and UML guys (as opposed to "dummies" like me :-) weren't "getting it" excepting maybe guha, andrew, and ora :-) why is that? Several reasons actually: 1) RDF (and particularly RDF Schemas -- where you use rdf to actually attempt to "do something" besides simplistically describe the contents of your documents for search engines (a la the META TAG or CDF -- and hey, RDF is supposed to provide a core level semantic architecture that sits right on top of our core XML layer -- enabling our domains different semantic "knowledge representation" models to interact and "learn" from each other, yes? As it sounds now, one RDF implementation has the potential to not interoperate properly with another -- even if both "live" in the same domain and were written using the same syntax. Simon St.Laurent wrote: > > How will XSchema use/relate to RDF? > > There are several options I can see: > > 1) XSchema could be designed, top-to-bottom, as an RDF application. This is a really BAD idea for the reasons enumerated above This > wouldn't necessarily rule out defining XSchema in its own terms with an > XSchema document or providing a DTD, but it would require that participants > have significant working knowledge of RDF. On the bright side, I suspect the > W3C would look more kindly on an RDF implementation, if we can make it work. > I know everyone is very protective of RDF...and they should be, since it is very much still gestating in the womb...(I too, look forward to watching it grow up....:-) > 2) XSchema could use RDF for the descriptive information contained in XSchema > documents, but use its own model for defining elements and attributes. > Using any part of RDF's ambiguity to define even part of XSchema isn't really an option...not a useful one anyway > 3) XSchema could ignore RDF altogether. This wouldn't rule out the use of RDF > to provide metadata information about documents, but would leave RDF out of > the structural information included in XSchema documents. > Gets my vote! RDF should be able to implement whatever we decide on for XSchema, in addition to its own RDF schema-specific functionality. > 4) XSchema could allow the use of RDF as one of many ways to extend the schema> information provided. > This is a given given 3, yes? We don't want to restrict any form of extension, do we? > > Making RDF useful for this project, if we choose to use it, is going to > require the creation of a much fuller set of tutorials in particular. The > current set (listed below) is notable for its density and its lack of concrete > examples. I'm willing to work on this project (I may even be able to get paid > for some of it) if we decide that RDF is important. I'd also like to hear > about other resources already in existence. > I've been working on an RDF Schema Tutorial that kinda got back burnered when I left the group (webMethods had to bring in the big guns (Joe Lapp ;-) and to be honest the time expenditure was starving me out -- plus I couldn't write about W3C-based issues with a clear conscience being a participating WG member (i'm a by the book gal :-) -- I may make an exception to do some accessibility work....but I'm digressing again.... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 2 00:03:11 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:49 2004 Subject: XSchema Question 1: RDF Message-ID: We need to get the RDF discussion moving again so we can move on to specific syntax. Dan Brickley suggested that I take a look at the W3C's P3P proposal for one example of how RDF/XML specifications can look like plain old XML without incurring much pain. (I also hope he'll feel free to kick me if I get this discussion wrong. Everyone else is welcome to join in as well.) The proposal is at http://www.w3.org/TR/WD-P3P10-syntax. Like nearly all of the W3C documents we're discussing here, this is a _Working Draft_, not a final spec, and is subject to change. In the introduction, the authors specify: >P3P uses RDF/XML for the exchange of structured data and assertions. The RDF/XML usage is a little strange, but later, in section 4.2, the relationship (to RDF and namespaces as well) is somewhat better defined: >The following RDF captures the information as expressed >above. P3P proposals MUST be statements that are properly >expressed according to the syntax model of RDF as well as >valid and well-formed XML. As a specific application of RDF we >make a number of assumptions about RDF: > > 1.the tag may be optionally omitted. > 2.a tag without a name space should be assumed > to be of the P3P namespace. P3P proposals are XML documents, and apart from the optional tag, it isn't clear that there's anything fundamentally different about them. Sections 4.2.1-4.2.4 define elements used in P3P, using ordinary XML element and attribute terminology and no further discussion of RDF. Appendix 3 provides non-normative DTDs for P3P XML, supplementing the ABNF used in the rest of the document. This suggests that at least RDF doesn't have to make the spec unreadable or unusual. It still doesn't answer the questions of whether RDF is * Stable * Understandable by enough people for this group to work with it * Well-suited to this kind of schema creation. Unfortunately, I'm not really qualified to answer those questions. What I'd like to do is have us go ahead with creating XSchemas in XML, with the RDF-literate guiding development when necessary to keep us from landing on the rocks. That still leaves open the question of whether there are enough RDF-literate people out there, and whether they have time for such an adventure. Comments? Suggestions? Volunteers? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Jun 2 00:42:28 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:01:49 2004 Subject: XSchema Question 1: RDF Message-ID: <3.0.32.19980601153945.00c7fa90@pop.intergate.bc.ca> At 10:02 PM 6/1/98 UT, Simon St.Laurent wrote: >We need to get the RDF discussion moving again so we can move on to specific >syntax. RDF is painfully simple, conceptually. And Lisa is correct in saying that the syntax is (IMHO unnecessarily) kinda ugly; I think there are good reasons to expect improvement. But it is easy to tell if something can easily be made into RDF. Here's the test: if what you are building can be expressed as a bunch of 3-tuples (object, propertyname, propertyvalue) then it's RDF-able. Otherwise it's not. E.g. (document, rootType, HTML) (elementType IMG, takesAttribute, SRC) (attribute SRC, valueType, URI) (attribute BORDER, defaultValue, "1") (entity copy, value, "©") (entity xml-spec, systemID, "http://www.w3.org/TR/REC-xml") are all easily RDF-able. I think the only thing in DTD's that are not trivially RDF-able are content models. They *are* RDF-able, but you have to use some of the "Seq" machinery, which I find awkward. In fact *every* attempt so far (the old DSD stuff, XML-Data, etc) to express content models in XML has come up verbose and unreadable compared to good ol' 8879 DTD notation. I think there's a better way, and want to see what xml-dev can come up with. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Tue Jun 2 01:16:52 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 1: RDF In-Reply-To: Message-ID: On Mon, 1 Jun 1998, Simon St.Laurent wrote: > We need to get the RDF discussion moving again so we can move on to specific > syntax. Dan Brickley suggested that I take a look at the W3C's P3P proposal > for one example of how RDF/XML specifications can look like plain old XML > without incurring much pain. (I also hope he'll feel free to kick me if I get > this discussion wrong. Everyone else is welcome to join in as well.) > > The proposal is at http://www.w3.org/TR/WD-P3P10-syntax. Like nearly all of > the W3C documents we're discussing here, this is a _Working Draft_, not a > final spec, and is subject to change. A related angle on this is that it would be possible for XSchema instances to be legitimate RDF-in-XML documents (ie. with an agreed mapping from XML elements-and-attributes to RDF nodes-and-arcs) without committing to being a full RDF application. The 'syntax' bit of the RDF Model and Syntax paper defines _two_ syntaxes for representating RDF graphs in XML: the normal 'serialisation' syntax and an 'abbreviated' syntax. RDF-aware software needs to be ready to parse both syntaxes. Given the time scale, this aspect of RDF could be a little daunting for the XSchema project. However, this doesn't mean that XSchema couldn't be 'RDF-friendly'. It might be, for example, that an RDF model reprenting XSchema concepts gets mapped out, and a single XML representation using one of the RDF-in-XML syntaxes is defined. This scenario would differ from XSchema being a full RDF application as follows: 1) XSchema documents would look exactly like serialised RDF graphs using a syntax compliant with the RDF Model and Syntax spec 2) XSchema documents would be mappable into an RDF graph that represents DTD/XSchema concepts in terms of resource/propertytype/value tripes 3) Not all RDF serialisations of the graph described in (2) would count as legal XSchemas. [ this is the halfway house bit! ] In other words, we agree an RDF model representation, pick our favourite XML syntax for this and then say that XSchema-aware software is _not_ expected to be capable of understanding of the other equivalent representations defined by the RDF Model and Syntax spec. This would be a compromise similar to that sketched in the P3P draft. As Tim Bray points out, the RDF model is at core rather simple, even if the gory details of the spec takes a bit of grappling with. It shouldn't be unfeasibly hard to represent XSchema ideas in terms of assertions framed as RDF triples: "the ____ property of the resource known as ____ is _____"... I suspect this would be a useful exercise in itself, even if it was decided that XSchema syntax couldn't (for whatever reason) be RDF friendly. The only other potential stumbling block is namespace prefixing: RDF uses namespaces, so an RDF-friendly syntax would hopefully do likewise. So a concrete question to ask might be: do we agree that it's acceptable to spend those extra bytes namespace-prefixing the elements and attributes in an XSchema document? Dan -- Daniel.Brickley@bristol.ac.uk Research and Development Unit tel: +44(0)117 9288478 Institute for Learning and Research Technology http://www.ilrt.bris.ac.uk/ University of Bristol, Bristol BS8 1TN, UK. fax: +44(0)117 9288473 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 2 01:34:23 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 1: RDF Message-ID: Tim Bray wrote: >But it is easy to tell if something can easily be made into RDF. Here's >the test: if what you are building can be expressed as a bunch of 3-tuples > >(object, propertyname, propertyvalue) > >then it's RDF-able. Otherwise it's not. Great! If this is the case (and I think it is, except for content models, as you noted), I think we can move on to other issues. I'd like to see the RDF-aware on this list continue to make input whenever we stray into territory that seems impossible to reconcile with a transformation into RDF, but this 'RDF in a Nutshell' gives us a useful guideline for future development. Does it seem reasonable to proceed, keeping a lookout for RDF without chaining ourselves to its (apparently unstable) syntax? Let me (or the list) know. I think we're ready. Tim also wrote: >I think the only thing in DTD's that are not trivially RDF-able are >content models. They *are* RDF-able, but you have to use some of the >"Seq" machinery, which I find awkward. In fact *every* attempt so far >(the old DSD stuff, XML-Data, etc) to express content models in XML has >come up verbose and unreadable compared to good ol' 8879 DTD notation. >I think there's a better way, and want to see what xml-dev can come up >with. Sounds like a good challenge. Let's get to work! Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Jun 2 02:16:29 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 1: RDF Message-ID: <3.0.32.19980601171526.00b74ba0@pop.intergate.bc.ca> At 11:34 PM 6/1/98 UT, Simon St.Laurent wrote: >Does it seem reasonable to proceed, keeping a lookout for RDF without chaining >ourselves to its (apparently unstable) syntax? Well, assuming you don't invest too much time crafting details of syntax; it seems to me that the most valuable outcome of this discussion is what needs to be in next-gen schemas and how they are to be used. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Jun 2 08:14:49 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 1: RDF References: Message-ID: <357396F0.4010FBE9@technologist.com> Simon St.Laurent wrote: > > P3P proposals are XML documents, and apart from the optional tag, it > isn't clear that there's anything fundamentally different about them. I don't understand how those conform to the RDF specification. Where are the RDF:Description elements? I'm not asking Simon in particular, but rather anyone knowledgable. http://www.w3.org/TR/WD-P3P10-syntax Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things never anger: First, the one who runs your deck The one who does the backup, and the one who signs your check http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 2 14:34:10 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:50 2004 Subject: Proposed draft of XSchema document available Message-ID: [Forwarded for Peter Murray-Rust] [John Cowan] >I have posted a proposed draft XSchema document at >http://www.ccil.org/~cowan/XSchema-draft-19980601.txt . >I worked this out independently of the list, then read >the archives. Many thanks, It appears to date from about 2 months ago? :-) It looks very similar to (part of) the sort of deliverable we might expect from XSC V1.0. There is a clear statement of many of the details which acts as a very useful starting point. >I am posting this, not in order to preempt the work of the >ad hoc XSchema group, but in order to provide a concrete >substrate for discussion. The draft is by no means complete; >it does not satisfy goal 8 (mechanisms for XSchema application), >nor does it say anything about namespaces. It is a very useful place to start from. This is the first public posting of a DTD to represent conventional DTDs w.r.t. XML spec, though I suspect that others have done very similar things. It's well set ou - but quite long - and I won't comment on everything. A few points. John normalises out PEs (as I think we have all implicitly agreed), but maintains support for other entities (and NOTATIONs). This raises the question: - should XSchemas support all aspects of *document* minimisation (e.g. general entities)? If not, they can only be used with normalised XML docs (because otherwise &foo; is uninterpretable.) My personal feeling is that we have to support for this purpose. - should XSchemas support NOTATION? I am not the right person to answer this :-) - John states that he sees XSchemas being used to support the valiadtion of valid XML docs, but implies (I may have got this wrong) that they can't be used with WF docs. I think XSchemas can and will be used with WF docs - for adding semantics, authoring support, etc. I think a number of use also see them being used for local validation. >Comments would be greatly appreciated. I suggest that SimonStL might take parts of this and hack them into whatever strawman he is going to come up. Large chunks would probably carry over unchanged. P. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Jun 2 14:46:14 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 1: RDF Message-ID: <199806021216.OAA00698@berlin.dvs1.tu-darmstadt.de> Tim Bray wrote: > In fact *every* attempt so far > (the old DSD stuff, XML-Data, etc) to express content models in XML has > come up verbose and unreadable compared to good ol' 8879 DTD notation. > I think there's a better way, and want to see what xml-dev can come up > with. -Tim Regardless of whether XSchema rivals DTD notation for brevity and clarity, we still need it. The compelling reason for XSchema is not besting the readability of DTD notation -- a visual schema editor is far clearer than both -- but making schema information available through XML tools (which are numerous) rather than DTD tools (which are not). For this reason, I would vote against directly using RDF in XSchema, as it means we will have designed something we can't use. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 2 14:48:40 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 2: Namespaces Message-ID: Dan Brickley just wrote, regarding RDF: ------------------------------- The only other potential stumbling block is namespace prefixing: RDF uses namespaces, so an RDF-friendly syntax would hopefully do likewise. So a concrete question to ask might be: do we agree that it's acceptable to spend those extra bytes namespace-prefixing the elements and attributes in an XSchema document? ------------------------------- Paul Prescod wrote earlier: ------------------------------- I feel that XSchema should have its own namespace, that its DTD should embed a namespace qualifier in element type names and that when and if it has an "import" mechanism other than general entities, that mechanism should support automatic namespace remapping (e.g. your foo:bar could be called baz:bar in my document). ------------------------------- I propose XSC for the namespace prefix, unless someone knows of a conflict or thinks three letters is too many. We also need a URI for the declaration. 'members.aol.com', the current site for the XSchema info, is probably not appropriate. I also have simonstl.com, and three ISBNs, but I don't think we should tie this to my identifiers. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Jun 2 14:57:09 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 3: Internal/External subsets Message-ID: <199806021136.NAA00602@berlin.dvs1.tu-darmstadt.de> Simon St. Laurent wrote: > At this point, I'd say no to internal XSchemas, if only because sorting out > those details will take a long time and considerable debate. It would also > require us to find some way of hiding the internal XSchemas from non-XSchema > aware processors, something I'm not fond of. I agree with Simon. I can't think of anything you can do with an internal XSchema that you can't do with an external XSchema, so including them in 1.0 just means having to wrangle over a bunch of rules for resolving duplicate XSchemas. With the recent partial validation discussions, this gets even uglier... -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Jun 2 14:58:33 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 2: Namespaces Message-ID: <3.0.32.19980602055701.00b838e0@pop.intergate.bc.ca> At 12:46 PM 6/2/98 UT, Simon St.Laurent wrote: >I propose XSC for the namespace prefix, unless someone knows of a conflict or >thinks three letters is too many. The prefix is *irrelevant*. Only the URI matters. Go read the draft. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ak117 at freenet.carleton.ca Tue Jun 2 15:11:21 1998 From: ak117 at freenet.carleton.ca (David Megginson) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: References: Message-ID: <199806021309.JAA00530@unready.megginson.com> Simon St.Laurent writes: > I propose XSC for the namespace prefix, unless someone knows of a > conflict or thinks three letters is too many. It's not up to the XSchema designers to select the namespace prefix -- that choice belongs to the individual users. By all means, use "XSC" in your examples, but according to the current namespace draft, each user is free to pick "X", "XSchema", "Simon", or whatever she wants: it would be useful to provide a few examples with alternative prefixes, just to make this point clear. > We also need a URI for the declaration. 'members.aol.com', the > current site for the XSchema info, is probably not appropriate. I > also have simonstl.com, and three ISBNs, but I don't think we > should tie this to my identifiers. You don't need a domain name, just a URL. For example, if you were to submit the XSchema spec as a note to the W3C, you could use the URL of the note; alternatively, perhaps xml.com would provide you with a stable URL that you can 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 2 15:31:11 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 2: Namespaces Message-ID: SSL>I propose XSC for the namespace prefix, unless someone knows of a SSL>conflict or thinks three letters is too many. > TB>The prefix is *irrelevant*. Only the URI matters. Go read the draft. TB>-Tim Of course the prefix is technically irrelevant. (I have, indeed, read the draft, even the latest one.) It would be nice, however, to use something consistently in the XSchema specification, instead of confusing people with random prefixes. I'd like to see XSC used in the spec. I think you'll find in common usage that people will prefer to refer to namespaces through common references, and that prefixes _do_ matter, whether or not they do technically. The URI is handy, and necessary, to avoid conflicts, but is anyone really going to talk about "namespace urn:uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"? Not unless they're showing off their memory, in which case they might do better to memorize pi to X digits. David Megginson wrote: DM>it would be useful to provide a few examples with alternative DM>prefixes, just to make this point clear. This is a good idea, though I'd like to see it confined to the portion of the spec covering XSchema and namespaces. DM>You don't need a domain name, just a URL. For example, DM>if you were to submit the XSchema spec as a note to the DM>W3C, you could use the URL of the note; alternatively, DM>perhaps xml.com would provide you with a stable URL that DM>you can use. So, any contenders for the URI? members.aol.com/simonstl/xschema/ is quite a chunk and not likely to be stable, long term. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 2 16:10:36 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 2: Namespaces References: Message-ID: <35740786.65F0121F@locke.ccil.org> Simon St.Laurent wrote: > I propose XSC for the namespace prefix, unless someone knows of a conflict or > thinks three letters is too many. As I read the Namespaces WD, the prefix (if it is not "xml") can vary from one document to another, depending on the namespace PIs that appear in that document. So my "foo:bar" can be your "baz:bar" indeed, as long as I declare "foo" to have the same value of the "ns" pseudo-attribute that you use to declare "baz". Thus it is not necessary to standardize a prefix, although it certainly would be reasonable to recommend one. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Tue Jun 2 16:13:06 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 2: Namespaces References: Message-ID: <35740ECC.31484D2E@finetuning.com> Simon wrote: > members.aol.com/simonstl/xschema/ is > quite a > chunk and not likely to be stable, long term. it doesn't necessarily NEED to be stable, since any "specification" we come up with is for experimental use only as our way of assiting the XML working group for when they define the REAL spec yes? Let's not forget that - although I have been personally amazed at the unprecedented usefulness of this discussion group for its unprecedented assistance to the WG on numerous occasions (and myself personally :-) It is the XML WG -- NOT US -- that will ultimately define "XSchema's" syntax etc. (if that is indeed what hey decide it should be called). XML Schemas will be incorporated into the XML core itself, and must be done so using due process...(to pick its prefix, or what have you...) SPEAKING OF WHICH WG members (Tim I believe this is referring to one of your comments) I have a burning question -- You mentioned that we don't have to pick such a prefix -- then please clarify my inquiry regarding the unique prefixes for RDF and RDF Schema that -- if I understand correctly -- are very much required. Is it an "RDF thang?" thanks, lisa Simon St.Laurent wrote: > > SSL>I propose XSC for the namespace prefix, unless someone knows of a > SSL>conflict or thinks three letters is too many. > > > TB>The prefix is *irrelevant*. Only the URI matters. Go read the draft. > TB>-Tim > > Of course the prefix is technically irrelevant. (I have, indeed, read the > draft, even the latest one.) It would be nice, however, to use something > consistently in the XSchema specification, instead of confusing people with > random prefixes. I'd like to see XSC used in the spec. > > I think you'll find in common usage that people will prefer to refer to > namespaces through common references, and that prefixes _do_ matter, whether > or not they do technically. The URI is handy, and necessary, to avoid > conflicts, but is anyone really going to talk about "namespace > urn:uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"? Not unless they're showing off > their memory, in which case they might do better to memorize pi to X digits. > > David Megginson wrote: > DM>it would be useful to provide a few examples with alternative > DM>prefixes, just to make this point clear. > > This is a good idea, though I'd like to see it confined to the portion of the > spec covering XSchema and namespaces. > > DM>You don't need a domain name, just a URL. For example, > DM>if you were to submit the XSchema spec as a note to the > DM>W3C, you could use the URL of the note; alternatively, > DM>perhaps xml.com would provide you with a stable URL that > DM>you can use. > > So, any contenders for the URI? members.aol.com/simonstl/xschema/ is quite a > chunk and not likely to be stable, long term. > > Simon St.Laurent > Dynamic HTML: A Primer / XML: A Primer / Cookies > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 2 16:14:59 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 2: Namespaces References: Message-ID: <35740F61.BE6BB2C1@finetuning.com> Also; why would XML schemas have a different prefix than their XML documented counterparts -- XML Schemas will become part of the CORE specification, yes? thanks ahead of time for the thoughtful soul that is going to fill my soul from their well of infinite knowledge (man, this namespace stuff is getting me batty...) lisa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Tue Jun 2 16:41:18 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: <35740ECC.31484D2E@finetuning.com> Message-ID: On Tue, 2 Jun 1998, Lisa Rein wrote: > your comments) I have a burning question -- > > You mentioned that we don't have to pick such a prefix -- then please > clarify my inquiry regarding the unique prefixes for RDF and RDF Schema > that -- if I understand correctly -- are very much required. > > Is it an "RDF thang?" >From http://www.w3.org/TR/WD-rdf-syntax/#transporting [....] The syntax descriptions below use the Extended Backus-Naur Form notation as defined in section 6, Notation, of [XML] to describe the essential RDF syntax elements. The EBNF here is condensed for human readability; in particular, the italicized "rdf" is used to represent a variable namespace name rather than the more precise BNF notation "'<' NSname ':...'" and the requirement that the property and type names in end-tags exactly match the names in the corresponding start-tags is implied by the XML rules. [...] RDF serialization syntax takes the form: [1] RDF ::= '' expression* '' [end of excerpt] ('rdf' in the above is italicised in the original HTML.) At first glance this looks as if 'rdf' is hardcoded as the namespace prefix, but I think this is just an artifact of the convenience shorthand being adopted. The phrase "'rdf' is used to represent a variable namespace name" makes it pretty clear that other prefixes could be used instead. Dan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jun 2 16:44:43 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:01:50 2004 Subject: XSchema Question 1: RDF In-Reply-To: <3.0.32.19980601153945.00c7fa90@pop.intergate.bc.ca> Message-ID: <000201bd8dfa$7932ba70$8ebc38cb@NT.JELLIFFE.COM.AU> > From: Tim Bray > RDF is painfully simple, conceptually. And Lisa is correct in saying that > the syntax is (IMHO unnecessarily) kinda ugly; I think there are good > reasons to expect improvement. My impression of RDF is that it has a superficially appealing model, but that its current syntax is so bad it will cause just as many problems as it solves. I have been told that the syntax was designed the way it is because that is what the metadata community, whoever they are, demand: the experience of the markup community is regarded as of secondary interest, I guess because RDF is regarded as so novel that mankind has never embarked on anything like it. But I am being too bitchy. In particular, RDF has the big problem that it is a system of serialization, not of markup. The difference is this: in a markup language, the data comes first, and the trick is how to reveal the structures which are of interest: the organizing principle for the schema is the natural structure of the data. In a serialization language, the data exists pre-chunked and pre-labelled: so having a nice manipulatable schema system (e.g. relational tables) becomes the organizing principle of the schema. So, for example, the element groups things together: it has no real purpose, and implements the built-in assumption that data is grouped together. But anyone who has marked up text knows that interesting data is plonked all over the place: often duplicated and often partial or wrong. Hence in SGML the emphasis on external markup of relationships: HyTime, XML extended pointers, and so on. The RDF syntax is IMHO completely skewed to the problem of "how can we make something that will not upset HTML?": it is starting off crippled. Syntax is not a trivial issue. RDF should use processing instructions or just some fixed attributes. I cannot see why they insist on using elements: they confuse and disguise the non-RDF element structure. If people are interested in semantic markup, they would be better looking at Topic Navigation Maps for the immediate term. You can find it at http://www.ornl.gov/sgml/wg8/document/1950.htm TNM can be analysed in terms of the RDF categories: it would make an excellent external syntax for RDF. > But it is easy to tell if something can easily be made into RDF. Here's > the test: if what you are building can be expressed as a bunch of 3-tuples > > (object, propertyname, propertyvalue) > > then it's RDF-able. Otherwise it's not. I thought Lisa's comment about it being early yet was interesting. In fact, ontology and metaphysics is one of the great Western traditions, from the Greeks until now. And AI has been studied for almost 30 years: based on the history of the study of knowledge representation, there is no reason to expect any great speed. Artificial Intelligence diverged into three fields: adaptive systems, rule-based systems, and knowledge representation. Adaptive systems have flourished unseen (the "adaptive equaliser" in your modem is a "neural net", genetic algorithms are used in stock markets), but rule-based systems and knowledge representation AI work foundered. (I see rule-based made a little resurgence again recently in the guise of "data mining".) The reason was because it was so difficult to capture enough knowledge. I think RDF is an attempt to create a massive world-wide knowledge base, so that old AI hacks will have something to do with their time. The trouble is that even if we do have information modeled in RDF, there is every chance that unless the categories they express are consistant and appropriate to the AI task intended, the AI will be fed skewed or incomplete information. A lot of problems are very domain-specific: having an incomplete knowledge base means that searching on that base can only be done with a degree of tentativeness. (In Topic Navigation Maps, ISO put in a "Weighting" attribute to express this kind of fuzziness.) It is probably the only possible strategy: enrich the data and hope that somewhere along the line enough interesting information is marked up that might be useful. Of course semantic markup would also be useful for specific in-house AI systems and scholarly work. Anyway, my gist is that semantic markup itself is not useful unless the "semantic universe" used for that markup is appropriate to your task. And even then, unless the markup is rigourous and applied to all the data consistently, it may not give the results it promises. Artificial Intellegence boffins have been working for years and come up with lots of nice side-benefits, but not delivered on their direct objectives. AI people working on this (I used to work for TI supporting AI systems in their dying days, so I think I have seen the promise and the difficulties) have constently failed to deliver: I think Apple had quite a long running project on this. The onus should be on them to provide complete solutions which have clearly addressed the technical problems (in this case, incompatability of RDF with simple schema languages) rather than on our goodwill. This is why I said RDF has a "superficially appealing model". To say that every relationship can be reduced to those tuples is quite a different thing to saying that direct representation of those tuples in markup is desirable. Behind RDF's syntax is the need not to make HTML break and the desire to be able to stream process data and stick in whatever markup at whatever point it is needed: this is why they need to create their own in-line schema declaration syntax rather than use headers or PIs. Why should XML put up with these sad constraints? There is also a third problem with the use of RDF to create a global knowledge network. That is that there are legitimate questions about data transmission speed and access: good AI searching sucks up as much processing power as the user will bear: add on to this the transmission delays of networks and I cannot see the usefulness of such a network. Perhaps for in-house data. And I suppose you would get domain-specific search engines pre-fetching and pre-indexing data, like the HTML search engines do now. But it does mean that there needs to be an awful lot of infrastructure: Peter and Lesley's Virtual Hyperglossary is one big piece. > I think the only thing in DTD's that are not trivially RDF-able are > content models. They *are* RDF-able, but you have to use some of the > "Seq" machinery, which I find awkward. In fact *every* attempt so far > (the old DSD stuff, XML-Data, etc) to express content models in XML has > come up verbose and unreadable compared to good ol' 8879 DTD notation. > I think there's a better way, and want to see what xml-dev can come up > with. -Tim I think the trick may be to define many more special purpose schema languages rather than a single one. For example, a relational database schema language. Presumably there are proprietary and standard candidates. Vendors and users would undoubtedly appreciate it if they could continue to use their familiar schema notation and tools in XML without change. I would be far happier to allow existing schema languages than either to reinvent the standard declarations or attempt any grandiose universal schema systems. If we took this view, then the best approach for XSchema might be to 1) find the major candidate schema languages (markup declarations being the first) 2) create specific XML versions of each of them, allowing for safe proprietary extensions (i.e., extensions that do not create any interchange problems with tools which do not use the extensions). And then 3) note how the schema can be analysed according to RDF's categories. This is what Dan B. has suggested "It shouldn't be unfeasibly hard to represent XSchema ideas in terms of assertions framed as RDF triples..." (This representation can be done formally inside the DTD for XSchema too, using architectural forms. I think Elliot K suggested that ages ago.) Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Tue Jun 2 16:55:41 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema: ease of use (design goal 5) Message-ID: <01e001bd8e36$b7aba6e0$1e09e391@mhklaptop.bra01.icl.co.uk> >I have posted a proposed draft XSchema document at >http://www.ccil.org/~cowan/XSchema-draft-19980601.txt . I think the most important point this paper states (and demonstrates) is: >human beings will find them [XSchemas] painful to write by hand, due to their great redundancy compared to DTDs. This conflicts directly with design goal 5, which states: >XSchema documents shall be easy to create, read, and modify, and shall provide authoring support. When I first looked at the idea of encoding DTDs in XML a couple of months ago, one of my motivations was that I find the current DTD syntax very ugly, and I came to the same conclusion: whatever the merits of an XML encoding, it would not be user-friendly. (My feelings about XSL are the same). XML works well as a markup language for text; it also works well as a markup language for data; but it is very poor as a human-readable lexical encoding of a language with rich syntax. Trying to solve this problem my imagination started running away with me: * one of the limitations of XML is that we cannot constrain the content of character strings (in attributes or PCDATA) in a DTD * the ideal way to define such constraints would be with regular expressions or BNF production rules * let's call "XML with constrained character strings" Rich XML or RXML. Of course an RXML document is an XML document; it just has some "content validity" rules in addition to the XML well-formedness and validation rules. * we can imagine a "pre-parser" which takes an RXML document and automatically generates additional XML markup so that all the syntax is now fully accessible as elements and attributes. This pre-parsed document would no longer be easily readable, but it would be easily processable using standard XML tools * We could encode both the current DTD information and the additional constraints in RXML * if we use RXML rather than plain XML to encode our DTD, we can continue to use BNF-like production rules written as text, while still being able to process the thing using general-purpose XML machinery. In other words, I think we have here not only a solution to the usability dilemma posed at the beginning of this posting, but a generally useful extension to the capabilities of XML. But sorry, I don't intend to devote my life to it! Mike Kay M.H.Kay@eng.icl.co.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 2 17:07:34 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema Question 2: Namespaces Message-ID: Lisa Rein writes: >it doesn't necessarily NEED to be stable, since any "specification" we >come up with is for experimental use only as our way of assiting the XML >working group for when they define the REAL spec yes? > >Let's not forget that - although I have been personally amazed at the >unprecedented usefulness of this discussion group for its unprecedented >assistance to the WG on numerous occasions (and myself personally :-) >It is the XML WG -- NOT US -- that will ultimately define "XSchema's" >syntax etc. (if that is indeed what hey decide it should be called). > >XML Schemas will be incorporated into the XML core itself, and must be >done so using due process...(to pick its prefix, or what have you...) In the long run, this is indeed true. In the short term, however, this is not a WG project and we are not using WG 'due process' - just public discussion leading to (hopefully) a rough consensus on a specification. This is indeed an experimental specification, but it is a specification we hope to complete by the end of June, _complete with namespaces_. It would be nice if some of this proposal survives as part of an eventual W3C specification, but it may well not. I'm focused on producing a workable specification, not contemplating its eventual demise. For a discussion XSchema/W3C WG issues, see http://www.lists.ic.ac.uk/hypermail/xml-dev/9805/0454.html . Also: >Also; why would XML schemas have a different prefix than their XML >documented counterparts -- XML Schemas will become part of the CORE >specification, yes? Someday they may, but we do need something for now. Their "XML-documented counterparts" use Thus it is not necessary to standardize a prefix, although JC>it certainly would be reasonable to recommend one. Precisely. So may we recommend XSC? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jun 2 17:45:15 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema: ease of use (design goal 5) In-Reply-To: <01e001bd8e36$b7aba6e0$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <000a01bd8e3d$aeb245b0$91bc38cb@NT.JELLIFFE.COM.AU> > From: Michael Kay > * one of the limitations of XML is that we cannot constrain > the content of > character strings (in attributes or PCDATA) in a DTD > * the ideal way to define such constraints would be with > regular expressions or BNF production rules > * let's call "XML with constrained character strings" Rich > XML or RXML. Of course an RXML document is an XML document; > it just has some "content validity" rules in addition to the > XML well-formedness and validation rules. Actually, there is already a standard syntax to let you constrain the content of character strings, using the SGML Lexical Typing Definition Requirements (LTDR). In standard jargon this is called "lexical typing": the stated intention of the ISO Working Group maintaining SGML is to move these into the SGML standard--at the moment they are just parked as part of the HyperText and Time Scheduling Languages standard (HyTime). LTDR Lexical typing provides a syntax to let you use any syntax you like to constain strings. In particular it allows POSIX regular expressions. There is also a token-matching language, which can look quite like content models. You can see the standard online at http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.2.html You can also see this explained in my book "The XML & SGML Cookbook" (just out this week !!!) on page 2-117 "Defining Data Types". You can embed your own syntax inside elements using NOTATION attributes, or using PIs, of course. > * we can imagine a "pre-parser" which takes an RXML document > and automatically generates additional XML markup so that > all the syntax is now fully accessible as elements and > attributes. This pre-parsed document would no longer be > easily readable, but it would be easily processable using > standard XML tools If you are talking about a pre-parser, then the danger is that you are no longer using XML. The ability to alias strings and delimiters to (entity references which deference to) elements, PIs, entity references etc. was part of SGML (i.e., SHORTREF, DATATAG) that was jettisoned for XML. If you are talking about the ability to pre-process an entity according to a (pipeline of) processes, that also is part of SGML Extended Facilities (i.e., Formal System Identifiers) which was jettisoned by XML when they decided to use URI syntax (It could be introduced again easily: or the URI query syntax could of course be used to provide extra parameters too; or a custom XML document-type could specify a tranformation itself as part of storage/entity management--but then the data is not XML, and so is outside the XSchema scope, I think.) > * We could encode both the current DTD information and the > additional constraints in RXML > * if we use RXML rather than plain XML to encode our DTD, we > can continue to use BNF-like production rules written as > text, while still being able to process the thing using > general-purpose XML machinery. HyTime LDTR went down this track (i.e. a variant, specialized syntax) and I think it did not work so well. But I would be happy if the XML markup declarations were given explicit specifications in terms of XSchema: that would allow a simple preprocessor to convert existing DTDs into XSchemas. We have had two constituencies here: one wants to have declarations using element syntax, the other wants to add new constraints. I would again submit that there is a third which we should not ignore: people who might not want to either change to XML markup declarations or to something like XData, but want to keep their old schema-definition systems. Anyone who has played with Adobe's excellent EDD knows how mind-numbing things can get when you have to support one schema syntax with another almost identical one, even with sophisticated translators. Rick Jelliffe ========================================================== The XML & SGML Cookbook, by Rick Jelliffe Charles F. Goldfarb Series on Open Information Management 656 pages + CD-ROM, Prentice Hall 1998, ISBN 0-13-614233-0 http://www.sil.org/sgml/jelliffeXMLAnn.html http://www.phptr.com/ > Book Search > "Jelliffe" http://www.amazon.com/exec/obidos/ASIN/0136142230/002-4102466-3352420 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 2 17:47:53 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema: ease of use (design goal 5) References: <01e001bd8e36$b7aba6e0$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <35741E46.9FDABFB3@locke.ccil.org> Michael Kay wrote: > I think the most important point this paper states (and > demonstrates) is: > > >human beings will find them [XSchemas] painful to write by > hand, due to their great redundancy compared to DTDs. > > This conflicts directly with design goal 5, which states: > > >XSchema documents shall be easy to create, read, and > modify, and shall > provide authoring support. The emphasis here should be on "by hand". Writing XML documents of any sort without machine support is painful. XED, to take the lowest common denominator, makes a big difference here. > When I first looked at the idea of encoding DTDs in XML a > couple of months ago, one of my motivations was that I find > the current DTD syntax very ugly, and I came to the same > conclusion: whatever the merits of an XML encoding, it would > not be user-friendly. (My feelings about XSL are the same). > XML works well as a markup language for text; it also works > well as a markup language for data; but it is very poor as a > human-readable lexical encoding of a language with rich > syntax. I agree, if for "readable" you substitute "writable". Proper indentation conventions and other such things can make reading easier. But then, syntax-coloring editors can make writing easier, too. > * we can imagine a "pre-parser" which takes an RXML document > and automatically generates additional XML markup so that > all the syntax is now fully accessible as elements and > attributes. This pre-parsed document would no longer be > easily readable, but it would be easily processable using > standard XML tools Actually, I think XML-DTD syntax is fine for the purpose. Write DTDs, translate to XSchemas; that's what I did when writing the draft itself to produce the Meta-XSchema. > * We could encode both the current DTD information and the > additional constraints in RXML Unfortunately it's hard to know how far to go. There is a trivial XML encoding of DTDs something like this: and there is a slippery slope of just how much to encode as elements and attributes, and how much to leave in DTD format. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Jun 2 18:06:50 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema Question 2: Namespaces Message-ID: <199806021514.RAA01311@berlin.dvs1.tu-darmstadt.de> Simon St. Laurent wrote: > > Precisely. So may we recommend XSC? > Yes. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Tue Jun 2 18:42:03 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema: ease of use (design goal 5) References: <01e001bd8e36$b7aba6e0$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <35741DF1.8D07AF9B@finetuning.com> > I think the most important point this paper states (and > demonstrates) is: > > >human beings will find them [XSchemas] painful to write by > hand, due to their great redundancy compared to DTDs. If this is true, why do we want to use XSchemas again :-) ? lisa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Tue Jun 2 18:42:03 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema Question 2: Namespaces References: Message-ID: <35743057.335790DE@finetuning.com> Simon said: > > In the long run, this is indeed true. In the short term, however, this is not > a WG project and we are not using WG 'due process' Actually, this is precisely the reason for my pointing this out to you. And it appears you still haven't heard me. In the long term, OR the short term, it really makes no difference. The process of defining XML schema IS a W3C process. You really need to accept this without compromise. If any spec could be construed as "unnecessary", surely it would be the one you are proposing independently. The WG is chugging away on the its schema agenda -- you couldn't possibly need it THAT fast THAT Bad. You couldn't implement it on your own if you wanted to -- I mean you COULD -- on your own computer -- but I don't think such an implementation would be very useful -- not even to YOU... - just public discussion > leading to (hopefully) a rough consensus on a specification. Hey Simon -- get a grip on yourself tough guy. XML Schema IS XML. And XML is W3C project under the auspices of W3C's due processes. Period. And don't you ever forget it! Christ -- let's just all go and define our own Namespaces -- Then we all work together to lead the last three years of hard work right....down....the toilet! This is indeed > an experimental specification, but it is a specification we hope to complete > by the end of June, _complete with namespaces_. > > It would be nice if some of this proposal survives as part of an eventual W3C > specification, but it may well not. I'm focused on producing a workable > specification, not contemplating its eventual demise. Don't get your feathers ruffled Simon, but its inevitable eventual demise is precisely what you MUST come to terms with and accept. We could all produce our own "workable" specifications, and work together to throw caution to the wind -- without a care in the world or any concern about the potential conflict with "that other XML schema definition". Why exactly are you so hot and bothered by a desperate and immediate need to design your own spec-dependent XSchema model?? -- MUCH LESS YOUR OWN NAMESPACE DEFINITION (I know I didn't hear that ;-) > Also: > >Also; why would XML schemas have a different prefix than their XML > >documented counterparts -- XML Schemas will become part of the CORE > >specification, yes? > > Someday they may, but we do need something for now. Their Not may. Not Someday. They ARE. Right Now. The WG chair (Jon Bosak) stated this as fact several weeks ago -- this isn't folklore or an old wives tale or a rumor or a warm fuzzy feeling in the bottom of my heart -- it couldn't be any straighter from the source. Jon risked catching a little heat in making that announcement, but he made it anyway in an attempt to stop us from wasting our time, or even our energy wondering about it. A nice gesture, i thought. > Someday they may, but we do need something for now. No we don't. We can wait. Better we wait then do something that could conflict or somehow confuse the "correct" way, when it is specified, in the not-to-distant future. "XML-documented > counterparts" use prefix. > Actually, if XML documents wish to reference all, or more crucially, if they only with to reference PART of a particular schema - they WILL need a prefix -- and the determined prefix would most likely depend on certain conditions and requirement. It these conditions and requirement that I envision being defined via regular expressions. I don't see RE's providing some sort of substitute for the for the structural rules defined in a schema model -- rather such REs could used to determine WHICH schema model should be used. And since everyone seems to be in agreement that a new prefix name does not have to be introduced (it is NOT required) -- my little voice of reason reminds that it's a bad idea to introduce prefix names just because we like them, when we don't NEED them. So with all that said -- and at the risk of ruffling more feathers, Not to discourage creative implementations -- and I TOTALLY DIG YOUR ENTHUSIASM -- however misguided :-) (take it from a fellow, albiet often misguided, enthusiast) But we MUST protect our holy spec from such creative interpretation -- or we WON'T have the kind of standardized foundation strong enough to sustain such creative implementations to occur without sacrifice in the future. > John Cowan writes: > JC>Thus it is not necessary to standardize a prefix, although > JC>it certainly would be reasonable to recommend one. > > Precisely. So may we recommend XSC? > Do you have some life or death functionality keeping you awake at night -- crying out for its own prefix name? Is your prefix emotionally insecure or perhaps it has been hurt in the past by such stringent data relationships (has it aquired a complex from its incompatibility with other data types? :-) Does it have trouble expressing itself perhaps? (sorry, I couldn't resist...) I'll get to the point: I propose we get this out of the way and agree NOW that the only acceptable namespace implementation to adopt, at this stage, is freshly-defined Namespace mechanism that has already been, nicely explained and defined for us with TENDER LOVING CARE you know, like in the WORKING DRAFT delivered courtesy of the WORKING GROUP that was originally charged with the task of doing so. And Smile when we're do it too :-) To devise any sort of indepently-devised namespace spec.... while at this very moment, a public working draft politely resides on the W3C's site who respectfully requests your conformance, please... just wouldn't be polite it would be like..... Like talking back to your mother! Now go to your room! lisa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jun 2 18:46:26 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: <199806021514.RAA01311@berlin.dvs1.tu-darmstadt.de> Message-ID: <000f01bd8e46$2888f0c0$91bc38cb@NT.JELLIFFE.COM.AU> XSC: ? I definitely prefer "XDTD:" or "XSchema:". The trouble with "XSC" is that it gives no hint as to its meaning: it is therefore bad markup on principle, despite its nice size. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 2 18:50:47 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema: ease of use (design goal 5) References: <01e001bd8e36$b7aba6e0$1e09e391@mhklaptop.bra01.icl.co.uk> <35741DF1.8D07AF9B@finetuning.com> Message-ID: <35742D09.37F9F327@locke.ccil.org> Lisa Rein wrote: > > >human beings will find them [XSchemas] painful to write by > > hand, due to their great redundancy compared to DTDs. > > If this is true, why do we want to use XSchemas again :-) ? Because, unlike DTDs in SGML syntax, they can be parsed using the same facilities used to parse XML document instances. And like that. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Tue Jun 2 18:57:42 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:01:51 2004 Subject: new wired story References: <000a01bd8e3d$aeb245b0$91bc38cb@NT.JELLIFFE.COM.AU> Message-ID: <35743303.96B5E0F8@finetuning.com> speaking of ambiguous definitions and the clouding of issues.... a particulary butchered version of one of my stories has just been posted for all to see on the wired site. Luckily, my editor put his name at the bottom, so everything that's wrong -- is his fault, of course!! http://www.wired.com/news/news/technology/story/12667.html lisa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 2 19:16:16 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema Question 5: Root element issues Message-ID: We'll start the XSchema document syntax discussion at the top, with the root element. Hopefully this piece will be a nice appetizer and we can proceed to its subelements and attributes, the main course. >From the Goals: -------------------- 1. XSchema documents shall use XML document syntax, using element nesting and attributes to describe all constraints that may be verified by a processor using XSchema. -------------------- In XML documents, per 2.1 of the XML specification: -------------------- There is exactly one element, called the root, or document element, no part of which appears in the content of any other element. -------------------- XSchema documents, in order to be XML documents, must have a single root element, which may be preceded by the prolog, PIs, and perhaps comments and XML 1.0 DTD information. An XSchema document might begin: ... Do we want to provide additional information in this root element regarding XSchema version, for instance? We could add "version='0.1'" or something. Given that we're discussing verifying fragments, it's mildly ironic to be requiring a root element. Any concerns on that issue? Most important, am I forgetting anything critical? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 2 19:26:34 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:51 2004 Subject: XCond: towards an XML version of conditional inclusion Message-ID: <35743584.B4790A46@locke.ccil.org> I would like to sketch an improved replacement for the lost SGML INCLUDE and IGNORE marked sections. XML rightly ditched them in document instances, though retaining them in DTDs; they are ugly syntactically, inflexible, and don't adapt well to complex conditions. "XCond" is my tentative replacement for them. For a preliminary draft, see http://www.ccil.org/~cowan/XCond-draft-19980602.html . -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 2 20:02:04 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema: ease of use (design goal 5) References: <01e001bd8e36$b7aba6e0$1e09e391@mhklaptop.bra01.icl.co.uk> <35741DF1.8D07AF9B@finetuning.com> <35742D09.37F9F327@locke.ccil.org> Message-ID: <357444C6.70D22479@finetuning.com> uh oh - a littly birdy told be that my attempt at sarcasm was perhaps soured by my current flu-like syptoms, and that the two are combining to convey some sort of resentful attack on both people and protocol! tis' not my intention and i must remember how the wry-est of humor in person or over the telephone is *usually* all but completely lost via the email translation. tis not my intention to polarize the discussion I've been framed (by myself!) BIG HUG everybody! lisa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matthew at praxis.cz Tue Jun 2 20:06:44 1998 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:01:51 2004 Subject: XSchema: ease of use (design goal 5) Message-ID: <01bd8e51$0a6c5950$020b0ac0@xerius.ini.cz> Michael Kay wrote: >Trying to solve this problem my imagination started running >away with me: > >* one of the limitations of XML is that we cannot constrain >the content of >character strings (in attributes or PCDATA) in a DTD >* the ideal way to define such constraints would be with >regular expressions or BNF production rules >* let's call "XML with constrained character strings" Rich >XML or RXML. Of course an RXML document is an XML document; >it just has some "content validity" rules in addition to the >XML well-formedness and validation rules. >* we can imagine a "pre-parser" which takes an RXML document >and automatically generates additional XML markup so that >all the syntax is now fully accessible as elements and >attributes. This pre-parsed document would no longer be >easily readable, but it would be easily processable using >standard XML tools >* We could encode both the current DTD information and the >additional constraints in RXML >* if we use RXML rather than plain XML to encode our DTD, we >can continue to use BNF-like production rules written as >text, while still being able to process the thing using >general-purpose XML machinery. > >In other words, I think we have here not only a solution to >the usability dilemma posed at the beginning of this >posting, but a generally useful extension to the >capabilities of XML. There are several issues here: 1) What is easiest to author? 2) What is easiest to view? 3) What is easiest to process? The current content model syntax is terse and easy to author (once you have mastered it). Nevertheless, the design goals of XML very clearly point towards favoring ease of processing over terseness, as Rick points out in his reply. This is why SHORTTAG and co. are not in XML and why calls for empty endtags led to such hue and cry. So 3) should take precedence, implying an XML-based syntax. The whole point of unifying document and schema syntax is to take advantage of existing tools when working with schemas; this applies particularly to editors and browsers (as has been stated numerous times). On the other hand, I wonder if Mike's suggestion regarding "pre-parsing" could not be linked with Peter's early suggestion about binding logic to element type descriptions. In the same way, I could (when XSchema is completed) design my own element type for content models which is tied to a pre-parser (e.g. in Java) which spits out the element and attributes defined in standard XSchema. In other words, exactly what Mike describes except that standard XSchema functionality rather than ad hoc mechanisms are used to get the desired result. Something like: In the metaschema for my XSchema variant: #PCDATA In my schema itself: FOO, (BAR | BAZ) So the use of DTD content models ends up being part of the "standard", but in a highly generic way requiring only that someone write the "ContentModelPreprocessor" class. Seem nicely self-referential to me... BTW: Anyone who thinks traditional content models are so easy to write should try to do so on a Czech keyboard. :-) 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Tue Jun 2 20:14:26 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:01:52 2004 Subject: XCond: towards an XML version of conditional inclusion Message-ID: <021a01bd8e52$684bc320$1e09e391@mhklaptop.bra01.icl.co.uk> >I would like to sketch an improved replacement for the lost SGML INCLUDE >and IGNORE marked sections. For a preliminary draft, see >http://www.ccil.org/~cowan/XCond-draft-19980602.html . > A useful facility, but the proposal seems unnecessarily complex to me. I don't see the need to have the dependency on external language processors and expression syntax. A special attribute XCond:include="Yes"|"No", whose Yes/No value can be picked up from an entity, would seem to do the job just as well. If you want to generate the Yes/No value using some external evaluators, I would have thought PIs were the right mechanism to do that. Also I don't see the need to specify it in terms of groves rather than XML documents, it might be more elegant, but it means you need to refer to another specification other than the XML standard. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 2 20:20:42 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:52 2004 Subject: XCond: towards an XML version of conditional inclusion References: <021a01bd8e52$684bc320$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <35744219.2FAF0DAA@locke.ccil.org> Michael Kay wrote: > A useful facility, but the proposal seems unnecessarily > complex to me. I don't see the need to have the dependency > on external language processors and expression syntax. Rather than depending on external processors, I simply allow for them. > A special attribute XCond:include="Yes"|"No", whose Yes/No > value can be picked up from an entity, would seem to do the > job just as well. If you want to generate the Yes/No value > using some external evaluators, I would have thought PIs > were the right mechanism to do that. So having certain PIs would have magic effects on certain entities? Sounds very wifty to me, not much in the spirit of XML self-documenting documents. > Also I don't see the need to specify it in terms of groves > rather than XML documents, it might be more elegant, but it > means you need to refer to another specification other than > the XML standard. I just did that for clarity, so that I don't have to talk about attributes that may or may not be physically present in the document. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 2 20:31:59 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:52 2004 Subject: XSchema: multiple proposals Message-ID: While we've been pondering some basic questions, several folks out there have already built some sample XSchema structures that are worth taking a look at. So far I've seen two and heard of two more. One of them, from John Cowan, has already been announced to the list, and is available at http://www.ccil.org/~cowan/XSchema-draft-19980601.txt . The author of the other one I've seen is in the process of posting it. I'd like this process to continue as a set of questions, followed by a proposal incorporating the results of the questions. At the same time, I think that drafts created by individuals can give us some valuable grounding for those discussions, especially when we can compare and contrast them. If anyone else out there has created a DTD or even a part of a proposal, I'd like to know. I'll use the XSchema page (http://purl.oclc.org/NET/xschema) to link to such proposals. The XSchema page will also be the home of the specification as it develops. I hope to have a first portion, based on the discussions so far, up by the end of this week, though it may move into the weekend. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ak117 at freenet.carleton.ca Tue Jun 2 20:35:31 1998 From: ak117 at freenet.carleton.ca (David Megginson) Date: Mon Jun 7 17:01:52 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: <35740ECC.31484D2E@finetuning.com> References: <35740ECC.31484D2E@finetuning.com> Message-ID: <199806021833.OAA00799@unready.megginson.com> Lisa Rein writes: > Let's not forget that - although I have been personally amazed at > the unprecedented usefulness of this discussion group for its > unprecedented assistance to the WG on numerous occasions (and > myself personally :-) It is the XML WG -- NOT US -- that will > ultimately define "XSchema's" syntax etc. (if that is indeed what > hey decide it should be called). I don't know if this is -- strictly speaking -- true. The WG may define a core schema language, but I would be surprised if it is the only one. As I've mentioned before, it makes sense to have specialised schema languages for different knowledge domains: for example, maintenance document designers should deal with chunks like "task", and "step", not "element". The real question is what these high-level schema languages map to for exchange. All of them (the to-be-created W3C schema language, XSchema, Microsoft's XML-Data, etc.) should be able to be transformed to DTDs for exchange; perhaps they should also be able to be transformed to the W3C schema language, if that becomes common for interchange. One interesting discipline would be to derive XSchema from RDF using architectural forms: the RDF names would be hidden behind the scenes (as #FIXED attributes in the XSchema DTD), but would be available to most XML processors. I wouldn't be surprised if this ends up being the most common way to use RDF. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Tue Jun 2 20:38:01 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:01:52 2004 Subject: external Message-ID: <199806021834.UAA01731@chimay.loria.fr> The following productions in the XML 1.0 spec. are never called (i mean directly from the XML grammar) : [30] extSubset [78] extParsedEnt [79] extPE Why ? A tipo ? Pat. PS: I would like to thank Mike Champion, Gavin Nicol and Steve Withall for their answer about Attribute value. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide * Projet Aquarelle : http://aqua.inria.fr ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Don.Schaefer at usa.xerox.com Tue Jun 2 21:49:19 1998 From: Don.Schaefer at usa.xerox.com (Schaefer, Don) Date: Mon Jun 7 17:01:52 2004 Subject: C++ XML Class Lib Message-ID: <67E29010AC4BD111955E00805F0DBA312667FE@station10.roch875.mc.xerox.com> Does anyone know of a C++ XML Class Lib that can be utilized on Solaris as well as NT? Is there one that validates as well? thanks for any help! don Don Schaefer dschaefer@questra.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Tue Jun 2 22:00:38 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:01:52 2004 Subject: external Message-ID: <3.0.32.19980602125855.00ba5250@pop.intergate.bc.ca> At 08:34 PM 6/2/98 +0200, Patrice Bonhomme wrote: >The following productions in the XML 1.0 spec. are never called (i mean >directly from the XML grammar) : > >[30] extSubset Right; this one is definitely a shortcoming. It obviously provides the grammar governing the external subset discussed in the preceding paragraph; but the spec should have made this explicit. >[78] extParsedEnt >[79] extPE Both exist to support the definition of well-formedness in 4.3.2 -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Tue Jun 2 22:04:53 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:01:52 2004 Subject: C++ XML Class Lib In-Reply-To: <67E29010AC4BD111955E00805F0DBA312667FE@station10.roch875.mc.xerox.com> References: <67E29010AC4BD111955E00805F0DBA312667FE@station10.roch875.mc.xerox.com> Message-ID: * Don Schaefer | | Does anyone know of a C++ XML Class Lib that can be utilized on | Solaris as well as NT? Is there one that validates as well? You can find a (hopefully) complete list at -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ak117 at freenet.carleton.ca Tue Jun 2 22:16:32 1998 From: ak117 at freenet.carleton.ca (David Megginson) Date: Mon Jun 7 17:01:52 2004 Subject: C++ XML Class Lib In-Reply-To: <67E29010AC4BD111955E00805F0DBA312667FE@station10.roch875.mc.xerox.com> References: <67E29010AC4BD111955E00805F0DBA312667FE@station10.roch875.mc.xerox.com> Message-ID: <199806022014.QAA01040@unready.megginson.com> Schaefer, Don writes: > Does anyone know of a C++ XML Class Lib that can be utilized on Solaris as > well as NT? Is there one that validates as well? You should try James Clark's SP library (http://www.jclark.com/sp/), which supports both SGML and XML -- it even comes with a precompiled DLL for Windows victims, but it also compiles cleanly under Linux, Solaris, and HPUX (the three that I've tried). For years, SP has been hidden at the heart of a surprisingly large number of major SGML systems, and since James is a member of the W3C XML and XSL working groups, you can be trust that he'll keep the XML support up-to-date. The good news: it's free (not GPLed), even for commercial use. The bad news: it's very complex C++, and there's _no_ documentation (not even many source-code comments) except for one very simple, high-level parsing interface. There is an SP mailing list, however, so you can get help from other users. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 2 22:18:09 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:52 2004 Subject: XCond: towards an XML version of conditional inclusion References: <3.0.32.19980602124348.00b8d340@pop.intergate.bc.ca> Message-ID: <35745D60.71F780C6@locke.ccil.org> I have added examples to my draft. The URL is unchanged for now. I also caught one substantive error: my intention was that a select-element be replaced by the *content* of the accepted child element, not by the element itself. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 2 22:44:04 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:52 2004 Subject: XCond: towards an XML version of conditional inclusion References: <3.0.32.19980602132321.00bbfdd0@pop.intergate.bc.ca> Message-ID: <357463DB.65713CC4@locke.ccil.org> Tim Bray wrote: > UNLESS could be replaced by a negation attribute or simply dropped > and leave that up to the expression. Not sure if that's an improvement > or not. It's nice to be able to say what a string shouldn't be, when there's no evaluator available: i.e. include *unless* these two strings match. Making it a different attribute is basically just factoring the XCond:type attribute; Occam says, make it a single attribute. > But I'm pretty sure it be nice to have a fall-through > default, i.e. > > A good idea. Next draft (like, tomorrow). > Also, I'd put the examples *first*, the formalism later -Tim I'll make a hyperlink at the top. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Jun 2 22:59:18 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:52 2004 Subject: Names and schemas References: <199806012121.QAA20900@ACADCOMP.SIL.ORG> Message-ID: <35745C6D.2740EF60@technologist.com> Robin Cover wrote: > > I'm made to feel more in doubt than ever about the level of abstraction > that's envisioned for "schema" (and XSchema) in this discussion. It's > not clear to me that the principal goal of a new schema language would > be to define classes of markup, with (syntactic?) constraints, though > certainly that could be one role. I don't think that the role of schemas would be merely to define syntactic constraints. Usually you would use a grammar or regular expression to do that. My definition of schema is: "A document that defines a class of data objects in some data model." So a "database schema" defines a class of "databases", usually in the "relational" data model. XSchema should define a class of "elements" (and "documents") in the (still implicit) "XML data model." Angle brackets are not part of the (implicit) XML data model -- they are part of its syntax. So a schema language would not override or change those characters. The characters between tags (content) are part of the data model. It might make sense for a schema language to express contraints on those characters. > From what realm(s) of discourse are these definitions being drawn? I don't know where that definition comes from. It is my application of the intuitive notion of a schema and my experience (but not expertise) with database systems. > That said (and perhaps too much), I welcome clarifications from > Paul and others on what is meant by "schema" and what authorities > (domains) are being used for the definition. and (especially) > the extent to which it's agreed that a schema should (not) be > constrained by the notions of particular markup models. I'm not sure what *exactly* you mean by markup models. The schema works on a data model. If you can translate some random document conforming to a random markup language into something that fits that model, then the schema applies. Otherwise it does not. Simple "low-level" schemas will usually express bias towards one markup language or the other. One could imagine a markup language with no concept of attribute, or with one that could have deep structures. XSchema would probably not apply to the latter, and might not work "as well" with the former. On the other hand, a higher-level schema might not care about concepts like elements and attributes at all. For instance RDF's data model is radically different from XML's (and thus XSchemas). Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things never anger: First, the one who runs your deck The one who does the backup, and the one who signs your check http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Jun 2 23:23:17 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:52 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: Message-ID: <3.0.1.16.19980602222040.3ba7f5b6@pop3.demon.co.uk> At 15:07 02/06/98 UT, Simon St.Laurent wrote: >Lisa Rein writes: >>it doesn't necessarily NEED to be stable, since any "specification" we >>come up with is for experimental use only as our way of assiting the XML >>working group for when they define the REAL spec yes? >> >>Let's not forget that - although I have been personally amazed at the >>unprecedented usefulness of this discussion group for its unprecedented >>assistance to the WG on numerous occasions (and myself personally :-) >>It is the XML WG -- NOT US -- that will ultimately define "XSchema's" >>syntax etc. (if that is indeed what hey decide it should be called). >> >>XML Schemas will be incorporated into the XML core itself, and must be >>done so using due process...(to pick its prefix, or what have you...) > >In the long run, this is indeed true. In the short term, however, this is not It would be useful to have guidance here, because my perception differs. If we are talking about the src= document of a namespace, I thought the WG had been extremely careful not to specify what you might find in it. It could be a DTD, a chunk of DRF or some XML-data. There seems no reason why it shouldn't also be a BNF, chunks of java or an XSchema. So we need the following: the ns= URI which tells people that the namespace is identified with the XML-DEV XSchema effort. the src= document which has the precise machine-readable specification This might be a DTD, might be the equivalent XSchema, or might even be both plus some documentation and ways of sorting out which to use. >a WG project and we are not using WG 'due process' - just public discussion >leading to (hopefully) a rough consensus on a specification. This is indeed >an experimental specification, but it is a specification we hope to complete >by the end of June, _complete with namespaces_. > >It would be nice if some of this proposal survives as part of an eventual W3C >specification, but it may well not. I'm focused on producing a workable >specification, not contemplating its eventual demise. For a discussion >XSchema/W3C WG issues, see >http://www.lists.ic.ac.uk/hypermail/xml-dev/9805/0454.html . IMO the W3C process expects (and has sometimes encouraged) experimentation and individual members of it will keep an eye on what we are doing. But XSchema bears the same relationship to W3C as does any voluntarily produced language effort (cf tcl, Perl, etc. in their beginnings) - i.e. it may be a useful thing to interoperate with at some time. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Jun 2 23:24:44 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:53 2004 Subject: LISTRIVIA (was Re: Press Release: Vervet Logic Releases XML Pro v.1.0) In-Reply-To: References: Message-ID: <3.0.1.16.19980602222033.3ba76dbc@pop3.demon.co.uk> Hi - thanks for the posting. Please don't take offence at the comments below :-), but I'm trying to set the style for XML-DEV. At 12:55 01/06/98 -0500, David Gulbransen wrote: > >Vervet Logic Announces the Release of XML Pro v1.0 > >BLOOMINGTON (June 1) - Vervet Logic, a leading XML Tools development >company, announced the release of their XML editor XML Pro, version 1.0. >The editor allows users to create and edit documents using XML, a new >Internet document standard recently ratified by the W3C. XML Pro is the >first visual XML editor to released to the Internet community Factual statements are fine. However it's important to make sure that claims ('the first') are justified. Since this has been challenged on another list, it's a good idea not to include anything contentious. > >XML Pro offers the features of an advanced XML Editor with an intuitive >interface that allows XML experts and novices alike to create valid, >well-formed XML documents. Priced at $149.95, XML Pro delivers a >professional XML editing solution at a consumer price. > >"We are using Vervet's XML Pro editor because it is more cost-effective >and higher quality than building our own tools, "said Peter Cousins, a >Level 8 Systems consultant for Prudential, "They have found a sweet-spot >of price/functionality that is perfect for us." XML-DEV doesn't need recommendations :-). It is taken for granted that every new XML tool announced is superb. If you want to include praise for your product, simply include the line: &xml-dev-product-praise; and this entity will be automatically expanded when someone reads it. It > >XML Pro features: > > o An easy, intuitive graphic user interface > o A unique document tree outline view to preserve document structure > o XML validation support with Document Type Definition (DTD) integration > o Element Wizard for easy element creation and management > o Attribute Wizard for easy attribute creation and management > o Support for entities, CDATA and XML Comments > o XML code preview and printing support > o XML Pro supports the XML 1.0 specification from the W3C. This is fine > >"We're pleased to see companies using Microsoft technologies for >innovation in XML " said Adam Denning, Group Program Manager of the XML >group at Microsoft. "Microsoft is working hard to help software developers >usher in new XML technology, and Vervet Logic has created a solid, useful >XML tool." But this can be condensed to &xml-praise2(&ms;) [... more snip ...] It's valuable to have the first announcement of significantly new functionality on XML-DEV, since it can help our thinking. However I want to avoid the syndrome of new commercial product announcements every day. Systems which have a freeware offering are valuable. Freeware offering with source code are, of course, extremely welcome as they are often re-usable. I wish all our commercial members well, since they are critical to the development of a mature market and there is - I hope - room for a lot of you. It makes it far easier for me and Henry to talk to chemical informatics people if XML software is dripping from the trees. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Jun 2 23:26:59 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: Message-ID: <3.0.1.16.19980602222036.3dff83b0@pop3.demon.co.uk> At 13:31 02/06/98 UT, Simon St.Laurent wrote: > >I think you'll find in common usage that people will prefer to refer to >namespaces through common references, and that prefixes _do_ matter, whether >or not they do technically. The URI is handy, and necessary, to avoid >conflicts, but is anyone really going to talk about "namespace >urn:uuid:C2F41010-65B3-11d1-A29F-00AA00C14882"? Not unless they're showing off >their memory, in which case they might do better to memorize pi to X digits. I am implementing namespaces in JUMBO and have realised how important the ns is. It's very important to choose a good one. The prefix *is* irrelevant and I shall try to show how we can avoid some of the earlier coding problems. It's probably quite sufficient to use , etc. > >So, any contenders for the URI? members.aol.com/simonstl/xschema/ is quite a >chunk and not likely to be stable, long term. Jon Bosak very kindly let us use xml.org for the SAX spec. I suspect that Jon may regret that :-). It certainly would fit the bill for the ns here. Of course the src document need not be so stable (a PURL could be a useful idea). And, of course, people will need to have local copies behind firewalls. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Jun 2 23:29:19 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema: ease of use (design goal 5) In-Reply-To: <01e001bd8e36$b7aba6e0$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <3.0.1.16.19980602222038.3ba7f738@pop3.demon.co.uk> At 15:57 02/06/98 +0100, Michael Kay wrote: > >>human beings will find them [XSchemas] painful to write by >hand, due to their great redundancy compared to DTDs. > I don't this is necessarily true. I wrote a lot of XML Schemas for JUMBO1 - all by hand (I do everything by hand) and didn't find them difficult. They were of the form I have already posted CDATA #REQUIRED By contrast I still make many errors typing in DTDs by hand (especially in the attributes and the order of their components). I also find it very difficult to remember the times when you need brackets in your content models and when you don't. And there will be zillions of wizzy wig editors to help. I bet I could beat myself typing a normal DTD if I used XSchema with XED. But - in any case - if the DTD is any *good* the thinking time is *far* greater than the typing time. So - please don't throw XSchemas away till we've come up with some :-) P. > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Jun 2 23:30:36 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: <35743057.335790DE@finetuning.com> References: Message-ID: <3.0.1.16.19980602222026.3b1ffeb0@pop3.demon.co.uk> At 10:03 02/06/98 -0700, Lisa Rein wrote: [... a number of rather emotive things...] Please try to be constructive on this list - tirades against other XML-DEVers are unlikely to be helpful. I haven't read all the later messages on this list yet, so please excuse me if I cover later ground. I am attempting to be neutral here and my understanding is: - everyone posting on this topic is doing it in good faith. Everyone has a mixture of altruism and self-interest in what they post here and my feeling is that the altruism quotient is high. - there is a groundswell of opinion that needs the result of the process we are currently going through. I, at least, will be grateful for what comes out of it. (Even if that wasn't true, it would still be a valuable exercise). - we are extremely sensitive to the process of the W3C. There are a number of WG members who read this list and some have commented publicly on this topic. - although there is no formal process, we have been informed several times of potential developments by the W3C which helped guide our activities. For example, JonB notified us of the change of caseSensistivity and also of the major revision in XSL. If we were doing something utterly foolish here I would expect that we would pick up some gentle hints. - the implementation of XML and related specs is a grey area. The DOM is concerned with implementation but most of the others aren't. In the case of SAX there was some initial feeling that this was 'duplicating the DOM' and was unnecessary - in the event it turned out not only to be valuable, but I think that the public discussion has covered areas the DOM will find very useful (Exceptions, Encodings, etc.). My current interpretation is that XSchema (note: NOT XML Schema) is an earlier implementation of something that is currently required by a number of people. It bears the same sort of relation to RDF and XML-data efforts as does SAX to the DOM. If we can do it fast, simply and efficiently we hope the community will benefit. It it doesn't, it's another experiment from which we learn something. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From wperry at fiduciary.com Tue Jun 2 23:34:24 1998 From: wperry at fiduciary.com (W. E. Perry) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 3: Internal/External subsets References: <3.0.1.16.19980530212754.08fff9c2@pop3.demon.co.uk> Message-ID: <35746F2D.E79559CB@fiduciary.com> Peter Murray-Rust wrote: > At 16:40 30/05/98 UT, Simon St.Laurent wrote: > >This was actually one of the questions I was planning for the end, but > Peter's > >recent examples have made me move it to the front. > > > >Should XSchema provide internal and external subsets, as do XML DTD's? > > Some clarification in terminology would help here :-). There is: > - an external DTD subset (in a file foo.dtd or xschema.dtd) > - an internal DTD subset (within [...] in the DOCTYPE) > - an external XSchema (in a file *.xsc) > - an internal XSchema [subset] within elements > > There are several concerns. > - should we allow DTD subsets and XSchemas to be mixed in a document > instance (whether delivered externally or internally) > - should we allow internal XSchemas (if so, should we use RDF notation) > - should we allow external XSchemas (I assume yes). If so, should they use > RDF? > - should we allow internal and external XSchemas to be mixed. > > If we can agree on internalXSchema and externalXSchema then the questions > are clearer. > > P. And from Prof. Murray-Rust's admirable illustration of the problem have followed all of the dichotomous queries (querimonies?) of the past three days: RDF or XML-Data? W3C Namespaces or some new alternative? Single-root-document philosophy or fragment-oriented parsing? In fact, a great many of these standards and suggestions will be used as schemata, or document content restraints, or typing mechanisms, where they are useful in the markup of particular content. The inevitability of these overlapping schemes simply emphasizes the fundamental characteristic of XML: the resolution of document content will rest finally with each consumer, despite the efforts of document authors to design schemata which enforce a single ultimate parse. In the popular press XML is described as permitting the author to design, and by implication to force the realization of, unique markup elements. In fact, by separating well-formedness from validity--making the DTD and all of its analogues optional--XML vests each document instance consumer with, potentially, absolute power to decide the terms of the parse. As a practical matter, DTD's and all other XML schemata will be processed by parsing modules, often through generalized API's like SAX. We expect that the definition of XSchema on this list will naturally yield the tools to process XSchemata conforming to the standard finally promulgated. There will be similar modules to process documents conforming to RDF, XSL, XML-Data, etc. Clearly, what is required to harness a selection of these modules to a single consistent purpose is an application. The salient characteristic of this application is to resolve the competing claims of schemata which may apply to the whole, or parts, or a document and to enforce upon the application of those schemata the preferences of the application user. Such an application is, of course, a rules-processing database, designed to read documents in para materia not only with the schemata which are asserted to apply to them, but also with the rules of a user which rank the competing claims and priority of the schemata, or override them entirely, on as finely granular a basis as an individual user cares to define. No standards process will resolve entirely the overlapping claims of the diverse schemata which have sprouted around XML, and new heresies will continue to bloom and lay claim to different portions of the orthodox turf. This is inevitable from the seditious nature of XML itself. In recognizing this we should also understand that, with XML, there is no absolute parse before the document and its putative schemata are in the hands of each ultimate consumer. On the practical level where XML developers must operate, this epistemology of XML promotes a very particular form of object model for parsed (or parsed a first cut by specific schemata processing modules) documents. In the first place it is an object model, rather than a relational or network-hierarchical one. Each parsing module must be able to finish its work in isolation, producing resultant nodes which resolve to object space where they may overlap or conflict with the outputs of other parsing modules. That object space must therefore be in the control of the final user application, which not only arbitrates among a number of candidate instances output by parsing modules, but may supply overriding objects altogether its own. This is the object model which Xschema and its analogues should implicitly be aiming toward. We will not get there today, and our immediate focus is the details of XSchema, but this is the framework in which I think that our modules must eventually compete for each document consumer's favor. Respectfully, W. E. Perry xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 2 23:44:58 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 2: Namespaces References: <35740ECC.31484D2E@finetuning.com> <199806021833.OAA00799@unready.megginson.com> Message-ID: <357478E2.30275F43@finetuning.com> David Megginson wrote: > > Lisa Rein writes: > > > Let's not forget that - although I have been personally amazed at > > the unprecedented usefulness of this discussion group for its > > unprecedented assistance to the WG on numerous occasions (and > > myself personally :-) It is the XML WG -- NOT US -- that will > > ultimately define "XSchema's" syntax etc. (if that is indeed what > > hey decide it should be called). > > I don't know if this is -- strictly speaking -- true. The WG may > define a core schema language, but I would be surprised if it is the > only one. I wasn't saying it had to be the only one, just that other ones would most likely be built up FROM that. Am I wrong? Correct me. lisa xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jun 3 00:05:11 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 5: Root element issues In-Reply-To: Message-ID: <3.0.1.16.19980602223623.3ba7a346@pop3.demon.co.uk> At 17:16 02/06/98 UT, Simon St.Laurent wrote: [...] >-------------------- > >In XML documents, per 2.1 of the XML specification: >-------------------- >There is exactly one element, called the root, or document element, no part of >which appears in the content of any other element. >-------------------- > [...] >An XSchema document might begin: > > > >... > > >Do we want to provide additional information in this root element regarding >XSchema version, for instance? It is going to be *very* important in forthcoming discussion that we make it clear when we are talking about the XSchema document or the document instance. This duality will come up throughout the process. Here we are talking about the root element *of the XSchema when represented as XML*. There has to be one, or it's not valid XML. seems a reasonable name :-) P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 3 00:51:28 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 2: Namespaces References: Message-ID: <357476B2.B87AA9CD@technologist.com> Simon St.Laurent wrote: > > I propose XSC for the namespace prefix, unless someone knows of a conflict or > thinks three letters is too many. I disagree with Tim that the *suggested* namespace prefix is irrelevelent. You could similarly argue that file extensions are meaningless because of mime types. But our file systems tend to work better if we keep file extensions globally unique, as far as possible, and our documents will work better (especially with respect to cut and paste) if we can keep prefixes globally unique (as far as possible). > We also need a URI for the declaration. 'members.aol.com', the current site > for the XSchema info, is probably not appropriate. I also have simonstl.com, > and three ISBNs, but I don't think we should tie this to my identifiers. That sounds like another job for xml.org. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things never anger: First, the one who runs your deck The one who does the backup, and the one who signs your check http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jun 3 00:54:50 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:53 2004 Subject: Press Release: Vervet Logic Releases XML Pro v.1.0 Message-ID: <3.0.1.16.19980602231849.3a77a1b0@pop3.demon.co.uk> [Posted for Murray Altheim] > >Date: Mon, 1 Jun 1998 12:18:07 -0700 (PDT) >From: Murray Altheim >Subject: Re: Press Release: Vervet Logic Releases XML Pro v.1.0 >To: xml-dev@ic.ac.uk, dgulbran@vervet.com >Mime-Version: 1.0 >Content-MD5: n86kMLUVoeV5FSgQCAwynQ== > >David Gulbransen writes: >> >> Vervet Logic Announces the Release of XML Pro v1.0 >[...] >> "We're pleased to see companies using Microsoft technologies for >> innovation in XML " said Adam Denning, Group Program Manager of the XML >> group at Microsoft. "Microsoft is working hard to help software developers >> usher in new XML technology, and Vervet Logic has created a solid, useful >> XML tool." >[...] >> Windows, Microsoft, and MSXML are either registered trademarks or >> trademarks of Microsoft Corp. in the United States and/or other countries. > >Perhaps it would be doing us a favor if you were to announce for which >platforms your editor is available, and also clarify the statement which >might to some imply that XML is a 'Microsoft technology', which is left >rather fuzzy in your advertisement to this discussion group. Not too many >of your customers may know what 'MSXML' is, or understand that XML was not >developed by Microsoft. You do mention that you are a privately held >company, not owned by Microsoft, correct? > >I looked over the press release and the online text describing your editor >and found nothing about platform support (not even on the order form). Is >it Java-based and hence runs on any platform? > >Thanks, > >Murray > >........................................................................... >Murray Altheim, SGML Grease Monkey >Member of Technical Staff, Tools Development & Support >Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900 > "Give a monkey the tools and he'll build a typewriter." > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Wed Jun 3 03:43:45 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: <357476B2.B87AA9CD@technologist.com> Message-ID: <199806030146.AA01310@murata.apsdc.ksp.fujixerox.co.jp> Paul Prescod wrote: > > I propose XSC for the namespace prefix, unless someone knows of a conflict or > > thinks three letters is too many. > > I disagree with Tim that the *suggested* namespace prefix is irrelevelent. > You could similarly argue that file extensions are meaningless because of > mime types. But our file systems tend to work better if we keep file > extensions globally unique, as far as possible, and our documents will > work better (especially with respect to cut and paste) if we can keep > prefixes globally unique (as far as possible). At best, "XSC" is an example prefix. In the future, the XML WG might make namespace-aware parsers strip name prefixes. I proposed this in the XML WG and will do so again. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Wed Jun 3 07:32:55 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 3: Internal/External subsets In-Reply-To: <35746F2D.E79559CB@fiduciary.com> Message-ID: <000201bd8eb1$52878290$96bc38cb@NT.JELLIFFE.COM.AU> Good post. One thing also that must be recognised is that each "stakeholder" or viewer of a document has different interests. So there is not just a jumble of different schemas, they can be to some extent organized or selected by viewpoint. (This is a difficulty with namespaces: I think it is biases towards having only one schema do everything.) XML markup declarations are definitely targeted at document creators for example. So there may be some use in making XSchema targeted at providing recipients of data the information they need to use it. I.e. a separation of "creation" constraints from "usage/storage" constraints. Content models might be a creation constraint, while fixed attributes and extended attribute types might be a usage constraint, if you catch the drift. In other words, perhaps rather than concentrating on the nature of documents (since XML already has a model built-in) or of assertions (like RDF, since good theory does not guarantee usefulness--remember Prolog) perhaps Xschema should situate itself as being useful in some definite parts of workflows. Rick Jelliffe > From: W. E. Perry > In fact, a great many of these standards and suggestions will be > used as schemata, or > document content restraints, or typing mechanisms, where they are > useful in the markup > of particular content. ... > That object space must therefore be in the control of > the final user > application, which not only arbitrates among a number of > candidate instances output by > parsing modules, but may supply overriding objects altogether its own. > > This is the object model which Xschema and its analogues should > implicitly be aiming > toward. We will not get there today, and our immediate focus is > the details of > XSchema, but this is the framework in which I think that our > modules must eventually > compete for each document consumer's favor. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From alain at cabinfo.com Wed Jun 3 08:50:08 1998 From: alain at cabinfo.com (Alain DESEINE) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 1: RDF References: <199806021216.OAA00698@berlin.dvs1.tu-darmstadt.de> Message-ID: <3574F1DE.25C3@cabinfo.com> Ron Bourret wrote: > > Tim Bray wrote: > > > In fact *every* attempt so far > > (the old DSD stuff, XML-Data, etc) to express content models in XML has > > come up verbose and unreadable compared to good ol' 8879 DTD notation. > > I think there's a better way, and want to see what xml-dev can come up > > with. -Tim > > Regardless of whether XSchema rivals DTD notation for brevity and clarity, we > still need it. The compelling reason for XSchema is not besting the readability > of DTD notation -- a visual schema editor is far clearer than both -- but making > schema information available through XML tools (which are numerous) rather than > DTD tools (which are not). > > For this reason, I would vote against directly using RDF in XSchema, as it means > we will have designed something we can't use. > > -- Ron Bourret > I agree with Ron. I think we only get some simple mechanism. I think that incorporating some other Specs like RDF will make our work sompething else than simple. I think we need a simple mechanism like this : ... ... The DTD could be something like this : Or something like this. Notice that name are only for exmple purpose, and are definitively not a proposal. Other Element could be designed for providing informations about the XSchema file (like revision, version, and so on). Alain. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From alain at cabinfo.com Wed Jun 3 08:50:23 1998 From: alain at cabinfo.com (Alain DESEINE) Date: Mon Jun 7 17:01:53 2004 Subject: XSchema Question 2: Namespaces References: <199806021514.RAA01311@berlin.dvs1.tu-darmstadt.de> Message-ID: <3574F1E1.751F@cabinfo.com> Ron Bourret wrote: > > Simon St. Laurent wrote: > > > > Precisely. So may we recommend XSC? > > > > Yes. > > -- Ron Bourret > I agree with this, we shall recommend XSC (or something else), because this can reduce dispersion. Alain. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tikvas at agentsoft.com Wed Jun 3 08:55:57 1998 From: tikvas at agentsoft.com (Tikva Schmidt) Date: Mon Jun 7 17:01:53 2004 Subject: unsuscribe Message-ID: <3574F249.F3BE0063@agentsoft.com> unsuscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From alain at cabinfo.com Wed Jun 3 09:15:21 1998 From: alain at cabinfo.com (Alain DESEINE) Date: Mon Jun 7 17:01:54 2004 Subject: XSchema Question 5: Root element issues References: Message-ID: <3574F7C1.C3A@cabinfo.com> Simon St.Laurent wrote: > > We'll start the XSchema document syntax discussion at the top, with the root > element. Hopefully this piece will be a nice appetizer and we can proceed to > its subelements and attributes, the main course. > > >From the Goals: > -------------------- > 1. XSchema documents shall use XML document syntax, using element nesting and > attributes to describe all constraints that may be verified by a processor > using XSchema. > -------------------- > > In XML documents, per 2.1 of the XML specification: > -------------------- > There is exactly one element, called the root, or document element, no part of > which appears in the content of any other element. > -------------------- > > XSchema documents, in order to be XML documents, must have a single root > element, which may be preceded by the prolog, PIs, and perhaps comments and > XML 1.0 DTD information. > > An XSchema document might begin: > > > > ... > > > Do we want to provide additional information in this root element regarding > XSchema version, for instance? > > We could add "version='0.1'" or something. > > Given that we're discussing verifying fragments, it's mildly ironic to be > requiring a root element. Any concerns on that issue? > > Most important, am I forgetting anything critical? > > Simon St.Laurent > Dynamic HTML: A Primer / XML: A Primer / Cookies > I aggree with ... About versionning (I mean version of the document instance, of course) information (and perharps some other informations), i think we have two ways : - Including it as you propose as an attribute of the root element like ... or, - adding a new element like this : 1.0 ... I prefer the first solution, but i can agree with the second one too. Alain. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jun 3 10:51:21 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:54 2004 Subject: XSchema Question 3: Internal/External subsets In-Reply-To: <000201bd8eb1$52878290$96bc38cb@NT.JELLIFFE.COM.AU> References: <35746F2D.E79559CB@fiduciary.com> Message-ID: <3.0.1.16.19980603095052.45c778fa@pop3.demon.co.uk> At 15:34 03/06/98 +1000, Rick Jelliffe wrote: >Good post. > >One thing also that must be recognised is that each "stakeholder" or viewer >of a document has different interests. So there is not just a jumble of >different schemas, they can be to some extent organized or selected by >viewpoint. (This is a difficulty with namespaces: I think it is biases >towards having only one schema do everything.) My understanding is slightly different. The ns= is used to formalise the uniqueness and the 'ownership' of the namespace, e.g. xml.org.cml might create a global identifier for CML. The src= field does not necessarily have to point to the same document globally. This is obviously required for firewalls, but could also be valuable if the implementation language in the src= file could vary (e.g. Perl, Java). Of course it shouldn't act as a pseudo-stylesheet mechanism. > [...] >In other words, perhaps rather than concentrating on the nature of documents >(since XML already has a model built-in) or of assertions (like RDF, since >good theory does not guarantee usefulness--remember Prolog) perhaps Xschema >should situate itself as being useful in some definite parts of workflows. Oh dear. I don't *do* any workflow :-) I deal with information components. I hope XML isn't simply seen as a document management system - it's a new step in capturing knowledge through componentised information. XSchema will help us define what these components are and help manage them. P> Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jun 3 10:51:35 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:54 2004 Subject: Namespaces and Parsers In-Reply-To: <012f01bd8a9d$119ecbc0$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980603095007.3a77930a@pop3.demon.co.uk> I've now started implementing Namespaces in JUMBO2 and have a clearer view of what is required. I've found myself writing at least some of the handling in SAX, and this represents my first thinking. I'd be extremely grateful for comments. Firstly, I think the namespace draft is exactly what I want at present. Let me assume a document like: ]> Orange smoke the following happens. SAX calls the parser, which send calls to the DocumentHandler and DTDHandler. The following result in SAX calls: xml:namespace PIs the F:safety PI the elements The following do not result in SAX calls. The DOCTYPE the ATTLIST the XML declaration (The startDocument is triggered by the start of file) (Am I correct?). The namespace draft suggest several places for validation (e.g. xml:namespace must precede DOCTYPE). There is at least one validation which cannot be carried out with SAX as it stands because information is lost. That is that the xml:namespaces precede the DOCTYPE, and it was there that I was suggesting minor revisions to SAX. I think The rest of rhe namespace constructs can be verified and processed through SAX calls. My current strategy is as follows: Implement a Namespace class, whose constructor is called for each xml:namespace (through processingInstruction). This can verify the constraints and leads to an NsDef, SrcDef and Prefix for each Namespace. Namespaces can be retrieved at any stage by their Prefix (from a Hashtable). The Namespace stores the NsDef and the SrcDef (if supplied). When a PI is encountered (processingInstruction) or an element or attribute (startElement) the Names will be inspected for colons [SAX preserves these, but has no special apparatus]. If found, a UniversalName will be constructed for each object (PINode, XNode, Attribute). The UniversalName consists of the ordered pair of the namespaceName and the localName. Thus the UN for F:foo might be [http://foo.com,foo]. For internal storage this might be held as the unique and parsable String http://foo.com:foo This is, of course, an illegal elementTypeName in documents, but represents a planet-wide uniquification. This is, IMO, the key aspect of namespaces - we can create these unique strings and handle them in software. When a stylesheet comes to render such an element, it must be able to create the UniversalName for that element (i.e. the stylesheet must have the same namespaceName and localParts in its components. It need not, and may well not, use the same prefix. It is likely that for screen display I shall use the prefix (e.g. the element might be displayed as F:foo) but the user should have the option of displaying the UniversalName if required. At this stage, merging of documents presents no problems. If I import another document with a different namespace which also happens to use the prefix F: I can create the universal names *before* merging the documents. I would probably create a trivial prefix (e.g. F1) for display. The behavior associated with each element will either be determined through a stylesheet (*after UniversalName resolution*) or through mapping to java classes. For the latter, the mapping will also involve resolution. Thus if I use an XSchema of the form: com.foo.FOONode.class ... The element FOO:foo will be resolved to the same UniversalName as in the document instance. This element is then mapped onto the Java class. It can display the button in orange and emit smoke when pressed. For output the user will have the option to set the prefixes for each namespace. By default they will have the same as they started with. I feel very happy and excited about this. As far as I can see it's implementable fairly simply in JUMBO2 and will be much nicer than JUMBO1's namespaces. There are some remaining problems: - unqualified names (i.e. prefix = null). Although I expect that in a year's time almost all XML will be using namespaces, there will be chunks which don't. Very often these will conform to a particular DTD (e.g. XHTML) but without qualification. I therefore have a (slightly dangerous) mechanism which I used in JUMBO1. It mapped all unqualified names to a prefix of "#DEFAULT" (a deliberately illegal Name). This could then be associated with a namespace either by an xml:namespace or through program operation. The advantage of this is that it then gives the user a chance to qualify their documents. - Xpointers. This is more serious. XPointers locate elements and attributes by the occurrence of QNames in the document. Thus descendant(1,FOO:foo) will *not* find anything in our example instance. Since 'most people' agree that the prefix has no formal standing, perhaps XPointer V2.0 (or even the latest revision) could allow UniversalName substitution. I think this would be extremely valuable and do not see any serious downside (given that we are implementing namespaces anyway). P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Wed Jun 3 13:37:53 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:01:54 2004 Subject: XSchema: multiple proposals Message-ID: <199806031121.NAA04198@berlin.dvs1.tu-darmstadt.de> Simon St. Laurent wrote: > While we've been pondering some basic questions, several folks out there have > already built some sample XSchema structures that are worth taking a look at. > So far I've seen two and heard of two more. One of them, from John Cowan, has > already been announced to the list, and is available at > http://www.ccil.org/~cowan/XSchema-draft-19980601.txt . The author of the > other one I've seen is in the process of posting it. And here it is, along with a list of comments/questions and a list of differences from John's proposal: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xschema.html Because John posted his first, I had the advantage of comparing the two and tweaking mine a bit (thanks, John ;). Both proposals are substantially similar to each other, as well as to the XML-specific parts of XML-Data. They differ mostly in element names and in how ?/+/* and attribute types are represented. All of which leads me to wonder if is there an (as yet undiscovered) way to represent XML content models in XML without using the basic structure: ... ... ... ... ... ... ... ... -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From anders at rcs.urz.tu-dresden.de Wed Jun 3 14:32:18 1998 From: anders at rcs.urz.tu-dresden.de (Andrea Anders) Date: Mon Jun 7 17:01:54 2004 Subject: From SGML to XML Message-ID: There are tools which can automatically transform SGML to XML (DTD and document instance) to receive valid documents? cheers A. Anders ____________________________________________________________ Andrea Anders ------------- eMail: anders@rcs.urz.tu-dresden.de WWW: http://rcswww.urz.tu-dresden.de/~anders xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Wed Jun 3 15:18:46 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:01:54 2004 Subject: external Message-ID: <002401bd8ef2$54190e80$1e09e391@mhklaptop.bra01.icl.co.uk> >The following productions in the XML 1.0 spec. are never called (i mean >directly from the XML grammar) : > >[30] extSubset >[78] extParsedEnt >[79] extPE > I think these constructs are never referenced because (like [1] document) they are all top-level constructs, they are never part of something else. Mike K xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 3 15:19:59 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:54 2004 Subject: From SGML to XML References: Message-ID: <357548F9.DABAADFC@technologist.com> Not every SGML DTD can be transformed into a version conforming to the XML subset. SGML documents can be normalized into an XML version with "sx" from http://www.jclark.com. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 3 15:23:15 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:54 2004 Subject: Namespaces and Parsers References: <3.0.1.16.19980603095007.3a77930a@pop3.demon.co.uk> Message-ID: <357548AB.3C76D5A7@technologist.com> Peter Murray-Rust wrote: > > - Xpointers. This is more serious. XPointers locate elements and > attributes by the occurrence of QNames in the document. Thus > descendant(1,FOO:foo) > will *not* find anything in our example instance. Since 'most people' agree > that the prefix has no formal standing, perhaps XPointer V2.0 (or even the > latest revision) could allow UniversalName substitution. I think this would > be extremely valuable and do not see any serious downside (given that we > are implementing namespaces anyway). XPointers, XSL, XSchema and most other XML processing specs will have to be updated to be namespace aware. This should probably done in version 1.0 of those specs. That explains the urgency of the namespace proposal. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 3 15:23:18 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:54 2004 Subject: XSchema Question 2: Namespaces References: <35740ECC.31484D2E@finetuning.com> <199806021833.OAA00799@unready.megginson.com> <357478E2.30275F43@finetuning.com> Message-ID: <35747FD1.C8BEA2D@technologist.com> David Megginson wrote: > I don't know if this is -- strictly speaking -- true. The WG may > define a core schema language, but I would be surprised if it is the > only one. Lisa Rein wrote: > > I wasn't saying it had to be the only one, just that other ones would > most likely be built up FROM that. Am I wrong? Correct me. All XML documents represent trees. Some schema languages will work with those trees (e.g. XSchema). Some XML documents ALSO represent tables (2D structures). Those will require schema languages that look something like relational database schema languages. Some XML documents represent machine-processable "knowledge". Those will require schema languages RDF-Schema. Maybe the W3C could make such a flexible "schema container" that all of these schema languages could be implemented in the container, but I think that there comes a point when a container is SO flexible as to be useless. Putting relational, knowledge-rep and tree verification information in one schema strikes me as probably not useful, even if it turns out to be possible. The important thing to note is that each type of schema will be working on a different underlying data model -- all encoded in the same XML document. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things never anger: First, the one who runs your deck The one who does the backup, and the one who signs your check http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 3 15:23:57 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:54 2004 Subject: XSchema and namespaces References: <000201bd8eb1$52878290$96bc38cb@NT.JELLIFFE.COM.AU> Message-ID: <357545D4.869B2E2A@technologist.com> Rick Jelliffe wrote: > > Good post. > > One thing also that must be recognised is that each "stakeholder" or viewer > of a document has different interests. So there is not just a jumble of > different schemas, they can be to some extent organized or selected by > viewpoint. (This is a difficulty with namespaces: I think it is biases > towards having only one schema do everything.) I agree. Nobody from the WG has commented publically or privately on the issue yet. (hint, hint) I'm perfectly happy to have every name belong to a single namespace, but they can be constrained by *0 or more* schemas. The namespace spec. should either support this directly (unlikely) or remove references to schemas altogether. But from a logical point of view, I don't understand why the namespace declaratoin should point to schemas, but not stylesheets, search engine keyword indexes and so forth. Schemas are just another type of processing specification. In some applications they will be cruicial. In others they will be irrelevant...just like stylesheets. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things never anger: First, the one who runs your deck The one who does the backup, and the one who signs your check http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 3 15:23:55 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:01:54 2004 Subject: XSchema Question 3: Internal/External subsets References: <35746F2D.E79559CB@fiduciary.com> <3.0.1.16.19980603095052.45c778fa@pop3.demon.co.uk> Message-ID: <3575476A.3D849B16@technologist.com> Peter Murray-Rust wrote: > > My understanding is slightly different. The ns= is used to formalise the > uniqueness and the 'ownership' of the namespace, e.g. xml.org.cml might > create a global identifier for CML. The src= field does not necessarily > have to point to the same document globally. I'm not sure what you mean here. A particular namespace declaration will have zero or one srcdef, no matter where on the web it is accessed from. Rick's point is that it should allow zero or more. > This is obviously required for > firewalls, but could also be valuable if the implementation language in the > src= file could vary (e.g. Perl, Java). Of course it shouldn't act as a > pseudo-stylesheet mechanism. I'm not sure that implementation language is the crucial factor. Schemas will hardly ever be full computer programs, and I would be worried about a system in which the exact same schema is expressed in two different languages (especially two different programming languages!). I think that Rick is referring to different levels and types of schemas...one for validating the parse tree, one for advanced hyperlinks, one for knowledge-representation assertions (e.g. RDF Schemas) etc. The namespaces proposal requires us to choose a single schema as the "canonical" one as if all of the other levels and types of schemas were somehow less important. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Jun 3 15:46:13 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:01:55 2004 Subject: ANN: Free-DOM 0.2.3 released Message-ID: <000001bd8ef4$c9256f00$2ee044c6@arcot-main> Free-DOM 0.2.3 is a maintenance release with some bugfixes and a rehash of DOM driver framework for more flexibility. For those interested, 0.3 release will coincide with next release of the DOM spec. This does not necessary mean that the DOM spec will go through seven more exciting revisions to reach 1.0 ;-p. Just in case you are wondering, Free-DOM (and its predecessor SAXDOM) are being used by thousands of people around the world. I was surprised to find that most of them live in the heart of Mongolia where Java is considered manly and practiced between horse hopping and sword dances. XML is considered more mundane since the government of Mongolia is currently considering whether to adopt XML as their national language. To 'speak' XML, you use arm jestures for elements and finger jestures for attributes. Entities are spoken with a foot striking specific regions of the listener thus utilizing pain as part of the language. DTD subsets are indicated by rolling their eyes before and after. Have fun, Don Park http://www.docuverse.com/personal/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Jun 3 15:47:40 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:01:55 2004 Subject: XSchema: multiple proposals Message-ID: <004d01bd8eee$58a06830$2ee044c6@arcot-main> >All of which leads me to wonder if is there an (as yet undiscovered) way to >represent XML content models in XML without using the basic structure: Frankly, I would like to see separate definitions for each element, attributes, and containment rules. I hated nested procedures in Pascal so I hate having to define objects inside another definition. Same thing happened with XSL where they mixed pattern definition and action rules together so that patterns nor rules can't be shared. Other than that, I am enjoying the stampede. Don Park http://www.docuverse.com/personal/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From h.rzepa at ic.ac.uk Wed Jun 3 15:55:15 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:01:55 2004 Subject: LISTADMIN: Daily digests instead of weekly ones? Message-ID: The volume on this list has grown to the point that daily digests are probably preferable to weekly ones. I will shortly put this request into the people who run the digests, and hope it could be actioned shortly (unless I get strong representations from the list not to do so). I will also ask for the siggy file to be shortened so as to reduce the bulk of the digests at least a little (the siggy arose from my inability to get off a list I subscribed to a few years back because the information to do so was entirely lacking!!) Meanwhile, if you wish to subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest PLEASE DO NOT do so using the form subscribe xml-dev-digest email@address since this requires direct intervention by me, and I would not wish to have to cope with the deluge if its avoidable (about 15-30 manual interventions per week are currently needed). Similarly, if you wish to unsubscribe from the individual postings list, PLEASE DO NOT do so using the form unsubscribe xml-dev email@address since the same applies. Oh, trivial as it may seem, I get about 2-3 requests a week actually of the form subscribe xml-dev youremail@youraddress, where the latter has not been expanded to the user's actual values. I expect the people who send such requests often wonder why they never get added to the list! Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Wed Jun 3 16:02:57 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:01:55 2004 Subject: XSchema: multiple proposals In-Reply-To: rbourret@dvs1.informatik.tu-darmstadt.de's message of "Wed, 3 Jun 1998 13:21:07 +0200" References: <199806031121.NAA04198@berlin.dvs1.tu-darmstadt.de> Message-ID: Ron> Ron Bourret => In article <199806031121.NAA04198@berlin.dvs1.tu-darmstadt.de>, Ron => wrote: Ron> And here [is my XSchema straw-proposal], along with a list of Ron> comments/questions and a list of differences from John's proposal: Ron> Ron> I have quite a few comments on this proposal; most of them are minor, apart from wanting some provision for documenting schema definitions. The DTD: Ron> Most people consider idref or IDREF to be a bad name for an IDREF attribute; each IDREF ought to be named for the role it fulfils. (This is simply a matter of style; it's more important if an element refers to two or more other elements.) Ron> Ron> Ron> Perhaps I'm confused; I thought that by "name declared in the DOCTYPE" you meant the name of the root element. But if that were the case, you wouldn't be able to use it as the ID (since its ElementDecl would want the same ID). In your XSchema-in-XSchema document, for instance, you never declared the "XSchema" element. I think what you wanted is Ron> Ron> I can understand that you like the symmetry between Choice an Seq, but I don't like the way that Choice can be an immediate descendent of Choice, or Seq an immediate descendent of Seq - it adds no extra value, and increases the number of ways of representing a particular schema. This makes comparing XSchemas more difficult (not a design goal, I know, but I see no reason to gratuitously complicate things). is equivalent to and is equivalent to You also write: Ron> o I do not include entities or notations. Fine by me, at this stage. Ron> o Ron> o To identify elements and element references, John uses Ron> NMTOKEN attributes while I use ID/IDREF attributes. John's Ron> strategy enforces the Name production while mine (possibly Ron> -- I don't know much about IDs and IDREFs) allows use of ID Ron> mechanisms. ID/IDREF values are constrained to be name tokens, but also enforces the uniqueness and existence constraints, so your method is stronger and still consistent with the XML definition. AFAICS, not having studied John's proposal[*], yours won't allow anything his doesn't in this respect. (I note that you had to relax down to NMTOKEN for attribute names, though, which aren't necessarily unique - I don't know an easy way around that). [*] No bias - I was just more rushed when John's appeared. Ron> o Ron> o To declare enumerated values, John uses a CDATA attribute Ron> and I use PCDATA. We should probably both use NMTOKENS Ron> attributes, which forces the enumerated values to match the Ron> Nmtoken production. Do you mean the following? > > > > I like that (more than the current proposal). Your questions: Ron> o Is there any way to ensure that the ElementRef's in Mixed Ron> do not contain any duplicate references? I couldn't think Ron> of any. Nor I. (The same concern applies to Choice, of course). Ron> o ElementDecl's and ElementRef's refer to each other through Ron> ID and IDREF attributes. I have no idea how/if this really Ron> works, but pretty much stole it from XML-Data. Is there a Ron> better way to do this with XLink and XPointer? I have a preference for ID/IDREF, as this works in ordinary XML or SGML systems, without requiring XLink support. But it raises the question: how to support linked XSchemas? Ron> o Ron> o I eliminated the AttlistDecl production from the XML spec. Ron> There was no reason to include this because all it did was Ron> name the element to which the attributes belonged and we get Ron> this association through nesting. Note that eliminating Ron> this means that when mapping DTD-> XSchema->DTD, we will Ron> lose any empty attribute lists. Does this matter? That's fine by me. Empty ATTLIST declarations carry no information in XML. (I think that in traditional SGML, they prevent users supplying ATTLISTs in the internal subset, but that disappears with WebTC). Ron> o Ron> o Do we want to include a Comment element in XSchema? There Ron> were some early requests for this, although it didn't make Ron> the final goals. I'm going to push for more than mere comments. I'd like to see a sensible markup for human-readable documentation (Java afficionados will know what I mean if I suggest Javadoc, and liken schemas to classes, elements to functions and attributes to formal parameters): Ron> Ron> *purpose of this element* Ron> Ron> ... *role of this child element* Ron> Ron> ... Ron> Ron> Ron> *purpose of this atttribute* Ron> ... Ron> ... Ron> ... Ron> Ron> Ron> ... Ron> Ron> Ron> ... Ron> (where the content-model of the "doc" element is yet to be determined). [P.S. Please could you clean up your HTML? I get lots of > Bad start-tag P [not allowed here], inferring
  • > Containing elements: HTML:BODY:BODYTEXT:UL errors. I don't think that's acceptable for a technical paper.] On the whole, I like this proposal. The only gripe I have is the lack of provision for in-line documentation. Most the issues I've mentioned are minor niggles. Thanks for taking the time to dream this up! -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Wed Jun 3 16:25:53 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:01:55 2004 Subject: XSchema: multiple proposals In-Reply-To: Toby Speight's message of "03 Jun 1998 15:02:46 +0100" References: <199806031121.NAA04198@berlin.dvs1.tu-darmstadt.de> Message-ID: Toby> Toby M. Speight Ron> Ron Bourret Ron> o ElementDecl's and ElementRef's refer to each other through Ron> ID and IDREF attributes. I have no idea how/if this really Ron> works, but pretty much stole it from XML-Data. Is there a Ron> better way to do this with XLink and XPointer? => In article , Toby wrote: Toby> I have a preference for ID/IDREF, as this works in ordinary XML Toby> or SGML systems, without requiring XLink support. But it raises Toby> the question: how to support linked XSchemas? I meant, "including other XSchemas by reference," in case I wasn't clear enough. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 3 16:49:40 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:55 2004 Subject: John replies to Ron: Queries Message-ID: <3575620D.AF9BF32C@locke.ccil.org> Ron Bourret writes at http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/issues.html : > Issues: > > ElementDecl deviates from elementType in XML-Data. elementType does > not require any members of the first group (the content model > declaration); presumably, a missing content model means empty. > ElementDecl follows the XML spec, which requires a content model. I think, rather, that XML-Data is trying to handle more general data sources than XML documents, for some of which the whole concept of a content model may make no sense. What is the content model of a Java object? It has a name and attributes, but nothing reasonably adhering to the concept "content model". This is not a goal for XSchema 1.0, so I agree that your choice is correct. > ElementDecl contains ElementRef and PCData for simplicity. These are > common content models and, although they could be placed in Seq/Choice > or Mixed, respectively, the efficiency in including them seemed to be > worth the deviation from the XML spec. This follows the model used by > XML-Data. I agree wrt ElementRef. See below for comments on Mixed. > It is possible to replace Choice and Seq with a Group element, > which would have an attribute specifying whether the > Group is a Choice or a Seq. This is what XML-Data does. I chose to > follow the XML spec. Again, XML-Data is trying to be general. Note that it can handle SGML &-groups, and potentially other kinds of groups (XOR-groups?) too. > Mixed is declared as containing zero or more (*) ElementRef's. > This matches the XML spec but not the XML-Data spec, > which says it must contain one or more (+) ElementRef's. I think that either you should require Mixed to have one or more children, or else you should eliminate the separate PCData element. Otherwise, the choice is arbitrary between an empty Mixed element (which is what my proposal uses) and a PCData element. Arbitrary choices are bad. (IMHO it is better to have just Mixed, particularly since #PCDATA-only content is still called "mixed content" in SGML-ese.) > Questions: > ElementDecl's and ElementRef's refer to each other through ID and > IDREF attributes. I have no idea how/if this really > works, but pretty much stole it from XML-Data. Is there a better way > to do this with XLink and XPointer? No, I think that ID and IDREF win here. XLink is overpowered for the purpose, and since all references are internal, the XPointer would just be "#the-id" instead of "the-id". Why add an extra byte when ID/IDREF do it correctly? > Is there any way to ensure that the #PCDATA in EnumerationValue, > NotationValue, and AttValue match the correct XML productions? > I can't think of any. I don't think so, which is one reason that I avoid #PCDATA in elements. > Do we want to include a Comment element in XSchema? There were some > early requests for this, although it didn't make the final goals. What for? Comments are comments, and XML comments work fine in XSchemas. We don't want to resurrect the dreaded COMMENT element from Netscape HTML, or was it Microsoft HTML. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 3 16:57:20 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:55 2004 Subject: Namespaces and Parsers References: <3.0.1.16.19980603095007.3a77930a@pop3.demon.co.uk> Message-ID: <3575634F.2AEBDDA@locke.ccil.org> Peter Murray-Rust wrote: > Thus the UN for F:foo might be [http://foo.com,foo]. For internal storage > this might be held as the unique and parsable String http://foo.com:foo Alas, ":" is valid in URIs (see RFC 1738). I suggest "^" or "~", which are not valid in URIs. "#" would work too, but would suggest the wrong semantics. > - Xpointers. This is more serious. XPointers locate elements and > attributes by the occurrence of QNames in the document. Thus > descendant(1,FOO:foo) > will *not* find anything in our example instance. Since 'most people' agree > that the prefix has no formal standing, perhaps XPointer V2.0 (or even the > latest revision) could allow UniversalName substitution. I think this would > be extremely valuable and do not see any serious downside (given that we > are implementing namespaces anyway). I don't think that XPointers have to be able to survive changes to prefixes, any more than they have to be able to survive changes to element GIs. It is just as reasonable to change the GIs globally as it is to change the prefixes globally, but *something* has to stay the same in order for XPointers to work at all. I suspect that XPointers that mention particular GIs, attribute names, and the like should be deprecated anyway, and that what really matters are IDs and tree-walking. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Wed Jun 3 17:10:03 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:01:55 2004 Subject: Pre- and Post-conditions (was RE: XSchema: multiple proposals) In-Reply-To: <004d01bd8eee$58a06830$2ee044c6@arcot-main> Message-ID: <000701bd8f01$e73bd800$c6bc38cb@NT.JELLIFFE.COM.AU> > From: Don Park > >All of which leads me to wonder if is there an (as yet > >undiscovered) way to > >represent XML content models in XML without using the basic structure: > > Frankly, I would like to see separate definitions for each element, > attributes, and containment rules. On approach would be to get rid of the notion of content models entirely (i.e. leave them where they are in the markup declarations), and replace them with more generalized pre- and post-conditions. A document is valid if each post-condition is true at a start-tag and if each pre-condition is true at the corresponding end-tag. Following is a really simple version. The reason why this might be useful is that it allows all sorts of containment constraints to be expressed but in a decentralized, incremental manner. --------------------------------------------------------------------------- ---------------------------------------------------------------------------- E.g. the following content model could be expressed (the XLink is incorrect...dont flame me!!!!!!!!!!) HERE(parent) == "x" This kind of thing can better express complicated validations, such as that if a certain element above has an attribute with a certain value, the current element or its children should not provide some attribute value. Presumably the syntax should follow ECMA or Perl (Yuck) more, and allow cascading assertions. Rick Jelliffe ========================================================== The XML & SGML Cookbook, by Rick Jelliffe Charles F. Goldfarb Series on Open Information Management 656 pages + CD-ROM, Prentice Hall 1998, ISBN 0-13-614233-0 http://www.sil.org/sgml/jelliffeXMLAnn.html http://www.phptr.com/ > Book Search > "Jelliffe" http://www.amazon.com/exec/obidos/ASIN/0136142230/002-4102466-3352420 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 3 17:25:42 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:55 2004 Subject: XSchema: multiple proposals References: <199806031121.NAA04198@berlin.dvs1.tu-darmstadt.de> Message-ID: <357569FA.5AD780D5@locke.ccil.org> Toby Speight wrote: > I can understand that you like the symmetry between Choice an Seq, > but I don't like the way that Choice can be an immediate descendent > of Choice, or Seq an immediate descendent of Seq - it adds no extra > value, and increases the number of ways of representing a particular > schema. This makes comparing XSchemas more difficult (not a design > goal, I know, but I see no reason to gratuitously complicate things). [examples snipped] XML DTDs allow the same flexibility, with content models like "(A | (X | Y))" versus "(A | X | Y)" and similarly for sequences. My proposal states: "It is not possible to reconstruct the exact DTD used to create an XSchema, but a functionally equivalent DTD can be reconstructed." I think this difference comes under that heading. I agree that having multiple ways of representing the same thing is a Bad Thing. > [*] No bias - I was just more rushed when John's appeared. So get cracking! :-) > > > > > > > > > > I like that (more than the current proposal). I find NMTOKENS (and to a lesser degree the other plural attribute types) obnoxious. They place an additional parsing burden on applications that use them, since AFAIK no parser offers to split the attribute values up (and only a DTD-aware parser could do so). If something is genuinely one-to-many, then element substructure is more useful for representing it. > I have a preference for ID/IDREF, as this works in ordinary XML or > SGML systems, without requiring XLink support. But it raises the > question: how to support linked XSchemas? How about with external parsed entities? Since we would want to link in whole XSchemas, not just parts of them, as a rule, it suffices to incorporate them entire by reference. > That's fine by me. Empty ATTLIST declarations carry no information in > XML. (I think that in traditional SGML, they prevent users supplying > ATTLISTs in the internal subset, but that disappears with WebTC). I don't think so. The WebTC, K.4.4.1, explicitly permits empty ATTLIST declarations, suggesting that they were forbidden before. (I don't have the text of 8879 available.) > I'm going to push for more than mere comments. I'd like to see a > sensible markup for human-readable documentation (Java afficionados > will know what I mean if I suggest Javadoc, and liken schemas to > classes, elements to functions and attributes to formal parameters): Now that is an excellent idea! However, it would be necessary to permit arbitrary XML markup within the doco, so a content model of ANY is probably the right thing here. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 3 17:48:14 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:55 2004 Subject: John replies to Ron: Differences Message-ID: <35756FCE.DE2F025E@locke.ccil.org> Ron Bourret writes in http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/differences.html > I do not include entities or notations. I think that XSchemas must contain all the information that DTDs do that is visible outside the DTD. Thus, parameter entities (which are not visible outside the DTD in XML) can go, but general entities and notation declarations must remain. If they do not, XSchemas are not usable for validation. (I never meant to imply, BTW, that XSchemas were not useful with WF documents; on the contrary, a document that is formally only WF because no DTD is available can be validated by an XSchema validator if its XSchema is available.) > To indicate a PCDATA-only element, I use a PCData element while John > uses an empty MIXED element. Although the PCData element is not > strictly necessary, I think the commonality of PCDATA-only content > makes it useful. I was thinking that PCDATA-only content is not so common. Most of the time, textual elements contain fancy-text information like bold, italic, or whatever. Pure plain text with no markup allowed probably makes the most sense in title elements and such. See my comments in a previous message on why it's bad to allow both empty MIXED elements and PCDATA elements in a single design. > To indicate frequency (optional, required, zero/one or more), I use > an attribute on Choice, Seq, and ElementRef > elements while John uses separate elements (OPT, OPTRPT, REPEAT). > I found John's mixture of frequency and structural information > confusing. I agree that this is better, and will be revising my draft. > To identify elements and element references, John uses NMTOKEN > attributes while I use ID/IDREF attributes. John's > strategy enforces the Name production while mine (possibly -- > I don't know much about IDs and IDREFs) allows use of > ID mechanisms. IDs are better in every way, and I can't imagine why I didn't think of them. They impose the same constraints as NMTOKEN attributes, which is a superset of the Name production, for Names cannot begin with XML digits. Changed in the next draft. > To declare the non-enumerated attribute type, John uses an attribute > while I used empty elements. I am torn here -- using > an attribute is much cleaner, but means that enumerated attribute > types are declared differently than non-enumerated > types. I'm willing to go either way on this one. > (Note: I couldn't figure out how John declared CDATA and NOTATION > attributes -- did I miss something?) This is what is technically known as a "blunder". On my part. Fixed in the next draft. My intent was to declare notation attributes like the others, and leave CDATA attributes as the #IMPLIED value. But a default of "CDATA" would be better. > To declare an attribute's default value, John uses an attribute > and I use PCDATA. I made a principle of not using PCDATA anywhere except in the definitions of internal general entities, where it's unavoidable. (You don't handle entities and so don't have that issue.) The chief reason is that XML parsers need not expand entities in PCDATA, leaving the work up to the application, whereas entities in attribute values get expanded greedily in the parser. > To declare enumerated values, John uses a CDATA attribute and I > use PCDATA. We should probably both use NMTOKENS attributes, which > forces the enumerated values to match the Nmtoken production. As I said before, I hate NMTOKENS attributes. I think it is good to have a sub-element for each enumerated value. However, I should not have tried to use the same element for an attribute value default and for an enumeration value, since one is CDATA and the other is NMTOKEN (or, actually, Name). The next draft will fix that. I note that you require at least one element declaration, whereas I do not. A DTD with no element declarations is valid, so I think I am correct here. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Wed Jun 3 18:18:01 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:01:55 2004 Subject: From SGML to XML In-Reply-To: Paul Prescod's message of Wed, 03 Jun 1998 09:00:41 -0400 Message-ID: <199806031617.RAA11075@stevenson.cogsci.ed.ac.uk> > SGML documents can be normalized into an XML version with "sx" > from http://www.jclark.com. As far as I can see, sx does not attempt to reproduce the dtd at all, and expands entity references and inserts defaulted attributes. Has anyone attempted a converter that produces an XML document with an as-equivalent-as-possible dtd? -- Richard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Wed Jun 3 18:43:55 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:01:55 2004 Subject: XSchema: multiple proposals In-Reply-To: John Cowan's message of "Wed, 03 Jun 1998 11:21:30 -0400" References: <199806031121.NAA04198@berlin.dvs1.tu-darmstadt.de> <357569FA.5AD780D5@locke.ccil.org> Message-ID: John> John Cowan [I've re-ordered this, to put the least contentious (from my POV) issues first. Discussion of empty ATTLIST declarations snipped - I believe you're right.] => Toby Speight wrote: >> [*] No bias - I was just more rushed when John's appeared. => In article <357569FA.5AD780D5@locke.ccil.org>, John wrote: John> So get cracking! :-) Point taken. :-) Soon, I promise! >> ... I don't like the way that Choice can be an immediate descendent >> of Choice, ... - it adds no extra value, and increases the number >> of ways of representing a particular schema. John> XML DTDs allow the same flexibility, with content models like John> "(A | (X | Y))" versus "(A | X | Y)" and similarly for sequences. John> John> My proposal states: "It is not possible to reconstruct the exact John> DTD used to create an XSchema, but a functionally equivalent DTD John> can be reconstructed." I think this difference comes under that John> heading. Exactly. John> I agree that having multiple ways of representing the same thing John> is a Bad Thing. Looks like we agree here. >> > >> > >> > >> > >> >> I like that (more than the current proposal). John> I find NMTOKENS (and to a lesser degree the other plural attribute John> types) obnoxious. They place an additional parsing burden on John> applications that use them, since AFAIK no parser offers to split John> the attribute values up (and only a DTD-aware parser could do so). John> If something is genuinely one-to-many, then element substructure John> is more useful for representing it. Hmm. I see your point. I think what I dislked about Ron's proposal is the unconstrained #PCDATA here: Ron> Ron> I think that the list-of-elements structure can be retained, but with tighter constraints by writing > > > > As a bonus, it's slightly less verbose in use (using "/>" syntax). Perhaps the notation value should be an IDREF to a defined notation? >> I'm going to push for more than mere comments. I'd like to see a >> sensible markup for human-readable documentation (Java afficionados >> will know what I mean if I suggest Javadoc, and liken schemas to >> classes, elements to functions and attributes to formal parameters): John> Now that is an excellent idea! However, it would be necessary John> to permit arbitrary XML markup within the doco, so a content John> model of ANY is probably the right thing here. I'd like to agree at least some conventions here, but I think we should defer the details until later. For the moment, I think we should concentrate on *where* we can put documentation. With IDREF, we could keep the documentation separated from the schema, but I'm a follower of the theory which says that the closer the documentation is to the code, the more likely they are to correspond. >> I have a preference for ID/IDREF, as this works in ordinary XML or >> SGML systems, without requiring XLink support. But it raises the >> question: how to support linked XSchemas? [i.e. how to reference >> element definitions from other XSchemas?] John> How about with external parsed entities? Since we would want to John> link in whole XSchemas, not just parts of them, as a rule, it John> suffices to incorporate them entire by reference. I don't think this is really workable. We don't have SUBDOC in XML, nor do we have anywhere in the XSchema DTD that we can insert another tree rooted at XSchema. Even if the mechanics can be made to work, I'm concerned about ID clashes. Can namespaces help prevent this? I'm not convinced about wanting only to link-in whole XSchemas, either: it seems to me that lots of people would want P[aragraph] (and its children) from HTML, for instance. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dgulbran at vervet.com Wed Jun 3 19:04:10 1998 From: dgulbran at vervet.com (David Gulbransen) Date: Mon Jun 7 17:01:55 2004 Subject: Press Release: Vervet Logic Releases XML Pro v.1.0 In-Reply-To: <3.0.1.16.19980602231849.3a77a1b0@pop3.demon.co.uk> Message-ID: > [Posted for Murray Altheim] > >I looked over the press release and the online text describing your editor > >and found nothing about platform support (not even on the order form). Is > >it Java-based and hence runs on any platform? Thanks for pointing out that omission, we've corrected it on our site. To answer your questions, we currently are only shipping a Win32 exe of XML Pro. As some of you have pointed out, we do conduct our development with Java, and we _do_ have a 100% Java version available. However, because of some problems with Swing, we're not 100% confident in releasing the Java port just yet. We will consider licensing the Java version for volume purchases or site license, provided we can work with the customer to ensure compatibility and functionality. Thanks again for brining this up, not including it in the press release was an oversight on our part. Please do not hesitate to mail me if you have any other questions/concerns. -David David Gulbransen v e r v e t l o g i c President and CEO ----------------------- 812.856.5270 | fax 812.855.4506 http://www.vervet.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 3 20:00:50 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:55 2004 Subject: XSchema: multiple proposals References: <004d01bd8eee$58a06830$2ee044c6@arcot-main> Message-ID: <35755B3D.8C4FF6ED@locke.ccil.org> Don Park wrote: > Frankly, I would like to see separate definitions for each element, > attributes, and containment rules. I hated nested procedures in Pascal so I > hate having to define objects inside another definition. Same thing > happened with XSL where they mixed pattern definition and action rules > together so that patterns nor rules can't be shared. Hmm. The trouble with that is that either the related definitions have to remain together or they don't. If they do, then there's obvious structure within the XSchema that isn't being captured. If they don't, then we've introduced another level of cross-references. DTDs, of course, don't require the ATTLIST pertaining to an ELEMENT to be anywhere near it. Since at most one ATTLIST could exist per ELEMENT (at least in pre-Web-TC-SGML), can some SGML-knowledgeable person comment on the original rationale for separating ELEMENT from ATTLIST? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jun 3 20:13:10 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema: multiple proposals In-Reply-To: Message-ID: <3.0.1.16.19980603191218.831ffde2@pop3.demon.co.uk> At 18:31 02/06/98 UT, Simon St.Laurent wrote: [...] >I'd like this process to continue as a set of questions, followed by a >proposal incorporating the results of the questions. At the same time, I >think that drafts created by individuals can give us some valuable grounding >for those discussions, especially when we can compare and contrast them. I agree. Reading the proposals and the discussion on them today I felt that things were coming together well. Although there is a spectrum of opinion there seem to be no major ideological gulfs. I think Simon is doing a great job of pulling this together - it's very challenging because there are issues we haven't really discussed before. As always it's a dichotomy between simplicity and functionality. My personal touchstone would be that - at present - a newcomer to XML who has read the XML 1.0 spec and the namespace spec would have a reasonable chance of understanding our proposal. The closer that we map onto them, the easier it will be. Personally I am very happy with the general tenor of the drafts that have been offered. Have I got the process right, Simon - two (or more) drafts will be published and then you will ask questions which may use material from the drafts. E.g. "do you want NOTATIONs? - see draft 1 for example" - "do you want AttributeTypes as attributes? (e.g. draft 1) or as content? (draft 2)". P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jun 3 20:13:12 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:56 2004 Subject: Namespaces and Parsers In-Reply-To: <357548AB.3C76D5A7@technologist.com> References: <3.0.1.16.19980603095007.3a77930a@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980603191220.8897a696@pop3.demon.co.uk> At 08:59 03/06/98 -0400, Paul Prescod wrote: [...] > >XPointers, XSL, XSchema and most other XML processing specs will have to >be updated to be namespace aware. This should probably done in version 1.0 >of those specs. That explains the urgency of the namespace proposal. I am delighted to see this stated so cleanly and fully support it. The message is clear for XSchema - we can and must address namespaces. Fortunately I don't think it's too difficult. For the others I hope that this view filters through to the WGs :-). I agree with Paul that XPointer should have namespace aware components. For example, it's perfectly reasonable for someone to ask "are there any mathematical or chemical equations in this document?" At present they would have to search for descendant(1,MathML:EQN) or descendant(CML:REACTION) and *hope* that the authors had used 'common' prefixes. But this will assuredly break. So really they should be searching for (1,http://www.ams.org.MathML:EQN) or whatever. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jun 3 20:13:16 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema Question 3: Internal/External subsets In-Reply-To: <3575476A.3D849B16@technologist.com> References: <35746F2D.E79559CB@fiduciary.com> <3.0.1.16.19980603095052.45c778fa@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980603191122.8897c81c@pop3.demon.co.uk> At 08:54 03/06/98 -0400, Paul Prescod wrote: >Peter Murray-Rust wrote: >> >> My understanding is slightly different. The ns= is used to formalise the >> uniqueness and the 'ownership' of the namespace, e.g. xml.org.cml might >> create a global identifier for CML. The src= field does not necessarily >> have to point to the same document globally. > >I'm not sure what you mean here. A particular namespace declaration will >have zero or one srcdef, no matter where on the web it is accessed from. >Rick's point is that it should allow zero or more. I agree that a particular document can only have 0/1 srcDefs. However what I meant was that two documents using the same namespacename (ns=) might have different SrcDefs. In a trivial case this might be that one was a mirror of the other (e.g. behind a firewall). However it also seemed possible that there were functionally equivalent schemas (or perhaps even non-equivalent ones) that different documents could choose. One reason - as I hinted might be that the schema had to reference functionality expressed in a computer language and that people might wish to use different languages. Thus sites forbid Java but allow JavaScript (I make no comment on this policy). I can see that site 1 might use: while the other one might use This may also be constrained by the availability of various packages. For example, if you get a certain type of functionality in a file (e.g. a mathematical formula) you may not have a choice about your symbolic algebra package. This will also be true of chemistry. There will be a grey area between schemas and stylesheets, especially if processing is required. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecom.mixx.de Wed Jun 3 20:21:18 1998 From: James.Anderson at mecom.mixx.de (james anderson) Date: Mon Jun 7 17:01:56 2004 Subject: Namespaces and Parsers References: <3.0.1.16.19980603095007.3a77930a@pop3.demon.co.uk> Message-ID: <3575947A.8F567A8@mecom.mixx.de> Peter Murray-Rust wrote: > [lots about namespaces, including] > > There are some remaining problems: > > - unqualified names (i.e. prefix = null). Although I expect that in a > year's time almost all XML will be using namespaces, there will be chunks > which don't. Very often these will conform to a particular DTD (e.g. XHTML) > but without qualification. I therefore have a (slightly dangerous) > mechanism which I used in JUMBO1. It mapped all unqualified names to a > prefix of "#DEFAULT" (a deliberately illegal Name). This could then be > associated with a namespace either by an xml:namespace or through program > operation. The advantage of this is that it then gives the user a chance to > qualify their documents. > this is a deficiency in the draft. since you're dealing with "symbols" here (otherwise known as "universal names"), and all symbols belong in a package ( to adopt a view from lisp), you need a package for those symbols which do not themselves name a package. it appears that you've been naming that package "#DEFAULT" and maintaining it as a constant. if you go ahead and make it a first class value rather than a special case, then there's no reason you can't bind any package to that prefix name. as soon as the namespace spec provides a syntax for that operation, the problem disappears. for my use i've just permitted the pi to contain "zero or one" prefix, with zero meaning the namespace/package for names/symbols without prefixes. bye for now, xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 3 20:24:59 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema: New draft of John Cowan's proposal Message-ID: <357594B7.E555C044@locke.ccil.org> The new URL is at http://www.ccil.org/~cowan/XSchema-draft-19980603.html . Note that the DTD and meta-XSchema are now in separate resources, and the main body is HTML (or actually XHTML; my apologies to anyone who doesn't like tags). Changes include adopting the ID/IDREF model, renaming NAME to REF, splitting off ENUM from VALUE (for use in ENUMTYPE elements), using an attribute for *, ?, and + rather than elements, forbidding SEQ within SEQ and CHOICE within CHOICE, getting NOTATION attributes represented. Still to be dealt with: namespaces, embedded doco in XSchemas, how to declare an XSchema. In addition, the meta-XSchema has been validated by nsgmls 1.3. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 3 20:32:34 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema: multiple proposals References: <199806031121.NAA04198@berlin.dvs1.tu-darmstadt.de> <357569FA.5AD780D5@locke.ccil.org> Message-ID: <35759688.23945A44@locke.ccil.org> Toby Speight wrote: > Hmm. I see your point. I think what I dislked about Ron's proposal > is the unconstrained #PCDATA here: > > Ron> > Ron> > > I think that the list-of-elements structure can be retained, but with > tighter constraints by writing > > > > > > > > > That's what my draft does wrt enumerations. I have more problems with notations, because it doesn't make sense to me to have to redeclare every notation name with every notation attribute, since any notation attribute can refer to any notation name. Thus I treat notation attributes like other attributes with predefined types. > John> Now that is an excellent idea! However, it would be necessary > John> to permit arbitrary XML markup within the doco, so a content > John> model of ANY is probably the right thing here. > > I'd like to agree at least some conventions here, but I think we > should defer the details until later. For the moment, I think we > should concentrate on *where* we can put documentation. Agreed. I'll think about it. > With IDREF, we could keep the documentation separated from the schema, but > I'm a follower of the theory which says that the closer the documentation > is to the code, the more likely they are to correspond. I think that's best also. > I don't think this is really workable. We don't have SUBDOC in XML, > nor do we have anywhere in the XSchema DTD that we can insert another > tree rooted at XSchema. For me it would be easy to add DOCTYPE (my root type) as another top-level type co-ordinate with ELEMENT, ENTITY, and NOTATION. > Even if the mechanics can be made to work, > I'm concerned about ID clashes. Can namespaces help prevent this? Yes, particularly if there were some way to say "Colon-free names brought in from this schema have an implicit 'ns' of xxxxx". > I'm not convinced about wanting only to link-in whole XSchemas, either: > it seems to me that lots of people would want P[aragraph] (and its > children) from HTML, for instance. I'll consider that. But linking in HTML4.0:P brings in a lot of baggage, specifically its content model, which includes virtually every other HTML body tag. I suspect that DTDs (and, a fortiori, XSchemas) tend to be far more closely interwoven than people really suspect. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jun 3 20:43:24 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema: New draft of John Cowan's proposal In-Reply-To: <357594B7.E555C044@locke.ccil.org> Message-ID: <3.0.1.16.19980603194234.78d793c0@pop3.demon.co.uk> At 14:23 03/06/98 -0400, John Cowan wrote: >The new URL is at http://www.ccil.org/~cowan/XSchema-draft-19980603.html . >Note that the DTD and meta-XSchema are now in separate resources, Excellent - many thanks for this work. The meta-schema seems to have a broken link. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.Sun.COM Thu Jun 4 01:50:42 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: <3.0.1.16.19980602222036.3dff83b0@pop3.demon.co.uk> (message from Peter Murray-Rust on Tue, 02 Jun 1998 22:20:36) Message-ID: <199806032348.QAA01353@boethius.eng.sun.com> [Peter Murray-Rust:] | Jon Bosak very kindly let us use xml.org for the SAX spec. I suspect that | Jon may regret that :-). It certainly would fit the bill for the ns here. Actually, I already regret it. There has to be some kind of process for deciding whether something rates use of the xml.org domain, and the fact is that I don't have time to do this myself. I believe that I am going to end up delegating this somewhere; please do me a favor and avoid using xml.org for a little bit until I figure out the best way to handle this. Jon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Jun 4 01:56:17 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema: multiple proposals Message-ID: Peter Murray-Rust wrote: >Reading the proposals and the discussion on them today I felt that >things were coming together well. Although there is a spectrum of opinion >there seem to be no major ideological gulfs. So far, we've pretty much avoided ideological gulfs. The two proposals (from John Cowan and Ron Bourret) are different, but I think we have the parts to define the basic structures, and then move on to other issues including the documentation features and other goodies. I'm very pleased by both drafts, and think we have a rich set of material to work with. >As always it's a dichotomy >between simplicity and functionality. My personal touchstone would be that >- at present - a newcomer to XML who has read the XML 1.0 spec and the >namespace spec would have a reasonable chance of understanding our >proposal. The closer that we map onto them, the easier it will be. That's my aim - and I'd like to make sure that they don't have to flip back and forth constantly among all the specs. This probably means a lot of work for me, but that's fine. I'm used to writing tutorials and manuals, so it's normal for me. >Have I got the process right, Simon - two (or more) drafts >will be published and then you will ask questions which may use material >from the drafts. This is almost exactly right. I'll be building an initial XSchema specification using material from these two drafts (and others that may be submitted), taking into account the discussions surrounding them on the list. Tomorrow I'll be taking a line-by-line look at the two drafts to compile a list of more detailed questions. *Content models appear to be the current zone of most contention.* As the discussion evolves, the specification will go through multiple numbered drafts. All released versions of the spec will remain available on the XSchema site (http://purl.oclc.org/NET/xschema) for reference. I'll have an outline for the specification up tomorrow sometime, to double-check that I haven't forgotten any critical portions. Also, if there are portions of the spec that people would like to 'adopt,' I'm open to collaborating, though I'll keep some editorial control over the spec as a whole. We can work this out after the outline settles. (Contact me privately if you're interested.) Thanks to _everyone_ for their participation. I am keeping a list of everyone who's joined the fun, and there will certainly be an _enormous_ acknowledgments on this one. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jun 4 01:58:25 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema: multiple proposals In-Reply-To: <35759688.23945A44@locke.ccil.org> References: <199806031121.NAA04198@berlin.dvs1.tu-darmstadt.de> <357569FA.5AD780D5@locke.ccil.org> Message-ID: <3.0.1.16.19980604003743.87476faa@pop3.demon.co.uk> At 14:31 03/06/98 -0400, John Cowan wrote: [...] > >> John> Now that is an excellent idea! However, it would be necessary >> John> to permit arbitrary XML markup within the doco, so a content >> John> model of ANY is probably the right thing here. >> >> I'd like to agree at least some conventions here, but I think we >> should defer the details until later. For the moment, I think we >> should concentrate on *where* we can put documentation. > >Agreed. I'll think about it. > >> With IDREF, we could keep the documentation separated from the schema, but >> I'm a follower of the theory which says that the closer the documentation >> is to the code, the more likely they are to correspond. > >I think that's best also. This is critical, I think, for ease of authoring, readability, maintenance and building programs. If we achieve nothing else, the formal linking of documentation to XSchema/DTD components will be invaluable. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.Sun.COM Thu Jun 4 02:02:16 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: <3.0.1.16.19980602222026.3b1ffeb0@pop3.demon.co.uk> (message from Peter Murray-Rust on Tue, 02 Jun 1998 22:20:26) Message-ID: <199806032359.QAA01358@boethius.eng.sun.com> [Peter Murray-Rust:] | - although there is no formal process, we have been informed | several times of potential developments by the W3C which helped guide | our activities. For example, JonB notified us of the change of | caseSensistivity and also of the major revision in XSL. If we were | doing something utterly foolish here I would expect that we would pick | up some gentle hints. I have very mixed feelings about this thread (which I don't have time to follow in detail). On the one hand, what you are engaged in here is, strictly speaking, wasted motion; the XML WG will define the standard for schemas, and the probability is high that it will use at best just a little bit of what you come up with as input. On the other hand, some of the discussion here may turn out to be quite useful. I don't have a problem with seeing it continue as long as you understand that very little of what you do may end up in the final specification. I'm a lot less bothered by the fact that this work is going on than I am by the fear that the participants will be distracted from putting any energy into XML/XSL browser implementations when the first XSL draft becomes available next month. Jon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Thu Jun 4 05:51:27 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema and namespaces In-Reply-To: <357545D4.869B2E2A@technologist.com> Message-ID: <199806040353.AA01325@murata.apsdc.ksp.fujixerox.co.jp> Paul Prescod wrote: > > I agree. Nobody from the WG has commented publically or privately on the > issue yet. (hint, hint) I repeatedly did in the XML SIG. http://lists.w3.org/Archives/Member/w3c-xml-sig/1998Mar/0029.html http://lists.w3.org/Archives/Member/w3c-xml-sig/1998Mar/0025.html Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Jun 4 12:22:25 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:01:56 2004 Subject: Reusing/referencing partial XSchemas (was: XSchema: multiple ...) In-Reply-To: John Cowan's message of "Wed, 03 Jun 1998 14:31:36 -0400" References: <199806031121.NAA04198@berlin.dvs1.tu-darmstadt.de> <357569FA.5AD780D5@locke.ccil.org> <35759688.23945A44@locke.ccil.org> Message-ID: John> John Cowan => In article <35759688.23945A44@locke.ccil.org>, John wrote: John> ... linking in HTML4.0:P brings in a lot of baggage, specifically John> its content model, which includes virtually every other HTML body John> tag. Well, it excludes UL/OL/etc, DIV, and Hn, for a start. But I think HTML was a bad choice of example on my part (and it's not even XML!). -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Jun 4 13:06:01 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:01:56 2004 Subject: XSchema: New draft of John Cowan's proposal In-Reply-To: John Cowan's message of "Wed, 03 Jun 1998 14:23:51 -0400" References: <357594B7.E555C044@locke.ccil.org> Message-ID: John> John Cowan => In article <357594B7.E555C044@locke.ccil.org>, John wrote: John> The new URL is at John> . John> John> Changes include adopting the ID/IDREF model, renaming NAME to REF, John> splitting off ENUM from VALUE (for use in ENUMTYPE elements), using John> an attribute for *, ?, and + rather than elements, forbidding SEQ John> within SEQ and CHOICE within CHOICE, getting NOTATION attributes John> represented. I like the changes; no argument here. [I cheated by reading only the DTD; I assume the prose is similar to that of XSchema-draft-19980601] I'm not sure if the name "VALUE" for the default value of an attribute is the clearest possible: John> For somebody reading an actual Xschema, it might be assumed that VALUE represented a fixed, rather than default, value - particularly if FIXED never occurs in that particular Xschema. Would FIXEDVALUE and DEFAULTVALUE be better names for FIXED and VALUE? Another issue which different people will have different opinions on is the content of the DOCTYPE element - instead of having freely mixable content of (ELEMENT|ENTITY|NOTATION)*, it might be better to enforce the grouping of declarations: (NOTATION*, ENTITY*, ELEMENT*). What do other people think? John> Still to be dealt with: ..., embedded doco in XSchemas, ... Can I have a first cut at this? Do individual ENUM values need documenting? Or is it sufficient to have the DOC in ATT describe them? Do entities and notations need documentation? A final comment, on conformance: should valid documents having a DTD which uses the XSchema DTD as a base architecture be considered conformant? Or should we insist that only the results of architectural forms processing can qualify? (Using architectural forms means that an internal subset may be used if it is compatible with the base architecture. Incidentally, I think an internal subset should be allowed in conforming XSchema documents, if it contains only general entity definitions (and notations?); as it is, entities must be expanded.) -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 4 15:06:09 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:57 2004 Subject: XSchema: New draft of John Cowan's proposal In-Reply-To: <3.0.1.16.19980603194234.78d793c0@pop3.demon.co.uk> from "Peter Murray-Rust" at Jun 3, 98 07:42:34 pm Message-ID: <199806041341.JAA16755@locke.ccil.org> > Excellent - many thanks for this work. *blush* > The meta-schema seems to have a broken link. Fixed. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 4 15:41:26 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:57 2004 Subject: XSchema: New draft of John Cowan's proposal In-Reply-To: from "Toby Speight" at Jun 4, 98 12:05:47 pm Message-ID: <199806041416.KAA17908@locke.ccil.org> Toby Speight wrote: > I'm not sure if the name "VALUE" for the default value of an attribute > is the clearest possible: > > John> > > For somebody reading an actual Xschema, it might be assumed that VALUE > represented a fixed, rather than default, value - particularly if > FIXED never occurs in that particular Xschema. Would FIXEDVALUE and > DEFAULTVALUE be better names for FIXED and VALUE? Doubtless they would. The name VALUE was an attempt to compromised between "default value" and "enum name", which latter is now ENUM. So VALUE can be changed. I'm also wondering if this mightn't now be a case for an attribute instead of a bunch of empty elements. One problem with XML is that there's no way to say "Attribute B is #REQUIRED iff Attribute A has value 'foo'". > Another issue which different people will have different opinions on > is the content of the DOCTYPE element - instead of having freely > mixable content of (ELEMENT|ENTITY|NOTATION)*, it might be better to > enforce the grouping of declarations: (NOTATION*, ENTITY*, ELEMENT*). How Pascal-ish! No, I think it's better to be freely able to associate things that go together in linear order. Indeed, I'm thinking that XSchemas should have structure, allowing DOCTYPE to be an element. I had discussed this yesterday wrt embedding external XSchemas, but it would also be useful for indicating sub-schemas, rather than just a rag-bag of declarations. In the meta-XSchema, e.g., there would probably be separate subschemas for ELEMENT and friends, ATT and friends, ENTITY, and NOTATION. > > I still think that ANY is the right thing, so that arbitrary markup (XHTML or XTEI or whatever) can be used here. > > > These look good. > Do individual ENUM values need documenting? Or is it sufficient to > have the DOC in ATT describe them? I would say yes, they should allow documentation, for modularity. > Do entities and notations need documentation? Surely! One purpose of documentation is to describe *purpose*, and understanding a notation will often require knowing its purpose: not everybody knows what "PERL5.x" means, still less "RipScrip2.0". > A final comment, on conformance: should valid documents having a DTD which > uses the XSchema DTD as a base architecture be considered conformant? Or > should we insist that only the results of architectural forms processing > can qualify? (Using architectural forms means that an internal subset may > be used if it is compatible with the base architecture. I can't comment, as I don't understand architectural forms. Can you give a simple concrete example? > Incidentally, I > think an internal subset should be allowed in conforming XSchema documents, > if it contains only general entity definitions (and notations?); as it is, > entities must be expanded.) Hmm. Good point. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Thu Jun 4 16:12:48 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:01:57 2004 Subject: Uniqueness of notations Message-ID: <199806041410.QAA10463@berlin.dvs1.tu-darmstadt.de> The MSXML parser flags duplicate notation names as an error. This seems quite reasonable to me, but I can't find it anywhere in the spec. Which is correct, and if duplicate notation names are allowed, which is used? -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Jun 4 16:17:10 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:01:57 2004 Subject: XSchema: New draft of John Cowan's proposal In-Reply-To: John Cowan's message of "Thu, 4 Jun 1998 10:16:50 -0400 (EDT)" References: <199806041416.KAA17908@locke.ccil.org> Message-ID: John> John Cowan => In article <199806041416.KAA17908@locke.ccil.org>, John wrote: John> One problem with XML is that there's no way to say "Attribute B John> is #REQUIRED iff Attribute A has value 'foo'". Yes. This is why I like your use of elements for specifying defaulting of attributes. My vote is keep it. >> instead of having freely mixable content of (ELEMENT|ENTITY|NOTATION)*, >> it might be better to enforce the grouping of declarations: (NOTATION*, >> ENTITY*, ELEMENT*). John> How Pascal-ish! John> No, I think it's better to be freely able to associate things John> that go together in linear order. I can't remember (nor find easily in the spec) whether notations must be declared before use. If so, then I think we should consider echoing that constraint, to simplify conversion to DTD. Apart from that consideration, I have no preference (and it's easy to transform the document algorithmically, if required). John> Indeed, I'm thinking that XSchemas should have structure, ... Sorry, you lost me with this paragraph. Can you illustrate it with an example? >> >> John> I still think that ANY is the right thing, so that arbitrary John> markup (XHTML or XTEI or whatever) can be used here. I'm not keen on arbitrary markup, because I'm interested in processing the documentation with DSSSL to give a pretty-printed human-readable document to go with the DTD. It's hard to do that if you don't know what elements to expect. And, as I mentioned, we'll want some XSchema-specific elements to refer to ELEMENT definitions (for example). >> Do individual ENUM values need documenting? Or is it sufficient to >> have the DOC in ATT describe them? John> I would say yes, they should allow documentation, for modularity. >> Do entities and notations need documentation? John> Surely! One purpose of documentation is to describe *purpose*, and John> understanding a notation will often require knowing its purpose: John> not everybody knows what "PERL5.x" means, still less "RipScrip2.0". Okay; adding DOC to ENTITY is trickier than the other cases, since its content-model is #PCDATA - actually, the more I think about it, the more difficult it seems to treat internal and external entities the same: Documenting NOTATION is trivial. >> A final comment, on conformance: should valid documents having >> a DTD which uses the XSchema DTD as a base architecture be >> considered conformant? Or should we insist that only the >> results of architectural forms processing can qualify? (Using >> architectural forms means that an internal subset may be used >> if it is compatible with the base architecture. John> I can't comment, as I don't understand architectural forms. Can John> you give a simple concrete example? Not really - I think there are other people on this group who are more qualified than I to do that. I've only used architectural forms to create DSSSL documents, and that was very much a trial-and-error process. But my motivation stems from the fact that DSSSL documents must only satisfy the architectural form; this enables individual (derived) DTDs to use e.g. their own names for the elements (perhaps in an author's native tongue), but prevents internal subset extensions from changing the allowed model. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From singba at msr.epm.ornl.gov Thu Jun 4 16:47:13 1998 From: singba at msr.epm.ornl.gov (singba) Date: Mon Jun 7 17:01:57 2004 Subject: XML / XSL Disparity Message-ID: <3576B2E8.B67AE723@msr.epm.ornl.gov> I am writing a very simple, Java based, search engine for XML documents. I commonly use XSL for presentation of my XML documents. I find that it is useful to modify or add to the contents of the XML using XSL for presentation purposes. Are there any provisions for allowing a user to search for what they see and get the correct document/view using a general purpose search engine? Obviously, one can not just search the XML file. As an example, imagine a date stored as 19980604 in an XML file. An XSL file converts that to 06-04-1998 for presentation. The user writes that date down and later searches for it but.... Any advice is appreciated. Thanks, Brad Singletary Center For Collaborative Technologies Research Oak Ridge National Laboratory xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Jun 4 17:16:37 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:57 2004 Subject: Namespaces and PURLs Message-ID: Although this comes from the XSchema proposal, it's a more general question about namespaces. For the 5/18 draft >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). This sounds like I can use a PURL (see http://www.purl.org for details) as a URI in a namespace declaration. They are unique and persistent, assuming the OCLC doesn't disappear any time soon. They are retrievable, though with a hitch - the OCLC sends a redirect to the 'actual' location to which the PURL refers. That location may change, though the PURL doesn't. (The same holds true for domain names, but the mechanisms are more commonly understood and implemented at a lower level.) Does the "it is not a goal" language mean that I can use a PURL, or should I stay away from doing so because some applications may be unable to handle an attempted resolution of (and redirection from) that URL? Applications don't appear to be prohibited from such retrieval; it's just not a goal that they do retrieve. Several others on the list have commented about possible useful things to put at the end of a namespace URI, so I'm a little concerned. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Jun 4 18:11:38 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:01:57 2004 Subject: Namespaces and PURLs In-Reply-To: "Simon St.Laurent"'s message of "Thu, 4 Jun 98 15:15:13 UT" References: Message-ID: Simon> Simon St.Laurent => In article , Simon => wrote: Simon> Does the "it is not a goal" language mean that I can use a PURL, Simon> or should I stay away from doing so because some applications may Simon> be unable to handle an attempted resolution of (and redirection Simon> from) that URL? Applications don't appear to be prohibited from Simon> such retrieval; it's just not a goal that they do retrieve. Redirections may be a problem for Java applets, if the security policy doesn't allow them. But that only matters for resources which must be retrieved. The important thing about the URI for a namespace is that it is unique. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Thu Jun 4 18:14:24 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:01:57 2004 Subject: John replies to Ron: Differences Message-ID: <199806041610.SAA11550@berlin.dvs1.tu-darmstadt.de> John Cowan writes: > Ron Bourret writes: > > > To indicate a PCDATA-only element, I use a PCData element while John > > uses an empty MIXED element. Although the PCData element is not > > strictly necessary, I think the commonality of PCDATA-only content > > makes it useful. > > I was thinking that PCDATA-only content is not so common. Most of > the time, textual elements contain fancy-text information like bold, > italic, or whatever. Pure plain text with no markup allowed probably > makes the most sense in title elements and such. Content models of PCDATA and EMPTY represent the terminals in DTDs. That is, bold, italic, etc. have a PCDATA content model. Furthermore, in more data (as opposed to document) applications of XML, PCDATA-only content seems to be relatively common. For the moment, I have left PCData in and required Mixed to take at least one ElementRef, per your earlier suggestion. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Thu Jun 4 18:23:00 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:01:57 2004 Subject: XSchema: Notation attributes (was Re: XSchema: multiple proposals) Message-ID: <199806041616.SAA11609@berlin.dvs1.tu-darmstadt.de> John Cowan wrote: > Toby Speight wrote: > > > Hmm. I see your point. I think what I dislked about Ron's proposal > > is the unconstrained #PCDATA here: > > > > Ron> > > Ron> > > > > I think that the list-of-elements structure can be retained, but with > > tighter constraints by writing > > > > > > > > > > > > > > > > That's what my draft does wrt enumerations. I have more problems > with notations, because it doesn't make sense to me to have to > redeclare every notation name with every notation attribute, > since any notation attribute can refer to any notation name. > Thus I treat notation attributes like other attributes with > predefined types. I'm not sure what you mean by redeclaring every notation name with every attribute. In the above structure, the notation value is simply a NMTOKEN. Why would I need to redeclare notation names? Are you thinking that the NotationValue attribute is an enumerated (not NMTOKEN) attribute? -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jun 4 18:27:17 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:57 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: <199806032359.QAA01358@boethius.eng.sun.com> References: <3.0.1.16.19980602222026.3b1ffeb0@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980604172602.8ca793e4@pop3.demon.co.uk> Many thanks for taking time to write, Jon At 16:59 03/06/98 -0700, Jon Bosak wrote: >[Peter Murray-Rust:] > >| - although there is no formal process, we have been informed >| several times of potential developments by the W3C which helped guide >| our activities. For example, JonB notified us of the change of >| caseSensistivity and also of the major revision in XSL. If we were >| doing something utterly foolish here I would expect that we would pick >| up some gentle hints. > >I have very mixed feelings about this thread (which I don't have time >to follow in detail). On the one hand, what you are engaged in here >is, strictly speaking, wasted motion; the XML WG will define the >standard for schemas, and the probability is high that it will use at >best just a little bit of what you come up with as input. On the >other hand, some of the discussion here may turn out to be quite >useful. I don't have a problem with seeing it continue as long as you >understand that very little of what you do may end up in the final >specification. I think we all agree that it is - strictly speaking - 'wasted motion' in formal W3C terms. I see what we are doing rather as the 'research' department of a company where we do not have to produce a product for the market, but can address things that may have value in their own right or may provide useful experience. The goal is to have something by the end of the month which will be simple, implementable and provide something useful that isn't currently available. If it's throw-away in 6 months none of those involved are going to lose sleep. My motivation is the following: - I need something now. I had to have a 'schema' for CML under JUMBO1. I need to rewrite it because of the change in namespaces - NB I *expect* things to break because of spec changes :-). So if I can use this to build the next phase of CML software (which is also due for revision) it saves me time and effort. When the full schema draft is available I will have to decide whether it addresses the needs of the chemical community :-) - It allows me to do generic things that I can't otherwise do. These include: editing a DTD documenting a DTD (I have horrible problems at present getting machine-readable documentation out of a DTD) controlling an editor with (part of) a DTD. - It is a valuable project for the XML-DEV community. Simon has commented on the large number of people who have corresponded with him. I have no idea whether any/many are W3C members, but it seems that people are happy to help create something here. Assuming we are *technically* successful, that helps build up a virtual community which knows how to tackle problems in a virtual manner. In that respect I feel the current membership is rather special :-). - It makes me faster at implementing the next step - whatever that is. > >I'm a lot less bothered by the fact that this work is going on than I >am by the fear that the participants will be distracted from putting >any energy into XML/XSL browser implementations when the first XSL >draft becomes available next month. I would hate to think we were diverting mainstream activity - and unless there is evidence otherwise I doubt that we are. I'd like to think that we are adding to the communal resources by creating an arena where ideas and components are potentially valuable and re-usable. Personally there is no way that *I* can tackle the current XSL spec since the requirements are quite outside my capability even to comprehend :-) There is a very large emphasis on typography - implementing XSL requires it to have the functionality of TeX as a subset. What concerned me about the XSL spec - and I don't have any formal input into it - is that there was very little support for anything other than paper/screen-image rendering. IOW it doesn't appear to support interactive processes such as buttons, etc. [this may be hidden in the details]. To this extent I feel that to support a very different domain - molecular science - where paper is not necessarily the prime focus, we shall have to develop our own tools on top of the XML specs. I see the current XSchema project as being useful for that. An additional point is that there is a requirement for some of us for XML transformations/patterns/rules etc. to be used outside the XSL framework. My understanding was that the W3C was not addressing this other than in an XSL context. For example some of us need the 'pattern' stuff from XSL (at least the last draft) but not the formatting/rendering - the output might go to a chemical robot for example. I don't think that this alters the informal relation between XML-DEV and the formal W3C processes. Since a member of a W3C group felt sufficiently strongly about our activities that it led to voluminous (and unacceptable) personal abuse I felt I should explore whether there were more general concerns. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Thu Jun 4 19:31:35 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:01:57 2004 Subject: New release of XSchema DTD proposal Message-ID: <199806041730.TAA11908@berlin.dvs1.tu-darmstadt.de> Thanks to John's and Toby's comments, I have updated my proposed DTD. I made the following changes: * Renamed idref attributes as appropriate (Element, RootElement, etc.) * Changed the id attribute on to RootElement (type IDREF) and declared in the XML version (oops) * Removed Choice as a direct child of Choice and Seq as a direct child of Seq * Added general entities and notations * Allowed to be empty (models an empty DTD) * Changed to be an empty element with a Notation attribute (type IDREF) * Changed to be an empty element with a Value attribute (type NMTOKEN) * Changed the content model of Mixed from (ElementRef*) to (ElementRef+) The URL is still the same: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xschema.html Tomorrow I'll try to hash out a list of differences (aside from naming) between John's and my DTDs. This should allow us to raise issues and create a single DTD. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jriedese at jnana.com Thu Jun 4 19:38:24 1998 From: jriedese at jnana.com (Joel Riedesel) Date: Mon Jun 7 17:01:57 2004 Subject: ANNOUNCE: Virtual Hyperglossary (VHG) DTD 1.0 alpha In-Reply-To: <3.0.1.16.19980529083324.37074526@pop3.demon.co.uk> Message-ID: <01e801bd8fdf$4ce3abf0$0132fac1@ipusushi> Preface: I'm using this vhg.dtd to test out some work we're doing with parsing out the DTD and using that to allow authors to reference data in documents that use that DTD (and subsequently be able to reason upon that data). DTD Parsing Assumption: I had made an assumption (probably quite incorrectly) that there would only be element in the DTD that wasn't referenced by other elements and therefore I would use that element as my "top" element. Question: This vhg.dtd has a locatorLink that is not referenced by any other element in the DTD. The semantics of extendedLink say that it will always contain locatorLink elements, but the DTD for extendedLink doesn't actually state that. So... somewhat obviously, I end up with the locatorLink as my top element. Oops. (Looks like I need to at least provide for the possibility of multiple top elements and let our author choose the correct one.) Is this type of DTD practice in any way standard? It sure feels a bit messy to define things this way (makes it tough to use the DTD by another program and actually automate XML things...). If the authors of the VHG.dtd find the need to define things this way, is that due to a current limitation of DTDs in general? Feel free to correct any misunderstanding I may have (which I won't be at all surprised about). Thanks. > > The VHG (Virtual Hyperglossary) is a simple but powerful approach for > supporting semantics and terminology using XML technology. The first > publicly available DTD (with documentation and examples) is at: > http://www.vhg.org.uk > and > http://www.vhg.org.uk/dtd > --- Joel Riedesel Jnana Technologies Corporation http://www.jnana.com mailto:jriedese@jnana.com 303 805 8275 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Jun 4 20:03:28 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:01:57 2004 Subject: XSchema: Notation attributes In-Reply-To: rbourret@dvs1.informatik.tu-darmstadt.de's message of "Thu, 4 Jun 1998 18:16:04 +0200" References: <199806041616.SAA11609@berlin.dvs1.tu-darmstadt.de> Message-ID: Ron> Ron Bourret => In article <199806041616.SAA11609@berlin.dvs1.tu-darmstadt.de>, Ron => wrote: Ron> John Cowan wrote: >> I have more problems with notations, because it doesn't make sense >> to me to have to redeclare every notation name with every notation >> attribute, since any notation attribute can refer to any notation >> name. Thus I treat notation attributes like other attributes with >> predefined types. Ron> I'm not sure what you mean by redeclaring every notation name Ron> with every attribute. In the above structure, the notation value Ron> is simply a NMTOKEN. Why would I need to redeclare notation Ron> names? Are you thinking that the NotationValue attribute is an Ron> enumerated (not NMTOKEN) attribute? I think the confusion is caused by my misunderstanding. From your DTD: Ron> Ron> Ron> Notation IDREF #REQUIRED> In particular, NotationType contains a list of Notation values. Why? What's wrong with the following? -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From adamanm at sbu.ac.uk Thu Jun 4 20:25:42 1998 From: adamanm at sbu.ac.uk (Marios Adamantopoulos) Date: Mon Jun 7 17:01:57 2004 Subject: New Kid on the block... References: <199806041616.SAA11609@berlin.dvs1.tu-darmstadt.de> Message-ID: <3576E866.CDEC6CD5@sbu.ac.uk> Hi all well I'm a beginner with XML so if anyone could give me any hints, it would be GREAT!!! I'm going to do my final year project in XML( Metadata probably) but I would like to learn a few things first. So if anyone knows where to get an XML editor and any other hints, or web addresses or books , please tell me... Thanks Mario-Mr.Blue xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 4 20:29:22 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:58 2004 Subject: John replies to Ron: Differences References: <199806041610.SAA11550@berlin.dvs1.tu-darmstadt.de> Message-ID: <3576E737.A13B63A@locke.ccil.org> Ron Bourret wrote: > Content models of PCDATA and EMPTY represent the terminals in DTDs. True, but not all data models have finite expansion. HTML does not, e.g. > That is, bold, italic, etc. have a PCDATA content model. Not typically. More likely, each would have a mixed model so that we can handle italic within bold and vice versa. 7A separate BI element could do that job otherwise, but that leads to a combinatorial explosion when there are six or seven appearance tags. > Furthermore, in more data (as > opposed to document) applications of XML, PCDATA-only content seems to be > relatively common. Perhaps true. But maybe that's a historical artifact due to there being no standard way to express rich text within databases. > For the moment, I have left PCData in and required Mixed to > take at least one ElementRef, per your earlier suggestion. Okay. BTW, it occurred to me today that SEQ and CHOICE (using my terminology) should be compelled to have at least two children, with content models Otherwise, we have all with the same meaning. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Thu Jun 4 20:51:10 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:01:58 2004 Subject: New Kid on the block... In-Reply-To: <3576E866.CDEC6CD5@sbu.ac.uk> Message-ID: <000501bd8fea$01d3aa10$94bc38cb@NT.JELLIFFE.COM.AU> > From: Marios Adamantopoulos > So if anyone knows where to get an XML editor and any other hints, or web > addresses > or books , please tell me... My book "The XML & SGML Cookbook" has just been released last week. (Actually, it sold out on the first day, I believe, but it is being reprinted.) It is not a first book on XML (i.e. on syntax), but it has a lot of hard-to-find material that is not covered anywhere else. It is certainly worthwhile looking at, or getting your library to order. Note: At least one major online company has put it under the keyword "cooking", so you may have to look for "Jelliffe"; some book shops have it under the name "The SGML Cookbook" which was the working title when I started it 2 years ago. Simon St Laurent, who also is on this list, has a good introductory book. There is a flood of XML books coming: it is very exciting. The best version of the XML specification available online is the annotated one at www.xml.com (See Features: Annotated XML at the left) Rick Jelliffe ========================================================== The XML & SGML Cookbook, by Rick Jelliffe Charles F. Goldfarb Series on Open Information Management 656 pages + CD-ROM, Prentice Hall 1998, ISBN 0-13-614233-0 http://www.sil.org/sgml/jelliffeXMLAnn.html http://www.phptr.com/ > Book Search > "Jelliffe" http://www.amazon.com/exec/obidos/ASIN/0136142230/002-4102466-3352420 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From thompson at roguewave.com Thu Jun 4 20:53:02 1998 From: thompson at roguewave.com (Patrick Thompson) Date: Mon Jun 7 17:01:58 2004 Subject: OSD? Message-ID: <199806041852.LAA18621@cvo.roguewave.com> Can anybody tell me the status of the Open Software Description (OSD) proposal from Microsoft and Marimba? Is this proposal being actively pursued by the W3C? What is the process? I am working on an OMG proposal for CORBA components and am interested in using XML, and possibly OSD, for packaging. Any insights would be appreciated. -Patrick --- Patrick Thompson Rogue Wave Software, Inc. ph. 541 754 3189 patrick@roguewave.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 4 20:56:17 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:58 2004 Subject: XSchema: Notation attributes References: <199806041616.SAA11609@berlin.dvs1.tu-darmstadt.de> Message-ID: <3576ED82.778C2BBC@locke.ccil.org> Blunderingly I wrote: > > That's what my draft does wrt enumerations. I have more problems > > with notations, because it doesn't make sense to me to have to > > redeclare every notation name with every notation attribute, > > since any notation attribute can refer to any notation name. > > Thus I treat notation attributes like other attributes with > > predefined types. > > I'm not sure what you mean by redeclaring every notation name with every > attribute. In the above structure, the notation value is simply a NMTOKEN. Why > would I need to redeclare notation names? Are you thinking that the > NotationValue attribute is an enumerated (not NMTOKEN) attribute? No, I was muddled about notation attributes. Until today I did not grasp that a specific notation attribute can only assume the value of one of the notations defined for it, so my remark above ("any notation attribute can refer to any notation name") is false, if "any notation name" is understood as "the name of any notation declared in the DTD". Consequently, my draft is simply in error in treating NOTATION on a par with ID, IDREF, ENTITY, .... -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 4 21:02:08 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:58 2004 Subject: Namespaces and PURLs References: Message-ID: <3576EED7.A4EC09DC@locke.ccil.org> Simon St.Laurent wrote: > This sounds like I can use a PURL (see http://www.purl.org for details) as a > URI in a namespace declaration. They are unique and persistent, assuming the > OCLC doesn't disappear any time soon. Clearly so. > Does the "it is not a goal" language mean that I can use a PURL, or should I > stay away from doing so because some applications may be unable to handle an > attempted resolution of (and redirection from) that URL? Any application that purports to understand HTTP URLs can handle redirection, since that has been part of HTTP since the beginning. And an application that purports to understand *any* URLs is extremely likely to understand HTTP URLs. > Applications don't > appear to be prohibited from such retrieval; it's just not a goal that > they do retrieve. More to the point: 1) There may be nothing to retrieve. 2) Applications should not assume that anything that is retrievable is in any way a machine-readable schema. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 4 21:19:07 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:58 2004 Subject: Namespaces: Biting The Bullet Message-ID: <3576F2C0.9F66E617@locke.ccil.org> In order to satisfy Goal 8 of the XSchema effort, it will be necessary for XSchemas to have some explicit way of encoding namespaces. The natural approach will be Except for casing, there should be no real dispute over that. Now, the real issue: why is a namespace element required, separate and distinct from the namespace PI? Fundamentally, because XSchemas (unlike DTDs) are not structurally part of the document they describe. Therefore, they may well have their own separate and distinct namespace PIs. Here's an example XSchema (using my syntax): What that says, in essence, is that the element GIs (and implicitly the attribute names as well) *used* in the XSchema come from the namespace "http://blather.com/blather", whereas the element names *mentioned* come from "http://plaintext.com/whatever". A document instance conforming to this XSchema may then begin: and then a namespace-aware XSchema-based validator will know that any elements called "T:P" in the document instance has the properties of the element called "TEXT:P" in the XSchema, since the namespace names agree. In principle, the same effect could be achieved by putting actual namespace PIs into the XSchema, since a namespace PI, like any other PI, is passed along to the application (in this case, an XSchema validator application). However, this is contrary to the spirit of XSchema, which is to express everything using element/attribute syntax. Furthermore, the use of actual namespace PIs would license an XML parser to pass through elements and attributes tagged with those prefixes, whereas the prefixes should appear in the XSchema only within attribute values, where they are hidden from the XML parser. XSchemas may well need other namespace PIs of their own. For example, if a DOC element contains other elements to indicate formatting, these presumably come from some namespace other than the XSchema namespace. If so, a PI will be in order to declare that namespace and some prefix for it. If the XSchema is describing that very namespace ... well, that leads to a mixed-level cross-reference. Keeping the PI distinct from the element solves the problem. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 4 21:55:30 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:58 2004 Subject: Notations, subschemas, entities Message-ID: <3576FB58.39B139D4@locke.ccil.org> Toby Speight wrote: > I can't remember (nor find easily in the spec) whether notations must > be declared before use. There seems to be no such requirement. The VC simply says: "Values of this type [i.e., notation] must match one of the notation names included in the declaration; all notation names in the declaration must be declared." > John> Indeed, I'm thinking that XSchemas should have structure, ... > > Sorry, you lost me with this paragraph. Can you illustrate it with an > example? In other words: ... ... ... ... ... ... ... In one sense it would be better to have a separate element for grouping declarations, but using the same element for both root and subordinate allows direct incorporation of XSchemas into other XSchemas either by cut-and-paste or by external text entities, as I mentioned before. > I'm not keen on arbitrary markup, because I'm interested in processing the > documentation with DSSSL to give a pretty-printed human-readable document > to go with the DTD. It's hard to do that if you don't know what elements > to expect. Out of my depth. > And, as I mentioned, we'll want some XSchema-specific elements > to refer to ELEMENT definitions (for example). XLink can do that using "#elementname", but that may not be the Right Thing. My concern is that we will bloat the simple XSchema DTD with elements for marking up fancy text. If we were going to do that, we'd need a subschema (see above!) that handled just the bare bones of fancy text, preferably in an HTML-compatible way. (I do happen to have such a thing in my back pocket....) > > %external; > notation CDATA #IMPLIED> > > value CDATA #REQUIRED> Using an attribute value to hold the definition of an internal entity involves processing out all markup characters (&, <, ', "), thus: would come out as whereas is far more readable and writable. The spec should say that the content of an ENTITY element should be wrapped in a CDATA marked section. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Jun 4 22:10:10 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:58 2004 Subject: XSchema: Proposed Outline Message-ID: A proposed outline for the XSchema specification follows. I hope to begin filling in the spaces over the weekend, so I'd appreciate hearing about anything that's a) missing (keep in mind that this is a _small_ project) b) needs expansion c) should be deleted d) is dead-wrong and/or inappropriate. All drafts of the outline and of the specification will be available at http://purl.oclc.org/NET/xschema. ------------- XSchema Specification 1.0 Introduction 1.1 Status 1.2 Origin and Goals 1.3 Relation to Other Standards 1.4 Terminology 2.0 XSchema Syntax 2.1 The XSchema Document 2.2 Element Declarations 2.3 Attribute Declarations 2.4 Content Model Declarations 2.5 XSchema Extensions 2.5.1 Documentation Extensions 2.5.2 Constraints on Extensions 3.0 XSchema and Namespaces 3.1 The XSchema Namespace 3.2 Interaction with Other Namespaces 3.3 Note about Namespace Usage 4.0 XSchema Transformation to XML 1.0 DTD 4.1 Transformation Models 4.2 Transformation Losses 5.0 Connecting XSchemas to XML Documents 5.1 Processing Models 5.2 Processing Instruction Notes: 1. XSchemas and XML 1.0 DTD Interactions ------------- Thanks again to everyone for the amazing level of discussion so far! Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Jun 4 22:25:34 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:58 2004 Subject: XSchema: Meta (Web site) Message-ID: I've posted a few pieces to the XSchema web site (at http://purl.oclc.org/NET/xschema) that may be interesting. * Peter-Murray Rust sent me a brief list of potential advantages of XSchema. * Marcus Carr pointed out a tool from OmniMark Technologies that converts SGML DTDs to documents. A sample document, including the SGML DTD they used, is posted. If anyone else has something they would like linked or posted, please let me know. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From moliphan at footprint.com Thu Jun 4 23:06:53 1998 From: moliphan at footprint.com (moliphan@footprint.com) Date: Mon Jun 7 17:01:58 2004 Subject: OK, I've read some books, tons of articles, and... Message-ID: <85256619.006E4DFF.00@fpmail.torolab.ibm.com> I am still having a bit of trouble understanding the potential applications of XML. Perhaps a reader would be good enough to confirm whether my thoughts, expressed below, are valid. By creating an XML file and a DTD, you have a defined, portable set of business rules - portable, because if I send you my XML file which contains a reference to a DTD I have created and which is located on the Internet, you are presumably unable to alter the contents if I impose a validity check. The structure of XML allows parties interested in my data to do searches with filters specific to the structure of the data. For example, knowing that a "Grommet" element exists with a "Magical" attribute, interested parties could search for Grommets with a Magical attribute of "Yes". A common storage area for DTDs would possibly allow those unfamiliar with my data structure to view it. As the data is using an "Open" definition, it is available to a wider audience. Perhaps it can be processed in more than one manner in one session. My idea here is: perhaps I am viewing information a product and decide to order it. My act of placing an order performs some processing on the vendor's behalf, and potentially on mine as well. A question I have is, how does my behaviour travel with the data (as structure does not define behaviour)? I have seen how Java parsers can traverse document elements, and given elements I can now associate actions with them using Java, but how does that help you, my interested party unless you can use my code with the data? Also, is an XML file going to act as a database in some circumstances? Although I have seen examples of this, I wonder how the heck that is supposed to work with the portability idea as multiple database instances would be difficult to reconcile. The paradox as I see it is that XML provides an open definition of structuring data, but there is difficulty then in providing a generic (low cost) method of using the data. My data will be (and, hopefully act) different from yours and everybody else's, therefore no generic agent is going to know what to do with it. Thanks in advance. Mike Oliphant xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jun 4 23:11:24 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:58 2004 Subject: ANNOUNCE: Virtual Hyperglossary (VHG) DTD 1.0 alpha In-Reply-To: <01e801bd8fdf$4ce3abf0$0132fac1@ipusushi> References: <3.0.1.16.19980529083324.37074526@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980604215323.86a71a4e@pop3.demon.co.uk> At 11:36 04/06/98 -0600, Joel Riedesel wrote: > >Preface: > I'm using this vhg.dtd to test out some work we're doing with parsing out > the DTD and using that to allow authors to reference data in documents >that > use that DTD (and subsequently be able to reason upon that data). Thanks very much for taking the time to test it :-). > >DTD Parsing Assumption: > I had made an assumption (probably quite incorrectly) that there would >only be > element in the DTD that wasn't referenced by other elements and therefore >I > would use that element as my "top" element. This is a natural and (I believe) false assumption. A DTD need not have a hierarchical structure, though most do. The following is acceptable: It is then possible to have any of the following: I am an A I am an B I am an C It is one of the 5 myths (I think Eliot Kimber said this) that DOCTYPE tells you what the document type is. It simply gives the root element and the set of ELEMENTs that can be used. > >Question: > This vhg.dtd has a locatorLink that is not referenced by any other > element in the DTD. The semantics of extendedLink say that it will > always contain locatorLink elements, but the DTD for extendedLink doesn't > actually state that. This is a shortcoming of the DTD approach to constraining content. Originally XLink was constructed as Then it was thought it would be useful to have text amongst the links, e.g:

    once upon a time there were three bears There is no way in XML of saying you must have certain content and you may have some other undefined in the DTD. A content model of (locatorLink*, ANY) would do the trick, but it's not allowed. There is discussion as to how to extend this so it can be expressed. I am sure some people more informed than me will comment on current initiatives in SGML and XML. > >So... somewhat obviously, I end up with the locatorLink as my top element. >Oops. (Looks like I need to at least provide for the possibility of >multiple >top elements and let our author choose the correct one.) The DTD cannot require you to have a hierarchy. It can only tell you whether the hierarchy you have chosen is compatible with the DTD. >Is this type of DTD practice in any way standard? It sure feels a bit >messy to define things this way (makes it tough to use the DTD by another That is why a number of people are actively discussing schemas. It is a possible way to extend the semantic expressibility. >program and actually automate XML things...). If the authors of the VHG.dtd >find the need to define things this way, is that due to a current limitation >of DTDs in general? Yes :-) > >Feel free to correct any misunderstanding I may have (which I won't >be at all surprised about). Delighted. That is one reason we are here... Lots of people did it for me when I was learning (and I still am :-) Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jun 4 23:11:34 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:58 2004 Subject: John replies to Ron: Differences In-Reply-To: <3576E737.A13B63A@locke.ccil.org> References: <199806041610.SAA11550@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980604215712.86a7051c@pop3.demon.co.uk> At 14:28 04/06/98 -0400, John Cowan wrote: [...] >> Furthermore, in more data (as >> opposed to document) applications of XML, PCDATA-only content seems to be >> relatively common. > >Perhaps true. But maybe that's a historical artifact due to there >being no standard way to express rich text within databases. PCDATA-only content models are likely to be extremely common in many areas and not necessarily related to their use in databases. I use them all the time in CML. They are also widely used in the examples in the RDF draft (e.g. the Dublin Core uses). P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jun 4 23:11:40 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:58 2004 Subject: New Kid on the block... In-Reply-To: <3576E866.CDEC6CD5@sbu.ac.uk> References: <199806041616.SAA11609@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980604220739.86a754d2@pop3.demon.co.uk> At 19:33 04/06/98 +0100, Marios Adamantopoulos wrote: >Hi all Hi Mario. > >well I'm a beginner with XML > >so if anyone could give me any hints, it would be GREAT!!! > >I'm going to do my final year project in XML( Metadata probably) Excellent. Student projects are often where really exciting things happen. Until this year I was external examiner at SBU and there were some very nice projects. You'll have to work quite hard but it will be worth it. By far the best places to start are the two complementary web pages: - http://www.sil.org/sgml/xml.html run by Robin Cover (OASIS) - http://www.ucc.ie/xml FAQ run by Peter Flynn. These have links to everywhere. So if you look for software, programs, etc. you'll find lots. and there are some very good collections of programs, examples, tutorials, etc. One of the key skills of XML is never to duplicate something if you don't have to. So we link to information rather than mentioning it explicitly. So you might want to look at xml-l which often has more general info that xml-dev. But I shan't tell you how to find it - that would be duplication :-) P. If you manage to do something really new, you will find people are interested. There are huge uncharted areas for XML to open up. If you have a personal interest/hobby it may be that XML can support that. For example, one thing discussed on XML-DEV has been genealogy (family histories). But XML could support almost anything that can be cleanly described and a good deal that can't. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 4 23:20:00 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:58 2004 Subject: OK, I've read some books, tons of articles, and... References: <85256619.006E4DFF.00@fpmail.torolab.ibm.com> Message-ID: <35770F38.ABD5847A@locke.ccil.org> moliphan@footprint.com wrote: > By creating an XML file and a DTD, you have a defined, portable set of > business rules - portable, because if I send you my XML file which contains > a reference to a DTD I have created and which is located on the Internet, > you are presumably unable to alter the contents if I impose a validity > check. Well, that's a little strong. You can't alter the structure, we might say, or at least only in predetermined ways. The content (not just actual #PCDATA content, but the values of attributes) can be altered arbitrarily. > The structure of XML allows parties interested in my data to do searches > with filters specific to the structure of the data. For example, knowing > that a "Grommet" element exists with a "Magical" attribute, interested > parties could search for Grommets with a Magical attribute of "Yes". Just so. > A common storage area for DTDs would possibly allow those unfamiliar with my > data structure to view it. The whole Web serves as the common storage area, since references to DTD are by URL, a local file name being a degenerate case of an URL. > A question I have is, how does my behaviour travel with the data (as > structure does not define behaviour)? I have seen how Java parsers can > traverse document elements, and given elements I can now associate actions > with them using Java, but how does that help you, my interested party > unless you can use my code with the data? It doesn't. That's the meaning of the buzzphrase "XML gives Java something to do/chew on." > Also, is an XML file going to act as a database in some circumstances? > Although I have seen examples of this, I wonder how the heck that is > supposed to work with the portability idea as multiple database instances > would be difficult to reconcile. Depends what you mean by "database". An XML document residing on a server someplace can represent a database, particularly if it has a DTD of the form: top-level element contains zero or more row elements, each of which can contain various column elements. That makes it look like a relational table. Of course, it does not provide the ACID properties that real databases have! > The paradox as I see it is that XML provides an open definition of > structuring data, but there is difficulty then in providing a generic (low > cost) method of using the data. My data will be (and, hopefully act) > different from yours and everybody else's, therefore no generic agent is > going to know what to do with it. XML does not make this problem any worse, though, and moving around behavior is not specifically an XML problem, although behavior-specifying languages could be written as XML applications: the not-yet-fully-defined XSL does this for the behavior of rendering on paper or screen; Java can provide generalized mobile behavior. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 4 23:28:43 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:01:58 2004 Subject: Roots of the DTD (was: ANNOUNCE: Virtual Hyperglossary) References: <3.0.1.16.19980529083324.37074526@pop3.demon.co.uk> <3.0.1.16.19980604215323.86a71a4e@pop3.demon.co.uk> Message-ID: <35771148.3E081D4C@locke.ccil.org> Peter Murray-Rust wrote: > This is a natural and (I believe) false assumption. A DTD need not have a > hierarchical structure, though most do. The following is acceptable: > > > > > It is then possible to have any of the following: > I am an A > I am an B > I am an C > > It is one of the 5 myths (I think Eliot Kimber said this) that DOCTYPE > tells you what the document type is. It simply gives the root element and > the set of ELEMENTs that can be used. Hmmm. This sounds like the "root" (my syntax) or "RootElement" (Ron's syntax) attribute in XSchema is a Bad Thing. Perhaps it should be removed? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jun 4 23:34:52 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:59 2004 Subject: Behavior and Semantics (was Re: OK, I've read some books, tons of articles, and...) In-Reply-To: <85256619.006E4DFF.00@fpmail.torolab.ibm.com> Message-ID: <3.0.1.16.19980604223112.8ca7ecee@pop3.demon.co.uk> Join the club, Mike - this is a major area of activity. You have rightly realised that a DTD defines the structure of a document, but not how it behaves or what should be done with it. There are two sorts of objects that will be interested in XML documents, humans and machines (and possibly some combination). For humans the most common activity will be using a stylesheet to render the document in a way that is more meaningful to a human. Thus could be rendered in large font in the middle of the page. Most humans can recognise a title because they have seen thousands in their life. Similarly something like <DATE format="ISO8601">19980604</DATE> might be rendered as June 4 1998 - the information is no different but it may be better understood At 17:01 04/06/98 -0400, moliphan@footprint.com wrote: > > >A question I have is, how does my behaviour travel with the data (as >structure does not define behaviour)? I have seen how Java parsers can >traverse document elements, and given elements I can now associate actions >with them using Java, but how does that help you, my interested party >unless you can use my code with the data? Machines need other ways of interpreting XML data and so - for example - if I send someone a molecule in XML a stylesheet isn't much help. You have to have a program. So long as we all agree on the DTD and the semantics and the ontology (tough) it doesn't matter what program we use. Unfortunately much chemical ontology is hardcoded into programs. > >Also, is an XML file going to act as a database in some circumstances? >Although I have seen examples of this, I wonder how the heck that is >supposed to work with the portability idea as multiple database instances >would be difficult to reconcile. XML will be used to transport data in a variety of 'formats'. Some will map directly onto well-know structures (e.g. RDBs) but others will be less structured. I make a lot of use of data in flexible structures and by using tree navigation can often use the XML document 'as the database'. > >The paradox as I see it is that XML provides an open definition of >structuring data, but there is difficulty then in providing a generic (low >cost) method of using the data. My data will be (and, hopefully act) >different from yours and everybody else's, therefore no generic agent is >going to know what to do with it. Your *data* may be different, but hopefully your ontology can be mapped onto other peoples. Thus maths will use MathML - the equations will vary , but they will all use the same DTD. Similarly chemists and biologists can use CML, and assuming they all mean the same thing by a an ATOM (fairly easy) and BOND (*not trivial*) they can interchange information seamlessly. Moreover mathematical chemists can use both MathML and CML in the same document using the namespace approach. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Thu Jun 4 23:44:10 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:01:59 2004 Subject: New Kid on the block... Message-ID: <01bd9002$5e706340$1eaedccf@bckman.ix.netcom.com> I have some very basic XML tutorial material at http://www.hypermedic.com/style/index.htm that you may want to look at. Frank -----Original Message----- From: Marios Adamantopoulos <adamanm@sbu.ac.uk> To: xml-dev@ic.ac.uk <xml-dev@ic.ac.uk> Date: Thursday, June 04, 1998 2:28 PM Subject: New Kid on the block... >Hi all > >well I'm a beginner with XML > >so if anyone could give me any hints, it would be GREAT!!! > >I'm going to do my final year project in XML( Metadata probably) > >but I would like to learn a few things first. > >So if anyone knows where to get an XML editor and any other hints, or web >addresses >or books , please tell me... > >Thanks > >Mario-Mr.Blue > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jun 4 23:46:39 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:59 2004 Subject: Roots of the DTD (was: ANNOUNCE: Virtual Hyperglossary) In-Reply-To: <35771148.3E081D4C@locke.ccil.org> References: <3.0.1.16.19980529083324.37074526@pop3.demon.co.uk> <3.0.1.16.19980604215323.86a71a4e@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980604224340.1cef3e16@pop3.demon.co.uk> At 17:27 04/06/98 -0400, John Cowan wrote: > >Hmmm. This sounds like the "root" (my syntax) or "RootElement" (Ron's >syntax) attribute in XSchema is a Bad Thing. Perhaps it should be >removed? > Yup :-). I have not commented on the current proposals because I wanted them to anneal before public comment. *For describing a DTD*, here should be no requirement to define a <root> of any sort, only <element>, <attribute>, <contentSpec> and possibly <entity> and <notation> according to how people think. Of course if you wish to propose a <root> element to extend the functionality you may, but I (and I expect many others) will urge you to remove it :-) P. (Of course the XSchema **as an XML document** must have exactly one root element, but it will probably be called something like <XSC:XSchema>) Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Jun 5 00:06:26 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:01:59 2004 Subject: Roots of the DTD (was: ANNOUNCE: Virtual Hyperglossary) Message-ID: <UPMAIL17.199806042204070661@classic.msn.com> >Hmmm. This sounds like the "root" (my syntax) or "RootElement" (Ron's >syntax) attribute in XSchema is a Bad Thing. Perhaps it should be >removed? Given the current way DOCTYPEs work, as well as the desire voiced by many on this list to be able to validate fragments, we'd probably do better to leave roots out of it. It remains an important issue, however, for whatever we use to link an XSchema to a document. Do we need/want to declare a 'Root' element there? It seems to me it could be optional, provided that whatever authors choose as their root contains the content model specified for it by the schema. This is an issue we need to address. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mcc at arbortext.com Fri Jun 5 02:17:22 1998 From: mcc at arbortext.com (Mike Champion) Date: Mon Jun 7 17:01:59 2004 Subject: OK, I've read some books, tons of articles, and... In-Reply-To: <85256619.006E4DFF.00@fpmail.torolab.ibm.com> Message-ID: <98Jun4.201151edt.26881@thicket.arbortext.com> At 05:01 PM 6/4/98 -0400, moliphan@footprint.com wrote: > >A question I have is, how does my behaviour travel with the data (as >structure does not define behaviour)? I have seen how Java parsers can >traverse document elements, and given elements I can now associate actions >with them using Java, but how does that help you, my interested party >unless you can use my code with the data? I see two ways in which XML helps here: First, the simple but powerful syntax allows Perl-type scripts to relatively easily extract specific content from the XML markup without having to "understand" anything about the document itself. Second, there *are* standard APIs emerging to allow Java, C++, etc. programs to process a variety of XML data in a common way; these include the "Simple Api for Xml" or SAX convention for interfacing to parsers, and the forthcoming W3C "Document Object Model" or DOM API to facilitate the kinds of things that "Dynamic HTML" scripts do, but for a standard way across XML applications. Between Java or JavaScript, XML and these APIs, you can widely share code and data in a convenient way. > >Also, is an XML file going to act as a database in some circumstances? >Although I have seen examples of this, I wonder how the heck that is >supposed to work with the portability idea as multiple database instances >would be difficult to reconcile. XML-based "schemas" can make it easier to interchange data; think of it as a generalized, somewhat self-describing data exchange format rather than a silver bullet to solve the portability problem. > >The paradox as I see it is that XML provides an open definition of >structuring data, but there is difficulty then in providing a generic (low >cost) method of using the data. My data will be (and, hopefully act) >different from yours and everybody else's, therefore no generic agent is >going to know what to do with it. There are a number of XML-based "metadata" initiatives, notably the "Resource Definition Format" or RDF that provides a set of conventions by which your data can be described, and this description interchanged with a database schema. It sounds to me like the "generic agent" you talk about would be a full-blown "artificial intelligence" that's well beyond the state of the art. XML merely provides a syntax or meta-language, and a set of conventions such as RDF, so that "artificial idiot-savant" applications or SPECIALIZED agents can be defined and widely exchanged. In other words, it's a set of conventions that let's us move forward more quickly than we have with HTML and a wide range of proprietary data formats, but it is by no means a universal knowledge representation format that would take us a quantum leap into the future. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From adamanm at sbu.ac.uk Fri Jun 5 03:21:17 1998 From: adamanm at sbu.ac.uk (Marios Adamantopoulos) Date: Mon Jun 7 17:01:59 2004 Subject: New Kid on the block... (block=XML) Message-ID: <357749CE.6DB97DDE@sbu.ac.uk> First, thanks to everyone... Honestly, I'm in the Toolbook list as well but new people don't get many replies... Secondly, when I was asking for any good web sites, I meant for novices like...me, sorry, I didn't specified it. I have found a lot of web sites, about 30, until now, but because I just started, it's a bit confusing... Everything is gonna become clear soon, and a great project is going to be created, by Spring time I hope... Anyway that was just a thank you message, and I look forward to help other people as well, say in 2-3 months, I hope, again... :-) That's all Enough said Have a nice day, night or both... Mario-Mr.Blue xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jun 5 03:28:15 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:59 2004 Subject: Announcement: change in AElfred maintainer Message-ID: <3.0.1.16.19980605022655.335f95a8@pop3.demon.co.uk> [forwarded by me from XML-L] > >As many of you already know, I left Microstar a few weeks ago to start >my own business. The AElfred XML parser that I wrote remains a (free) >Microstar product, and Microstar will continue to maintain it. Please >send all future bug reports, feature requests, or queries about >AElfred to the following e-mail address: > > info@microstar.com > >Any announcements about future releases will come directly from >Microstar. For information about Microstar, AElfred, and Microstar's >other XML products and services, see > > http://www.microstar.com/ > > >Thanks, and all the best, > > >David > >-- >David Megginson david@megginson.com > http://www.megginson.com/ > I am sure we all wish David well, and hope that his new business allows him (or even requires him) to keep in touch with XML-DEV or other XML organs. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.Sun.COM Fri Jun 5 06:49:11 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:01:59 2004 Subject: XSchema Question 2: Namespaces In-Reply-To: <3.0.1.16.19980604172602.8ca793e4@pop3.demon.co.uk> (message from Peter Murray-Rust on Thu, 04 Jun 1998 17:26:02) Message-ID: <199806050446.VAA02045@boethius.eng.sun.com> [Peter Murray-Rust:] | I think we all agree that it is - strictly speaking - 'wasted motion' | in formal W3C terms. I see what we are doing rather as the 'research' | department of a company where we do not have to produce a product for | the market, but can address things that may have value in their own | right or may provide useful experience. The goal is to have something | by the end of the month which will be simple, implementable and | provide something useful that isn't currently available. If it's | throw-away in 6 months none of those involved are going to lose sleep. I'm glad to hear that. | Assuming we are *technically* successful, that helps build up a | virtual community which knows how to tackle problems in a virtual | manner. In that respect I feel the current membership is rather | special :-). It is indeed an amazing collection of talent. | Personally there is no way that *I* can tackle the current XSL spec | since the requirements are quite outside my capability even to | comprehend :-) There is a very large emphasis on typography - | implementing XSL requires it to have the functionality of TeX as a | subset. Implementing XSL requires it to have the functionality of DSSSL. Take a look at Jade. Are you telling me that the collective resources of this entire group aren't adequate to the production of something that equals what James Clark can do by himself? Jon xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jun 5 08:12:02 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:01:59 2004 Subject: Behavior and Semantics Message-ID: <3.0.1.16.19980605070600.1c2fa61e@pop3.demon.co.uk> [from David Durand] > > ------ This is a copy of the message, including all the headers. ------ > > Return-path: <david@dynamicdiagrams.com> > Received: from punch.ic.ac.uk [155.198.5.17] > by bowmore.cc.ic.ac.uk with smtp (Exim 1.58 #2) > id 0yhlBp-0004JO-00; Fri, 5 Jun 1998 02:21:05 +0100 > Received: from dynamicdiagrams.com [205.181.196.2] > by punch.ic.ac.uk with smtp (Exim 1.62 #1) > id 0yhlBn-0000UP-00; Fri, 5 Jun 1998 02:21:04 +0100 > Received: by dynamicdiagrams.com (940816.SGI.8.6.9/940406.SGI.AUTO) > for xml-dev@ic.ac.uk id VAA08243; Thu, 4 Jun 1998 21:10:05 -0700 > Date: Thu, 4 Jun 1998 21:10:05 -0700 > From: david@dynamicdiagrams.com (David G. Durand) > Message-Id: <199806050410.VAA08243@dynamicdiagrams.com> > To: xml-dev@ic.ac.uk > Subject: Re: Behavior and Semantics (was Re: OK, I've read some books, tons > of articles, and...) > > >From: Peter Murray-Rust <peter@ursus.demon.co.uk> > > >You have rightly realised that a DTD defines the structure of a document, > >but not how it behaves or what should be done with it. > > This is exactly correct. This is because the set of possible behaviors > a document might exhibit and processes to which it might be subjected > is an open (infinite) set. By providing names in some well-known > ontology, we hope to make it easier to re-use information with > different processes. > > I'm responding to this, because I hope that I can help unconfuse soem > issues that you have persistently confused as to the applicability of > the "stylesheet notion". > > >There are two sorts of objects that will be interested in XML documents, > >humans and machines (and possibly some combination). > > >For humans the most common activity will be using a stylesheet to render > >the document in a way that is more meaningful to a human. Thus <TITLE> > >could be rendered in large font in the middle of the page. Most humans can > >recognise a title because they have seen thousands in their life. Similarly > >something like > ><DATE format="ISO8601">19980604</DATE> might be rendered as > >June 4 1998 > > >- the information is no different but it may be better understood > > >At 17:01 04/06/98 -0400, moliphan@footprint.com wrote: > > >>A question I have is, how does my behaviour travel with the data (as > >>structure does not define behaviour)? I have seen how Java parsers can > >>traverse document elements, and given elements I can now associate actions > >>with them using Java, but how does that help you, my interested party > >>unless you can use my code with the data? > > > >Machines need other ways of interpreting XML data and so - for example - if > >I send someone a molecule in XML a stylesheet isn't much help. You have to > >have a program. So long as we all agree on the DTD and the semantics and > >the ontology (tough) it doesn't matter what program we use. Unfortunately > >much chemical ontology is hardcoded into programs. > > This is the point on which you are incorrect. The term stylesheet is > perhaps confusing, since it implies a formatting specification, but > then the notion, like most of the notions in XML, comes from the print > (and online) publishing world. > > XML stylesheets will have a hook to a fully general scripting > language. That means that it will be possible to have stylesheets that > access special browser caspabilities, Java code, or whatever. It's > important that this be done via style sheets, since that's the > standard mechanism, and since users will be able to change stylesheets > if they need to interpret the data differently. For instance, you > might supply a molecule with a "display 3D model" style, while I want > to "view" it by using my molecular synthesis generation software. > > Both of us are accomodated by XML, and both are served by the use of > a single method of attaching processing semantics to a document. > > >>The paradox as I see it is that XML provides an open definition of > >>structuring data, but there is difficulty then in providing a generic (low > >>cost) method of using the data. My data will be (and, hopefully act) > >>different from yours and everybody else's, therefore no generic agent is > >>going to know what to do with it. > > >Your *data* may be different, but hopefully your ontology can be mapped > >onto other peoples. Thus maths will use MathML - the equations will vary , > >but they will all use the same DTD. Similarly chemists and biologists can > >use CML, and assuming they all mean the same thing by a an ATOM (fairly > >easy) and BOND (*not trivial*) they can interchange information seamlessly. > > Moreover mathematical chemists can use both MathML and CML in the same > >document using the namespace approach. > > And, using the stylesheet mechanism, you can inform users of the > method of processing _you_ intend to use with the data. > > In most browsing contexts, a default display stylesheet will be > appropriate, but the fact XML inherently supports indirection for > processing methods allows a lot of power for repurposing and upgrading > data that is already created. > > -- David > ------------------------------------------+---------------------------- > David Durand dgd@cs.bu.edu| david@dynamicDiagrams.com > Boston University Computer Science | Dynamic Diagrams > http://www.cs.bu.edu/students/grads/dgd/ | http://dynamicDiagrams.com/ > | MAPA: mapping for the WWW > | http://dynamicDiagrams.com/minimapa > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jun 5 08:12:09 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:00 2004 Subject: XML-DEV as virtual community (was Re: XSchema Question 2: Namespaces) In-Reply-To: <199806050446.VAA02045@boethius.eng.sun.com> References: <3.0.1.16.19980604172602.8ca793e4@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980605070506.1df71052@pop3.demon.co.uk> At 21:46 04/06/98 -0700, Jon Bosak wrote: [...] > >| Assuming we are *technically* successful, that helps build up a >| virtual community which knows how to tackle problems in a virtual >| manner. In that respect I feel the current membership is rather >| special :-). > >It is indeed an amazing collection of talent. > >| Personally there is no way that *I* can tackle the current XSL spec >| since the requirements are quite outside my capability even to >| comprehend :-) There is a very large emphasis on typography - >| implementing XSL requires it to have the functionality of TeX as a >| subset. > >Implementing XSL requires it to have the functionality of DSSSL. Take >a look at Jade. Are you telling me that the collective resources of >this entire group aren't adequate to the production of something that >equals what James Clark can do by himself? > Thanks, Jon. Actually I frequently feel that the best programs are either written by a large number of people or a single one. What we see on the Web in general is a process of evolution in the Darwinian sense. Many solutions are not planned, they evolve [1]. The uses to which HTML has been put represent the results of experiments, a few of which have worked, and a great many of which fail. A successful idea (or 'meme' to use Richard Dawkins' term) can breed very quickly on the WWW. XML-DEV is a breeding ground for XML memes. Many ideas are seeded and a very few survive. We cannot expect those to be the 'best' in some absolute sense, but they will be 'good'. They will coexist with a competing fluid ecosystem of other memes. The membership of XML-DEV grows steadily - Henry tells me it's about 1200 (and I suspect that the readership is higher since it's probably syndicated in some organisations). I therefore don't think we are 'depleting the energy resources' by working on this problem. It's interesting that many of the people involved are quite distinct from those involved in SAX. I think this represents an influx of talent that may have come from the non-SGML community and in this sense it may bring fresh insights. I am interested and flattered that you see XML-DEV having a positive role for XSL. Perhaps - when it is released - it would be clear what the areas are in which implementation will be seen as valuable. Implementing XSL is a very large project and will require modularisation. If that modularity is clear in the spec, that will be a great help. In that case I am sure there are many readers who will find modules that they: - need - would like to contribute to - have the appropriate skills (and work with interoperable technology - e.g. language) and they - are happy to do this in public - are happy to work in the XML-DEV manner (i.e. no formal guarantee that their work will ultimately count for anything) For my own purposes I would love to see an effort on the non-typographical aspects of XSL. We need to have mechanisms for implementing behaviour. This is probably complementary to the (?main) effort in rendering XML for human readers. P. [1] The infrastructure of the Web (e.g. the protocols) is , of course, very carefully regulated and cannot vary. It corresponds to the basic machinery of any organism - essentially all use the same genetic code. But above that there is great flexibility. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jun 5 08:44:10 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:00 2004 Subject: Behavior and Semantics In-Reply-To: <3.0.1.16.19980605070600.1c2fa61e@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980605074329.218f7b52@pop3.demon.co.uk> At 07:06 05/06/98, Peter Murray-Rust wrote: >[from David Durand] [...] >> > >> >Machines need other ways of interpreting XML data and so - for example - if >> >I send someone a molecule in XML a stylesheet isn't much help. You have to >> >have a program. So long as we all agree on the DTD and the semantics and >> >the ontology (tough) it doesn't matter what program we use. Unfortunately >> >much chemical ontology is hardcoded into programs. >> >> This is the point on which you are incorrect. The term stylesheet is >> perhaps confusing, since it implies a formatting specification, but >> then the notion, like most of the notions in XML, comes from the print >> (and online) publishing world. >> >> XML stylesheets will have a hook to a fully general scripting >> language. That means that it will be possible to have stylesheets that >> access special browser caspabilities, Java code, or whatever. It's >> important that this be done via style sheets, since that's the >> standard mechanism, and since users will be able to change stylesheets >> if they need to interpret the data differently. For instance, you >> might supply a molecule with a "display 3D model" style, while I want >> to "view" it by using my molecular synthesis generation software. >> >> Both of us are accomodated by XML, and both are served by the use of >> a single method of attaching processing semantics to a document. I agree with your analysis. I am probably using the word 'stylesheet' to mean 'implementations of XSL'. My concern has been how to implement functionality using the scripting language. This may become clearer when XSL next version comes out. When it was originally released, however it seemed that there was not likely to be support for Java programs, nor for any document transformation nor for many interactive operations. I agree that the stylesheet lets you locate an element-in-context and then apply some script to it. My concern was (and perhaps is) that XSL isn't going to give me much help unless I'm interested in rendering text - I hope I'm wrong about that. At present I need to: - locate <CML:MOL> in a document - run some code to process it or apply behaviour. I can see that the stylesheet may help me with the former, but I can't see yet that it has much to offer for the latter - other than saying "you can run some code here on this element" (maybe by calling Java from ECMAScript) - which is essentially what I had been saying. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecom.mixx.de Fri Jun 5 09:27:16 1998 From: James.Anderson at mecom.mixx.de (james anderson) Date: Mon Jun 7 17:02:00 2004 Subject: SGML/XML 98 Paris, another take ->? namespaces & validation References: <199805272256.PAA29584@boethius.eng.sun.com> Message-ID: <35779E48.DDE58D44@mecom.mixx.de> Jon Bosak wrote: > > One thing I may not have been sufficiently clear about in my report > was that the nervousness I personally feel about the namespace draft > isn't about its ability to solve the problems it was designed for > (there is universal agreement among the groups for which it was > produced that it does) but about the complexities it raises for > traditional DTD validation. I probably should have been more explicit > about this. yes, please. is there some part of the exisiting deliberations which led up to the namespace proposal, which could be made public and would explain the problem? i would welcome this, as, although i've heard the concern expressed often, i've seen no basis for it in implementing namespaces and validation, and am wondering if i've misunderstood something fundamental... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Fri Jun 5 09:44:06 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:00 2004 Subject: John replies to Ron: Differences Message-ID: <199806050742.JAA13362@berlin.dvs1.tu-darmstadt.de> Peter Murray-Rust wrote: > >> Furthermore, in more data (as > >> opposed to document) applications of XML, PCDATA-only content seems to be > >> relatively common. > > > >Perhaps true. But maybe that's a historical artifact due to there > >being no standard way to express rich text within databases. > > PCDATA-only content models are likely to be extremely common in many areas > and not necessarily related to their use in databases. I use them all the > time in CML. They are also widely used in the examples in the RDF draft > (e.g. the Dublin Core uses). This is what I meant. Many data applications of XML, such as transferring sales orders or flight schedules across the net, have no interest in rich text. Thus, they are likely to have many PCDATA-only elements. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Fri Jun 5 10:15:55 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:00 2004 Subject: XSchema: Proposed Outline Message-ID: <199806050812.KAA13585@berlin.dvs1.tu-darmstadt.de> Simon St. Laurent wrote: > A proposed outline for the XSchema specification follows. I hope to begin > filling in the spaces over the weekend, so I'd appreciate hearing about > anything that's > > a) missing (keep in mind that this is a _small_ project) > b) needs expansion > c) should be deleted > d) is dead-wrong and/or inappropriate. > > [outline snipped] This looks good to me. I would add: * An appendix for the XSchema DTD * An appendix for the XSchema-declared-in-XSchema document Also, do we need a section discussing the interaction of XSchema with other DTDs (there was some mention yesterday of allowing an internal subset which I didn't quite follow) or is this covered under the XSchema PI? -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Fri Jun 5 11:02:31 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:00 2004 Subject: XSchema: Notation attributes Message-ID: <199806050858.KAA13730@berlin.dvs1.tu-darmstadt.de> Toby Speight wrote: > From your DTD: > > Ron> <!ELEMENT NotationType (NotationValue+)> > Ron> <!ELEMENT NotationValue (#PCDATA)> > Ron> <!ATTLIST NotationValue > Ron> Notation IDREF #REQUIRED> > > In particular, NotationType contains a list of Notation values. Why? > What's wrong with the following? > > <!ELEMENT NotationType EMPTY> 1) Oops -- I got this right in the XML file but not in the DTD. NotationType is now EMPTY. 2) Notice that the Notation attribute is type IDREF. This is valid only if notations themselves must be unique (and hence can be identified by an ID attribute). I posted a question about this yesterday but have not yet received an answer. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Fri Jun 5 11:10:10 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:00 2004 Subject: XSchema: PCDATA-only content (was: John replies to Ron: ...) In-Reply-To: rbourret@dvs1.informatik.tu-darmstadt.de's message of "Thu, 4 Jun 1998 18:10:56 +0200" References: <199806041610.SAA11550@berlin.dvs1.tu-darmstadt.de> Message-ID: <ulnrcjjty.fsf@digitivity.com> Ron> Ron Bourret <URL:mailto:rbourret@dvs1.informatik.tu-darmstadt.de> => In article <199806041610.SAA11550@berlin.dvs1.tu-darmstadt.de>, Ron => wrote: Ron> Content models of PCDATA and EMPTY represent the terminals in Ron> DTDs. That is, bold, italic, etc. have a PCDATA content model. Ron> Furthermore, in more data (as opposed to document) applications Ron> of XML, PCDATA-only content seems to be relatively common. For Ron> the moment, I have left PCData in and required Mixed to take at Ron> least one ElementRef, per your earlier suggestion. To me, it's not particularly important whether PCDATA-only content is represented with a distinct element or as a special case of MIXED. But I think the latter is quite usable if a convenience is defined thus: <!ENTITY pcdata "<MIXED/>"> Then we can write <ELEMENT foo> &pcdata; </ELEMENT> -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From h.rzepa at ic.ac.uk Fri Jun 5 11:12:45 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:02:00 2004 Subject: LISTADMIN: unsubscribing and general admin Message-ID: <v0401170ab19d6663b842@[155.198.224.86]> One of two please come my way every day asking for help in unsubscribing. One problem seems to be that people are sending what is called "styled" text to majordomo making the request. Whilst the styling might be invisible to the user's emailer (eg Eudora etc), Majordomo gets confused about handling a request that is wrapped in <...> tags (its after all a program from the dark ages of 2-3 years ago> So if you have an admin request, please turn all styling off, and try to ensure if possible that the request emanates from the same email identity as the one actually subscribed. If this is not possible, send one of the type unsubscribe xml-dev yourname@youraddress and I will process it manually. About 20 of these come in every week, so I cannot guarrantee I will action it immediatly. Once in a while the odd request will "scroll off the top of my screen" and get orphaned, so if nothing has happened after a week, please remind me! Re Daily digests. It may take a day (or three) to get this actioned. Please bear with me. Finally, I have had at least one person say they do not know my email address to contact me. Please note that its at the bottom of the (overlong!) signature, so that excuses of this type carry no weight! Sorry!! Dr Henry Rzepa, Dept. Chemistry, Imperial College, LONDON SW7 2AY; mailto:rzepa@ic.ac.uk; Tel (44) 171 594 5774; Fax: (44) 171 594 5804. URL: http://www.ch.ic.ac.uk/rzepa/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Fri Jun 5 11:18:28 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:00 2004 Subject: Roots of the DTD In-Reply-To: Peter Murray-Rust's message of "Thu, 04 Jun 1998 22:43:40" References: <3.0.1.16.19980529083324.37074526@pop3.demon.co.uk> <3.0.1.16.19980604215323.86a71a4e@pop3.demon.co.uk> <3.0.1.16.19980604224340.1cef3e16@pop3.demon.co.uk> Message-ID: <uiumgjjg0.fsf_-_@digitivity.com> Peter> Peter Murray-Rust <URL:mailto:peter@ursus.demon.co.uk> => In article <3.0.1.16.19980604224340.1cef3e16@pop3.demon.co.uk>, => Peter wrote: Peter> At 17:27 04/06/98 -0400, John Cowan wrote: >> Hmmm. This sounds like the "root" (my syntax) or "RootElement" >> (Ron's syntax) attribute in XSchema is a Bad Thing. Perhaps it >> should be removed? Peter> Yup :-). I have not commented on the current proposals because Peter> I wanted them to anneal before public comment. *For describing Peter> a DTD*, here should be no requirement to define a <root> of any Peter> sort, only <element>, <attribute>, <contentSpec> and possibly Peter> <entity> and <notation> according to how people think. I can forsee applications where one might say, "Please send me documents conforming to the FOO schema," in much the same way as one requests LaTeX or Word formats these days. In which case, one usually needs also to specify the root element (this is implied in LaTeX or Word). I don't see any harm in the schema having a default root (on the understanding that documents may, if they wish, use a different root). It's not a big issue to me, though. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Fri Jun 5 11:53:07 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:00 2004 Subject: Notations, subschemas, entities In-Reply-To: John Cowan's message of "Thu, 04 Jun 1998 15:54:00 -0400" References: <3576FB58.39B139D4@locke.ccil.org> Message-ID: <ud8cojhu2.fsf@digitivity.com> John> John Cowan <URL:mailto:cowan@locke.ccil.org> => In article <3576FB58.39B139D4@locke.ccil.org>, John wrote: John> Toby Speight wrote: >> I can't remember (nor find easily in the spec) whether notations >> must be declared before use. John> There seems to be no such requirement. The VC simply says: John> "Values of this type [i.e., notation] must match one of the John> notation names included in the declaration; all notation names John> in the declaration must be declared." Yes, that's all I could find. John> Indeed, I'm thinking that XSchemas should have structure, ... >> Sorry, you lost me with this paragraph. Can you illustrate it with an >> example? John> In other words: John> John> <DOCTYPE root="blah"> John> <DOCTYPE> John> <ELEMENT id="blah"> ... </ELEMENT> John> <ELEMENT id="bazz"> ... </ELEMENT> John> <NOTATION id="foo"> ... </ELEMENT> John> </DOCTYPE> John> <DOCTYPE> John> <ELEMENT id="zim"> ... </ELEMENT> John> <DOCTYPE> John> <ENTITY ...> ... </ENTITY> John> <ENTITY ...> ... </ENTITY> John> <ELEMENT id="zam"> ... </ELEMENT> John> </DOCTYPE> John> </DOCTYPE> Ah, I see. While it does mean there are many functionally-equivalent XSchemas for a given DTD, I have no real objection to this (although if I were creating reusable XSchema fragments, I'd stick the ELEMENT etc. declarations in a separate file, and have my XSchema reference them. I'm not 100% convinced of the utility of importing a schema that hasn't been designed for re-use. John> My concern is that we will bloat the simple XSchema DTD with John> elements for marking up fancy text. If we were going to do John> that, we'd need a subschema (see above!) that handled just the John> bare bones of fancy text, ... Yes, that's a danger. I think we need to thrash out documentation issues in a separate discussion. Unfortunately, I may be unable to see it through to the end, as I'm on holiday from 13th June until the end of the month. >> <!ELEMENT EXTERNAL-ENTITY (DOC?)> >> <!ATTLIST EXTERNAL-ENTITY >> %external; >> notation CDATA #IMPLIED> >> <!ELEMENT INTERNAL-ENTITY (DOC?)> >> <!ATTLIST INTERNAL-ENTITY >> value CDATA #REQUIRED> John> Using an attribute value to hold the definition of an internal John> entity involves processing out all markup characters (&, <, ', John> "), thus: John> John> <!ENTITY yutz 'I use &int-entity; and refer to "&ext-entity;"'> John> John> would come out as John> John> <INTERNAL-ENTITY value="I use &int-entity; and refer to John> "&ext-entity;""/> John> John> whereas John> John> <INTERNAL-ENTITY><![CDATA[I use &int-entity; and refer to John> "&ext-entity;"]]></INTERNAL-ENTITY> John> John> is far more readable and writable. John> John> The spec should say that the content of an ENTITY element should be John> wrapped in a CDATA marked section. "Should" might be wording it too strongly. I agree with your point here, but I think it's orthogonal to whether internal and external entities should use the same element type. I like the value-as-content as you wrote it above, if EXTERNAL-ENTITY remains as I wrote. The reason I didn't put the value as content was due to my allowance for DOC; we'd need <!ELEMENT INTERNAL-ENTITY (DOC?, LITERAL)> <!ELEMENT LITERAL (#PCDATA)> to satisfy XML's restrictions on mixed content. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Fri Jun 5 11:57:08 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:00 2004 Subject: Roots of the DTD Message-ID: <199806050946.LAA13951@berlin.dvs1.tu-darmstadt.de> Toby Speight wrote: > Peter> At 17:27 04/06/98 -0400, John Cowan wrote: > > >> Hmmm. This sounds like the "root" (my syntax) or "RootElement" > >> (Ron's syntax) attribute in XSchema is a Bad Thing. Perhaps it > >> should be removed? > > Peter> Yup :-). I have not commented on the current proposals because > Peter> I wanted them to anneal before public comment. *For describing > Peter> a DTD*, here should be no requirement to define a <root> of any > Peter> sort, only <element>, <attribute>, <contentSpec> and possibly > Peter> <entity> and <notation> according to how people think. > > I can forsee applications where one might say, "Please send me documents > conforming to the FOO schema," in much the same way as one requests > LaTeX or Word formats these days. In which case, one usually needs also > to specify the root element (this is implied in LaTeX or Word). I don't > see any harm in the schema having a default root (on the understanding > that documents may, if they wish, use a different root). A default root might fly. Certainly a mandatory root is wrong. In many ways, the XSchema PI is like DOCTYPE -- it points to a document containing the structure of your document. As Simon suggested, it should therefore have a way to specify the root element, similar to the doc-type in the DOCTYPE declaration. Unfortunately, these raises conflicts between DOCTYPE and the XSchema PI, since they are two different ways to do the same thing. For example: <!DOCTYPE a SYSTEM "myxschema.xsc"> // root element is a <?XSchema myxschema.xsc a> // root element is a <!DOCTYPE a> <?XSchema myxschema.xsc> // root element is a <!DOCTYPE a> <?XSchema myxschema.xsc b> // root element is ??? <!DOCTYPE a SYSTEM "myxschema.xsc"> <?XSchema yourxschema.xsc b> // ????? I don't like telling people they can use DOCTYPE or XSchema PIs but not both. I also don't like having to write a long list of conflict resolutions -- it just makes XSchemas harder to use. In both cases, it feels like we are imposing requirements not in the XML spec. Ideas? -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From anders at rcs.urz.tu-dresden.de Fri Jun 5 12:14:19 1998 From: anders at rcs.urz.tu-dresden.de (Andrea Anders) Date: Mon Jun 7 17:02:00 2004 Subject: DOM Message-ID: <Pine.LNX.3.96.980605120306.29578B-100000@rcs41.urz.tu-dresden.de> Hi, thanks for the information "From SGML to XML". I have another (oafishly) question: Can anyone tell me (in simple words) what DOM is? Is there only a relation to XML or also to HTML/SGML. I've read a publication on WWW about XML-architecture. It ment the architecture consists of XML, XLL, XSL and DOM. Is this correct? How does DOM works together with XML, XLL and XSL? And is DOM a really new "thing"? Thanks Andrea ____________________________________________________________ Andrea Anders ------------- eMail: anders@rcs.urz.tu-dresden.de WWW: http://rcswww.urz.tu-dresden.de/~anders xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Fri Jun 5 12:56:37 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:01 2004 Subject: XML / XSL Disparity Message-ID: <006e01bd9070$c2ce9fa0$1e09e391@mhklaptop.bra01.icl.co.uk> >I am writing a very simple, Java based, search engine for XML >documents. Does it really need a new search engine? Much more useful would be a new filter for an existing search engine, then you could concentrate your efforts on the XML-specific functionality. >As an example, imagine a date stored as 19980604 in an XML file. >An XSL file converts that to 06-04-1998 for presentation. The user >writes that date down and later searches for it but.... > The idealistic answer is that to search for a date, you should know it's a date rather than pretending it's text. Unfortunately XML doesn't give you that information. You could try to get it from an external place, e.g. an extended XSchema. Searching on the presentation form of information rather than the stored form is always tricky. You can do it by presenting to the search engine (at indexing time) the display version of the document rather than the original XML, but this presupposes that everyone will use the same style rules for display, and that the rules are not context-sensitive (A British user would want to see the above date as 4/6/1998). Perhaps more importantly in practice, the display form of the document will have lost the semantic information inherent in the XML tags, which can potentially add greatly to the selectivity of the search. I personally think that if the paradigm is "free text searching" then it is only going to work well if the content of the displayed text and the stored text are much the same. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Jun 5 14:56:40 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:01 2004 Subject: XSchema: Proposed Outline Message-ID: <UPMAIL17.199806051255000610@classic.msn.com> Ron Bourret wrote: >This looks good to me. I would add: >* An appendix for the XSchema DTD >* An appendix for the XSchema-declared-in-XSchema document Of course! I knew there was something missing, and that's the main piece. >Also, do we need a section discussing the interaction of XSchema with other DTDs >(there was some mention yesterday of allowing an internal subset which I didn't >quite follow) or is this covered under the XSchema PI? I think we should probably handle this in the section with the PI. This is going to be a significant area in which we need to determine what kind of behavior we're supporting. XSchema Question 3 has not yet been really conclusive. Notation declarations were also suggested in private email, and I think we probably should deal with that. Thanks for the input - the spec is starting to get off the ground. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Jun 5 15:12:55 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:01 2004 Subject: Roots of the DTD Message-ID: <UPMAIL17.199806051311160275@classic.msn.com> >I don't like telling people they can use DOCTYPE or XSchema PIs but not both. I >also don't like having to write a long list of conflict resolutions -- it just >makes XSchemas harder to use. In both cases, it feels like we are imposing >requirements not in the XML spec. Ideas? Perhaps the simplest way to deal with this is to leave roots _out_ of the XSchema PI. I always thought it was kind of silly to declare it in DOCTYPE - after all, the root element should be the first and last thing you see in a document, and an application should be able to figure it out. It seems to me like redundancy, though there may be reasons for it which I haven't fathomed. The other reason for ignoring roots is that we _can't_ change DOCTYPE, so I think we'd better just stay out of its way. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mcc at arbortext.com Fri Jun 5 15:37:55 1998 From: mcc at arbortext.com (Mike Champion) Date: Mon Jun 7 17:02:01 2004 Subject: DOM In-Reply-To: <Pine.LNX.3.96.980605120306.29578B-100000@rcs41.urz.tu-dres den.de> Message-ID: <98Jun5.093218edt.26892@thicket.arbortext.com> At 06:13 AM 6/5/98 -0400, Andrea Anders wrote: >I have another (oafishly) question: Can anyone tell me (in simple words) >what DOM is? Is there only a relation to XML or also to HTML/SGML. I've read a >publication on WWW about XML-architecture. It ment the architecture >consists of XML, XLL, XSL and DOM. Is this correct? How does DOM works >together with XML, XLL and XSL? And is DOM a really new "thing"? DOM is not really a "new thing", it's an attempt to a) standardize the different "Dynamic HTML" APIs in the 4.0 versions of the major HTML browsers so that (one hopes) the 5.0 versions will allow much greater interoperability, b)to extend the idea of a standard API to XML browsers and editors, and c) to cover multiple languages, not just ECMAScript. The DOM is an abstract object model for XML and HTML documents, i.e., a description of a set of interfaces (Element, Attribute, Text, etc.) and methods that allow XML and HTML documents to be constructed, navigated, and modified via a common API across all products that support it. It is not intended to support full-blown SGML, e.g., there's no marked section interface in the API. For the moment the DOM API just describes a generic XML document or dataset, but they no doubt be extended some day to describe "power tools" for the manipulation of XLL and XSL information associated with an XML document. I hope this helps. See the DOM page at http://www.w3.org/DOM/ for more information on the current draft of the spec, the mailing list, etc. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jonathan at texcel.no Fri Jun 5 15:42:23 1998 From: jonathan at texcel.no (Jonathan Robie) Date: Mon Jun 7 17:02:01 2004 Subject: DOM In-Reply-To: <Pine.LNX.3.96.980605120306.29578B-100000@rcs41.urz.tu-dres den.de> Message-ID: <3.0.3.32.19980605094001.03a71660@pop.mindspring.com> At 12:13 PM 6/5/98 +0200, Andrea Anders wrote: >can anyone tell me (in simple words) what DOM is? The DOM is a programming API for XML and HTML documents. >Is there only a relation to XML or also to HTML/SGML. It doesn't include support for SGML, only for XML and HTML. >I've read a >publication on WWW about XML-architecture. It ment the architecture >consists of XML, XLL, XSL and DOM. Is this correct? How does DOM works >together with XML, XLL and XSL? And is DOM a really new "thing"? The DOM can be used to create, navigate, and modify XML documents. As an API, it should be useful as a way to implement XSL or XLL. Is it new? Well, it has roots in many older things, but yes, it is new. I'm enclosing a general introduction to the DOM which may answer your questions. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: what is the dom.zip Type: application/zip Size: 6740 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980605/d95bc80b/whatisthedom.zip -------------- next part -------------- jonathan@texcel.no Texcel Research http://www.texcel.no From cowan at locke.ccil.org Fri Jun 5 15:44:35 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:01 2004 Subject: XSchema: Proposed Outline Message-ID: <3577F5E0.553A5182@locke.ccil.org> Simon St.Laurent wrote: > a) missing (keep in mind that this is a _small_ project) I believe that notations and entities need representation, and both Ron's draft and mine now incorporate them. XSchemas need to be convertible to DTDs without losing material information (as opposed to structural information about the DTD itself, as indicated by parameter entities). *A fortiori*, there should be a section on translating DTDs to XSchemas as well as the other way around. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecom.mixx.de Fri Jun 5 15:54:12 1998 From: James.Anderson at mecom.mixx.de (james anderson) Date: Mon Jun 7 17:02:01 2004 Subject: Namespaces: Biting The Bullet References: <3576F2C0.9F66E617@locke.ccil.org> Message-ID: <3577F8E5.7408B5E3@mecom.mixx.de> why make this more complicated than it need be? John Cowan wrote: > > > Now, the real issue: why is a namespace element required, separate > and distinct from the namespace PI? Fundamentally, because XSchemas > (unlike DTDs) are not structurally part of the document they > describe. Therefore, they may well have their own separate and > distinct namespace PIs. > i read the namespace draft to be, in this regard, more liberal then the xml spec itself, in that it does not proscribe the appearance of namespace pi's at locations other than indicated in the modified prolog production. which means any given entity (either the external entity which comprises the dtd or an internal entity denoting an element) could well contain a namespace pi. as a side effect of which a binding of prefix to namespace could be established for the dynamic scope of the entity. if you make this one mechanism work correctly, why would you need a second one? >... > In principle, the same effect could be achieved by putting actual > namespace PIs into the XSchema, since a namespace PI, like any > other PI, is passed along to the application (in this case, an > XSchema validator application). as long as your parser "passes" the pi in the correct dynamic scope (which some do not (yet) do) this suffices to support dynamically scoped namespaces. > However, this is contrary to > the spirit of XSchema, which is to express everything using > element/attribute syntax. then you should eliminate pi's in all cases. > Furthermore, the use of actual > namespace PIs would license an XML parser to pass through elements > and attributes tagged with those prefixes, whereas the prefixes > should appear in the XSchema only within attribute values, where > they are hidden from the XML parser. > > XSchemas may well need other namespace PIs of their own. For > example, if a DOC element contains other elements to indicate > formatting, these presumably come from some namespace other than > the XSchema namespace. If so, a PI will be in order to declare > that namespace and some prefix for it. If the XSchema is > describing that very namespace ... well, that leads to a mixed-level > cross-reference. Keeping the PI distinct from the element solves > the problem. an example would help here. i don't (yet) see a 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 15:58:25 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:01 2004 Subject: Roots of the DTD References: <199806050946.LAA13951@berlin.dvs1.tu-darmstadt.de> Message-ID: <3577F82B.6F2010D7@locke.ccil.org> Ron Bourret wrote: > A default root might fly. Certainly a mandatory root is wrong. > > In many ways, the XSchema PI is like DOCTYPE -- it points to a document > containing the structure of your document. As Simon suggested, it should > therefore have a way to specify the root element, similar to the doc-type in the > DOCTYPE declaration. I agree. > Unfortunately, these raises conflicts between DOCTYPE and the XSchema PI, since > they are two different ways to do the same thing. I think this is just a special case of XSchema PI vs !DOCTYPE conflict in general. After all, a document might insist that it conforms to a.dtd and b.xschema.xml, where a is not in any way transformable to b. With a well-chosen document and a and b, the document might even pass validation. > I don't like telling people they can use DOCTYPE or XSchema PIs but not both. I > also don't like having to write a long list of conflict resolutions -- it just > makes XSchemas harder to use. In both cases, it feels like we are imposing > requirements not in the XML spec. Ideas? I say, give the users plenty of rope, and if they hang themselves, they hang themselves. However, I would say that a document conforms to an XSchema if its actual root is an element defined in the XSchema, even if the XSchema-PI doesn't declare any root. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 16:09:44 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:01 2004 Subject: Apologia pro vita mea (was: XML-DEV as virtual community) References: <3.0.1.16.19980604172602.8ca793e4@pop3.demon.co.uk> <3.0.1.16.19980605070506.1df71052@pop3.demon.co.uk> Message-ID: <3577FBC2.C29DA265@locke.ccil.org> Peter Murray-Rust wrote: > It's interesting that many of > the people involved are quite distinct from those involved in SAX. I think > this represents an influx of talent that may have come from the non-SGML > community and in this sense it may bring fresh insights. As one of those folks from the non-SGML community, let me document my involvement with XML. I hope that this will provide a sample of where the "influx of talent" is coming from. I was helping to design a project, the details of which I can't reveal, but which involved various communicating processes. Other team members had sketched out rough syntaxes for the basic message format. One was a classic binary format with explicit length words, absolute byte offsets within the message, and no thought given to endianism issues. The other was a classic comma-separated, double-quote-employing, backslash-escaping plain text design. I looked at these two and blurted, "Aren't these rather archaic? What about XML?" At that point I knew almost nothing about XML except that it was SGML--, and nothing about SGML except that it was the foundation of HTML. On this project it happened that new ideas were important, for non-technical reasons. The team leader told me to go forth and learn, which I have done. The project has been handed off to an implementation group and now lives in Approval Limbo, but I'm still learning XML. I've prepared a presentation on XML for my company, which I hope to be able to make public later on. > [1] The infrastructure of the Web (e.g. the protocols) is , of course, very > carefully regulated and cannot vary. It corresponds to the basic machinery > of any organism - essentially all use the same genetic code. But above that > there is great flexibility. Actually, the protocols vary more than you may think, and by much the same Darwinian process. Efforts are now underway to revise the very format of email messages (with plenty of respect for backward compatibility, never fear), and of course TCP/IP has already been revised, though the new version is not yet in widespread use. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 16:19:46 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:01 2004 Subject: Roots of the DTD References: <UPMAIL17.199806051311160275@classic.msn.com> Message-ID: <3577FE30.2DE080F8@locke.ccil.org> Simon St.Laurent wrote: > Perhaps the simplest way to deal with this is to leave roots _out_ of the > XSchema PI. I always thought it was kind of silly to declare it in DOCTYPE - > after all, the root element should be the first and last thing you see in a > document, and an application should be able to figure it out. It seems to me > like redundancy, though there may be reasons for it which I haven't fathomed. Well, redundancy is the basis of validation: no redundancy, nothing to validate against (validation really = internal consistency, since the DTD is part of the document logically). But I agree that redundancy within the document entity doesn't buy that much, as opposed to redundancy between the doc entity and the external DTD/XSchema entity. So for my part, the root attribute goes. This, I think, is also an argument against internal XSchema subsets unless limited to entity declarations. Entity declarations provide essential as opposed to redundant information. And that said, with system identifiers URIs, it's just as easy to put your local entity declarations for foo.xml into foo.entities.xml, a small XSchema. Of course, to do that we must be able to have multiple XSchema PIs or else XSchema inclusion, or preferably both. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Jun 5 17:12:21 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:01 2004 Subject: XSchema Question 6: Entities Message-ID: <UPMAIL17.199806051510050587@classic.msn.com> John Cowan wrote: >I believe that notations and entities need representation, and both >Ron's draft and mine now incorporate them. XSchemas need to be >convertible to DTDs without losing material information (as opposed >to structural information about the DTD itself, as indicated by >parameter entities). Question: Should entity support be provided in XSchema? The goals do not require entity support. During the goals process, a number of people suggested staying out of the entity business, though a few also thought it was important. Both Ron and John have included entity support in their DTD's. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Jun 5 17:13:51 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:01 2004 Subject: XSchema: Proposed Outline Message-ID: <UPMAIL17.199806051511130837@classic.msn.com> John Cowan wrote: >*A fortiori*, there should be a section on translating DTDs to >XSchemas as well as the other way around. The goals only commit us to XSchema->DTD translation. While I don't mind including a section on DTD->XSchema translations, I don't want to get bound up trying to translate every bit of a DTD, even a normalized DTD, to an XSchema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Jun 5 17:26:55 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:02 2004 Subject: Namespaces: Biting The Bullet Message-ID: <UPMAIL17.199806051525180618@classic.msn.com> >> XSchemas may well need other namespace PIs of their own. For >> example, if a DOC element contains other elements to indicate >> formatting, these presumably come from some namespace other than >> the XSchema namespace. If so, a PI will be in order to declare >> that namespace and some prefix for it. If the XSchema is >> describing that very namespace ... well, that leads to a mixed-level >> cross-reference. Keeping the PI distinct from the element solves >> the problem. > >an example would help here. i don't (yet) see a problem. Before we get caught up in this for XSchemas, I'd like to hear some discussion of how namespaces work with plain old DTDs, and how best to handle documents and DTDs with mixed namespaces. 'This ambiguity is not always a problem' (2.5) sounds like a problem that we'll have to resolve for XSchemas, and I'm hoping that the method prescribed in the draft for DTDs will get us through. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Fri Jun 5 17:39:11 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:02 2004 Subject: XSchema: Proposed Outline Message-ID: <199806051532.RAA15804@berlin.dvs1.tu-darmstadt.de> Simon St. Laurent: > The goals only commit us to XSchema->DTD translation. While I don't mind > including a section on DTD->XSchema translations, I don't want to get bound up > trying to translate every bit of a DTD, even a normalized DTD, to an XSchema. I missed this -- I thought we wanted to do both directions (at least from a normalized DTD). My reason for wanting this is so that a specialized parser can read an existing DTD and give me XSchema SAX events, which I can then build into a tree and explore. In fact, I regard this as initially more important than the other direction since most people use DTDs, not XSchema. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Fri Jun 5 17:55:25 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:02 2004 Subject: off-topic (was RE: Roots of the DTD) In-Reply-To: <UPMAIL17.199806051311160275@classic.msn.com> Message-ID: <000401bd909a$9a1b5dd0$78bc38cb@NT.JELLIFFE.COM.AU> Just to fill in the gaps. > From: Simon St.Laurent > I always thought it was kind of silly to declare it > in DOCTYPE - > after all, the root element should be the first and last thing > you see in a > document, and an application should be able to figure it out. It > seems to me > like redundancy, though there may be reasons for it which I > haven't fathomed. > > The other reason for ignoring roots is that we _can't_ change > DOCTYPE, so I > think we'd better just stay out of its way. SGML and HTML allow tags to be missing. So you do not know what the top element is, just by looking at the first tag. So this information needs to be provided elsewhere: hence the element type name in the DOCTYPE declaration. SGML also allows <!DOCTYPE #IMPLIED SYSTEM> (I think this is default) which means that if the first start-tag is the root element (the "document element") and that if there is a DTD, the system knows about it independently of having to name it. XML does not allow tag ommission, or the #IMPLIED form. Rick Jelliffe ========================================================== The XML & SGML Cookbook, by Rick Jelliffe Charles F. Goldfarb Series on Open Information Management 656 pages + CD-ROM, Prentice Hall 1998, ISBN 0-13-614223-0 http://www.sil.org/sgml/jelliffeXMLAnn.html http://www.phptr.com/ > Book Search > "Jelliffe" http://www.amazon.com/exec/obidos/ASIN/0136142230/002-4102466-3352420 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Jun 5 18:26:55 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:02:02 2004 Subject: Namespaces and PURLs Message-ID: <3.0.32.19980605091804.00b66ec0@pop.intergate.bc.ca> At 03:15 PM 6/4/98 UT, Simon St.Laurent wrote: >>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). > >This sounds like I can use a PURL A PURL sounds highly appropriate to me for namespace identification. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From alain at cabinfo.com Fri Jun 5 18:29:01 1998 From: alain at cabinfo.com (Alain DESEINE) Date: Mon Jun 7 17:02:02 2004 Subject: XSchema Question 6: Entities References: <UPMAIL17.199806051510050587@classic.msn.com> Message-ID: <35781C11.F06@cabinfo.com> Simon St.Laurent wrote: > > John Cowan wrote: > >I believe that notations and entities need representation, and both > >Ron's draft and mine now incorporate them. XSchemas need to be > >convertible to DTDs without losing material information (as opposed > >to structural information about the DTD itself, as indicated by > >parameter entities). > > Question: Should entity support be provided in XSchema? > > The goals do not require entity support. During the goals process, a number > of people suggested staying out of the entity business, though a few also > thought it was important. Both Ron and John have included entity support in > their DTD's. I'm not sure that entities support is so important. Just remember what we say some days ago. At this time we only need XShemas for about 2 tasks : - Validating XML documents against something else more readeable than a DTD - Providing Documentation mechanism that does not exist in DTDs One of our major goal at these time was "doing something simple ..., but powerfull" So I'm not for adding Entities support in XSchema. I think that XScema should stay simple. Alain xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Fri Jun 5 18:38:25 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:02 2004 Subject: XML-DEV as virtual community (was Re: XSchema Question 2: Namespaces) Message-ID: <000201bd909f$40433cb0$2ee044c6@arcot-main> >Implementing XSL requires it to have the functionality of DSSSL. Take >a look at Jade. Are you telling me that the collective resources of >this entire group aren't adequate to the production of something that >equals what James Clark can do by himself? Since James Clark is a member of the group, it would be rather difficult not to equal James' own incredible engineering feat unless XML-DEV is a government experiment on devolution of human brain. <g> If we are to assume that each of the group's member make about 100K a year in the average, 1200 members' collective expertise would cost around 120 million dollars a year. Financial impact of the group on all of the industries affected by XML now or in the future should be well over a billion easily. As my son shouts every minute, "Go, Power Rangers!" Don Park http://www.docuverse.com/personal/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Daniel.Brickley at bristol.ac.uk Fri Jun 5 18:41:32 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:02:02 2004 Subject: Namespaces and PURLs In-Reply-To: <3.0.32.19980605091804.00b66ec0@pop.intergate.bc.ca> Message-ID: <Pine.HPP.3.96.980605173101.3132L-100000@mail.ilrt.bris.ac.uk> On Fri, 5 Jun 1998, Tim Bray wrote: > At 03:15 PM 6/4/98 UT, Simon St.Laurent wrote: > >>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). > > > >This sounds like I can use a PURL > > A PURL sounds highly appropriate to me for namespace identification. -Tim The only complication I can think of is the use of the '#' fragment identifier in the 'src=' attribute... Not sure if it makes sense to use '#' in this context anyway, but the following from the PURL FAQ is probably worth bearing in mind. Dan >From the PURL FAQ at http://purl.oclc.org/OCLC/PURL/FAQ#toc5.7 5.7 Can I use local references in conjunction with a PURL? (i.e., http://purl.foo.com/ME/HOME#LREF) There's more to this question than meets the eye. Let's break it down into manageable pieces. First, the local reference (i.e. #LREF) is a directive to the HTTP client (browser). When you select a URL containing a local reference, only the portion of the URL preceding the local reference is requested from the HTTP server. It is the client's responsibility to act on this directive in relation to the requested document once the document is received. Therefore this behavior is dependent upon the client. Not all clients handle local references the same way. PURLs can not contain local references because we do not allow them to contain the "#" character. Since browsers would not send the local reference (i.e., anything after and including a "#" character, such as #LREF) part of a PURL to the PURL resolver, there'd be no point in allowing it. You can use local references appended to PURLs so that your browser attempts to locate the local reference within the document retrieved by the PURL, but some browsers (incorrectly) drop the local reference upon receiving the redirect from the PURL resolver (actually any redirect from any HTTP server) and therefore fail to act on the local reference directive when the actual document is received. As a result, PURLs with local references appended to them, such as http://purl.oclc.org/OCLC/PURL/FAQ#toc6.0, resolve to (the beginning of) the document referenced by the PURL under some Web browsers. To determine how your browser behaves, try the example PURL above. If it takes you to the top of this document, then your browser is not handling local references correctly. If it takes you to section 6.0 of this document, then your browser is handling local references correctly. Either way, you should still end up with this document. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From macherius at darmstadt.gmd.de Fri Jun 5 19:03:33 1998 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:02:02 2004 Subject: ANN: Draft Sildeset for Links and Relations in XML Message-ID: <199806051701.TAA22423@sonne.darmstadt.gmd.de> Hello, I've prepared a *DRAFT* set of slides in PDF that deal with XML Linking, RDF an related fields. I'm looking for volunteers to review them and hopefully (not ;) to correct them. When I'm sure that there are no serious misunderstandings or errors and I haven't left out something, I'll release the slides under GPL. Things I'm not sure of (Numbers reflect slide numbers) 4 : Is the notation urn:http://foo.com/ correct ? 6 : What really is the difference between document and group ? : Do you consider the visualization an oversimplification ? 7 : Any idea how to generally visiualize the concept of a link without discriminating inline/off-line and simple/extended ? : May a locator really be a link of type locator ? 9 : Have I missed a feature ? 10: Formalisms tend to be erroneous, please check. 11: " " " " " " " . 12: Maybe someone has a good summary of the state of discussion ? Disclaimer: The material reflects my personal understanding only and may be completely wrong. Commercial use is prohibited. The given URL is certain to change soon, so don't link now. Please don't ask how PDF is displayed or the like :) Thanks, ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@darmstadt.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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 19:06:33 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:02 2004 Subject: XML-DEV as virtual community (was Re: XSchema Question 2: Namespaces) References: <000201bd909f$40433cb0$2ee044c6@arcot-main> Message-ID: <357824D9.142A09B2@locke.ccil.org> Don Park wrote: > As my son shouts every minute, "Go, Power Rangers!" Hmm. Try getting him to say '<Go Rangers="Power"/>'! -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From macherius at darmstadt.gmd.de Fri Jun 5 19:09:15 1998 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:02:02 2004 Subject: ANN: Draft Sildeset for Links and Relations in XML Message-ID: <199806051704.TAA22473@sonne.darmstadt.gmd.de> > I've prepared a *DRAFT* set of slides in PDF that deal with XML > Linking, RDF an related fields. I'm looking for volunteers to review Err, yes there is an URL ... http://www.darmstadt.gmd.de/~inim/temporary/ Sorry, ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@darmstadt.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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 5 19:09:19 1998 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:02:02 2004 Subject: XSchema Question 6: Entities Message-ID: <01bd90a4$40ea11c0$020b0ac0@xerius.ini.cz> >Question: Should entity support be provided in XSchema? > >The goals do not require entity support. During the goals process, a number >of people suggested staying out of the entity business, though a few also >thought it was important. Both Ron and John have included entity support in >their DTD's. This essentially boils down to a philosophical question: is XSchema mainly a new XML-based syntax for working with DTDs or is it the start of a new paradigm for working with XML. My strong preference would be for the latter, including jettisoning baggage from SGML which was included in the XML spec for compatibility reasons but which does not necessarily make sense for new XML applications. Seen in this light, I don't see any reason to include entities in XSchema. Entities are really too powerful and including them as a native construct in the schema makes a lot of infrastructure projects far more complicated (SAX, DOM, etc., etc.). Part of the paradigm shift that I am hoping will take place is a move away from entities and towards more structured linking mechanisms (i.e. XLink and XPointer). This presupposes a certain number of things that most of us seem to take for granted anyway, such as the fact that graphical authoring environments will replace hand-coding of XML for most non-trivial tasks. To this I would add mixing-and-matching of schemas; entities are abused far too much because of this current lack. The prospect of having an XML-based syntax that takes over the roll of the DTD for defining schema information is very exciting because the prospects for exploiting the synergies rising from this are enormous. It becomes even more so if: 1) Parameter entities become reusable schema fragments (I hacked together an example of this using XLink in a previous post), 2) General entities become XLinks, reducing the free-for-all flavor of XML and enforcing structure. 3) Character entities become transparent to the author and consumer. BTW: I feel the same way about notations. Why not leave them out in favor of a real typing system to be added to the XSchema core sometime in the future? Specifying some basis atomic types, a mechanism for defining structured types (preferably based on reuse of schema fragments) and a tie-in to MIME types surely wouldn't be a project of any more complexity that the basis XSchema specification. 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 19:16:16 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:02 2004 Subject: XSchema Question 6: Entities References: <UPMAIL17.199806051510050587@classic.msn.com> Message-ID: <35782718.D5129CD4@locke.ccil.org> Simon St.Laurent wrote: > Question: Should entity support be provided in XSchema? Yes. Without support for general entities in XSchemas, an XSchema-based validator cannot exist unless it also reads the DTD. Required attributes or content may be hidden inside entities, causing a validator oblivious to entities to give a false negative result. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 19:20:09 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:02 2004 Subject: Notations, subschemas, entities References: <3576FB58.39B139D4@locke.ccil.org> <ud8cojhu2.fsf@digitivity.com> <35781A0F.39168ED4@locke.ccil.org> <ulnrbero9.fsf@digitivity.com> Message-ID: <35782845.890078D0@locke.ccil.org> Toby.Speight@digitivity.com wrote: > Perhaps you've misinterpreted me; that's exactly what I was thinking > of, but I didn't find it required XSchema in its own content-model. > My suggestion is like this: [example snipped] > I think that's neater than nesting XSchemas. Neater in one way, but it requires forethought rather than afterthought. Since XSchemas are now to be rootless, yanking in the whole XSchema to use just part of it begins to make sense. I think it's time for me to post a real example of a reusable DTD. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 19:38:55 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:02 2004 Subject: The Itsy Bitsy Teeny Weeny Simple Hypertext DTD Message-ID: <35782CCE.EEBAA0B6@locke.ccil.org> I have posted an XML DTD for simple hypertext at http://www.ccil.org/~cowan/ibtwsh.dtd . This is a small subset of HTML 4.0 Transitional, suited to embedding rich-text doco into XML documents. My next draft (hopefully today) of the XSchema DTD will incorporate this by reference. >From the introduction: This is an XML DTD which describes a subset of HTML 4.0 for embedded use within other XML DTDs. It is by intention equivalent (within its scope) to -//W3C//DTD HTML 4.0 Transitional//EN, but is not a derived work in the copyright sense. (Brief excerpts from HTML 4.0 Transitional appear here and there.) It is often convenient for XML documents to have a bit of documentation somewhere in them. In the absence of a DTD like this one, that documentation winds up being #PCDATA only, which is a pity, because rich text adds measurably to the readability of documents. By incorporating this DTD by reference (as an external parameter entity) into another DTD, that DTD inherits the capabilities of this one. Using HTML-compatible elements and attributes allows the documentation to be passed straight through to HTML renderers. Current HTML renderers can cope with most XML tags, but empty tags require special treatment. Inserting a space before the terminating "/>" usually makes the "/" (which is not HTML) invisible. Using "<TAG></TAG>" is not as effective, as the latter is often misinterpreted as a second "<TAG>". Note that since the elements of this DTD are intended to be used within domain-specific elements of the surrounding DTD, there is no "root element" corresponding to the HTML element in HTML. Recommended content models for elements containing documentation are "%horiz.model;" for simple text fragments, and "%struct.model;" for documents in extenso. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jun 5 19:39:05 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:03 2004 Subject: XSchema: Proposed Outline In-Reply-To: <UPMAIL17.199806042008220083@classic.msn.com> Message-ID: <3.0.1.16.19980605183741.314f4a44@pop3.demon.co.uk> At 20:09 04/06/98 UT, Simon St.Laurent wrote: >A proposed outline for the XSchema specification follows. I hope to begin >filling in the spaces over the weekend, so I'd appreciate hearing about I shall not be online for about 6-7 days (unless I'm fortunate in connections), so wish you well for the next stage. Here is my postal vote: - if there is a decision between power and simplicity, I vote simple - don't try anything adventurous at this stage (i.e. more adventurous that this adventure) Best of luck. I'll read most of it when I'm back. I shall hopefully do some evangelising for XML (I'm talking to the International Federation of Science Editors). P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jun 5 19:43:12 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:03 2004 Subject: XSchema Question 6: Entities Message-ID: <3.0.1.16.19980605184024.09c74662@pop3.demon.co.uk> [From Chris Maden] >Return-Path: <crism@ruby.ora.com> >Date: Fri, 5 Jun 1998 13:36:22 -0400 (EDT) >From: Chris Maden <crism@oreilly.com> >To: peter@ursus.demon.co.uk >Subject: Re: XSchema Question 6: Entities > >[Simon St.Laurent] >> Question: Should entity support be provided in XSchema? > >No. General entities should be usable, as XSchema is an XML document. >However, one of the problems with DTDs as they currently exist is >their confusion in declaring both the structure of a document class, >and in declaring entities primarily useful for a particular instance. > >The schema itself is really applicable to a class of documents, and >should restrict itself to such. Don't re-invent the DTD; that's not >useful. If this is successful, XML syntax for entity declarations may >be a useful exercise, but it should be distinct from schemas. > >-Chris >-- ><!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> ><!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" >"<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 ><USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 20:50:14 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:03 2004 Subject: The Itsy Bitsy Teeny Weeny Simple Hypertext DTD References: <3.0.32.19980605110922.00b08100@pop.intergate.bc.ca> Message-ID: <35783D84.C05762F6@locke.ccil.org> Tim Bray wrote: > Nice work; a couple of comments: Thank you. Praise from Sir Roger is praise indeed. > 1. Why do you have the (barf) FONT element in the days of stylesheets? I would rather have had CONTRAST (different text color), IMPORTANT (bigger font), and UNIMPORTANT (smaller font) tags, but nobody added such generic local markup to HTML 4.0. I have added some comments. Michael Everson, BTW, says that red color is a plaintext element in Egyptian hieroglyphics and Naxi texts (from China), and someday Unicode may well get control characters for BEGIN RUBRIC and END RUBRIC, to be rendered as a long overhead line in B/W environments. See http://wwwold.dkuug.dk/JTC1/SC2/WG2/docs/n1636/n1636.htm . I note that ABBR and ACRONYM did get into HTML 4.0, and I am adding them to ibtwsh.dtd forthwith. > 2. The html character entities that you reference unfortunately are > non-XML-conformant, because they are all declared like so: > > <!ENTITY copy CDATA "©" -- copyright sign, U+00A9 ISOnum --> > There are two obvious problems here... -Tim Um, yes. Somebody someday will have to fix that. For now, the intent is clear, and nsgmls does not enforce the prohibition even when running in XML mode. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 21:04:36 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:03 2004 Subject: Comments on VHG DTD 1.0alpha Message-ID: <357840B8.4BD8337B@locke.ccil.org> Generic site comment: Fetching TM out of the Symbol font works only with browsers that accept the nonstandard "face" attribute of FONT. Netscape shows an ä instead, which is very ugly. I suggest "(TM)" as a plain-text workaround, since unlike ® the TM-symbol has no legal standing. (Of course, ™ would be the Right Thing.) I think that the entryID attribute is a mistake. Even non-validating parsers will still return the correct value for the "id" entry. People who want to use IDs that aren't XML Names can **** well encode them. When the Itsy Bitsy stabilizes, you may want to use it as the content model for the admin, definition, and note elements. I believe that you should force (using #FIXED) inline=true for simple links, and inline=false for extended links. This is a general view of mine. An excellent piece of work! -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecom.mixx.de Fri Jun 5 21:54:57 1998 From: James.Anderson at mecom.mixx.de (james anderson) Date: Mon Jun 7 17:02:03 2004 Subject: ? XLink/Pointer expressiveness Message-ID: <35784D88.C128B44A@mecom.mixx.de> greetings, i have a question for the "xlink/x-pointer" proficient: how would i express several references to subelements of a remote resource? if xml were referentially transparent, something like (taking an simplistic case) <patient id="01"> <name> <first>edward</first> <last>dolittle</last> </name> <history id="02" href="http://hostpital/patients?name=edward.dolittle" /> <last-treatment href="http://hostpital/patients?name=edward.dolittle#child(-1,treatment)" /> </patient> wouldn't trouble me. but xml is not, so i would like to do something like: <patient id="01"> <name> <first>edward</first> <last>dolittle</last> </name> <history id="02" href="http://hostpital/patients?name=edward.dolittle" /> <last-treatment href="id(02).child(-1,treatment)" /> </patient> which makes intuitive sense, but not necessarily structural sense - depending on the document model and link behaviour. ? are the fine points to link behaviour / type which are intended to govern such situations? ? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jun 5 22:13:01 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:03 2004 Subject: Comments on VHG DTD 1.0alpha In-Reply-To: <357840B8.4BD8337B@locke.ccil.org> Message-ID: <3.0.1.16.19980605210532.314f92ac@pop3.demon.co.uk> Thanks very much for your comments, John. At 15:02 05/06/98 -0400, you wrote: >Generic site comment: Fetching TM out of the Symbol font works only >with browsers that accept the nonstandard "face" attribute of FONT. >Netscape shows an ä instead, which is very ugly. I suggest >"(TM)" as a plain-text workaround, since unlike ® the TM-symbol >has no legal standing. (Of course, ™ would be the Right Thing.) Over to you, Lesley :-) > >I think that the entryID attribute is a mistake. Even non-validating <entryID> is an element and can be anything that #PCDATA can accept. There can also be multiple entryIDs. I think you mean the id attribute on termEntry... >parsers will still return the correct value for the "id" entry. >People who want to use IDs that aren't XML Names can **** well >encode them. I struggled with this one. We have little experience communally of how much ID is going to be used in XML. The key aspect of IDs is that they must be unique - and parsers must report errors here. This was the bargain I had to make - uniqueness versus flexibility of content. It is very important to have handles on the termEntrys, so id really forces people to have to do it. (They can't put in entailment without it). And remember that the authors will be curators, who care about content and robustness and related things. So a unique string is not a tragedy. Of course it can be relaxed later. But tightening up is always more difficult. So the authors are going to have to find a way of uniquifying. term1, term2 ... is the simplest. Do the current authoring tools support uniqueness? > >When the Itsy Bitsy stabilizes, you may want to use it as the >content model for the admin, definition, and note elements. Indeed. I am also disappointed at the slow progress towards an DTD for XHTML... > >I believe that you should force (using #FIXED) inline=true for >simple links, and inline=false for extended links. This is a >general view of mine. Thanks. Again we have no experience. The simple links are not embedded in mixed content, so does it matter? But I can and probably will do it. I also agree with you about extended. I think the whole Xlink spec is too text-oriented. I've argued to make it more general. P. > >An excellent piece of work! > >-- >John Cowan http://www.ccil.org/~cowan cowan@ccil.org > You tollerday donsk? N. You tolkatiff scowegian? Nn. > You spigotty anglease? Nnn. You phonio saxo? Nnnn. > Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 22:56:45 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:03 2004 Subject: Unified XSchema draft available Message-ID: <35785599.CB2A130B@locke.ccil.org> Although there are still a few things Ron and John disagree on, I have written a unified draft, basically by taking Ron's draft and hacking on it a bit. Ron hasn't seen it yet, though, so it may change further in the process of converging. The URL: http://www.ccil.org/~cowan/XSchema-draft-DTD-19980605.txt . You may also need: http://www.ccil.org/~cowan/ibtwsh.dtd . In the interests of speed, I have not published new prose or a new meta-XSchema yet. New and changed stuff from Ron's last draft (*s mark what Ron has NOT approved-in-principle yet): *1. Attribute types need not be declared; the implicit default is CDATA. *2. CDATA attributes can mention a syntax (no limitations on this yet, but intended for things like "URL", "ISO8601" (date), etc.) 3. #PCDATA within the schema is used only for the value of internal entities now. *4. The Frequency attribute can be omitted in content models, and defaults to "Required". 5. ElementRef is now just Ref. 6. Enumeration is now EnumerationValue, for consistency. 7. The Namespace element is in. 8. The Doc element is allowed at the head of XSchema, ElementDecl, AttDef, EnumerationValue, GEDecl, Notation, and Namespace elements. Its content model is %horiz.model; from Itsy Bitsy, which allows simplified versions of the HTML 4.0 elements CITE, CODE, DFN, EM, KBD, SAMP, STRONG, VAR, FONT, A, BR, and SPAN, plus of course #PCDATA. *9. XSchemas can be nested in XSchemas. 10. The RootElement attribute is gone. *11. Seq and Choice must have at least two children. 12. Many comments added. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 23:00:01 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:03 2004 Subject: My comments on the XLink and XPointer drafts Message-ID: <35785A8E.92A87D7C@locke.ccil.org> I sent these to Maler & DeRose on 1998-03-30, and have so far received only an acknowledgement. I now post them to the listfolk for their edification and comments. Title: Cowan's Comments 1-8 on XLink/XPointer Drafts Source: John Cowan <cowan@ccil.org> Primary Author: John Cowan (no W3C affiliation) Date: 1998-03-25 Status: Expert contribution Action: For the consideration of W3C XML WG References: Draft WD-xlink-19980303, Draft WD-xpointer-19980303 Distribution: W3C XML WG, XML-DEV, and all interested parties The following comments are offered to the W3C XML WG for consideration. Since I do not currently have access to the mailing list, I would appreciate a direct reply to <cowan@ccil.org> with the disposition of these comments. [Replying to XML-DEV is okay too.] For reference, comments are labeled "Cowan-<draftname>-<status>-<serialno>" where <draftname> is "XLink" or "XPointer" and <status> is "Editorial" or "Substantive". Serial numbers are unique throughout. Substantive comments are listed in roughly increasing order of complexity. Cowan-XPointer-Editorial-1: Origin Clarification Section 3.2.2, on the "origin" keyword, uses the phrase "the location source is the sub-resource from which the user initiated traversal". In the case of a generalized link, it is not clear whether this refers to the actual link element, or the locator sub-element where the XPointer is physically located. It seems to me that the actual link element, which is typically directly visible to the user, is what is meant; in either case, clarification is in order. Cowan-XLink-Editorial-2: Role Information Non-normative Sections 4.1.2, 4.1.3, and 4.1.4 should make clear that role information is non-normative, like title information, by adding some such sentence as: "XLink does not require that application software make any particular use of role information." Cowan-XLink-Editorial-3: Additional Attribute-Remapping Example An additional example should be provided in Section 7 for attribute remapping. The given example does not clearly state why remapping is required, as the existing "title" and "role" attributes of the TEXT-BOOK element are at least formally suitable for XLink. An example using one of the more syntactically limited attributes such as "show" in an incompatible way would clarify the purpose of attribute remapping. Here is a sample declaration: <!ELEMENT WIDGET ANY> <!ATTLIST WIDGET position CDATA #IMPLIED class CDATA #IMPLIED show (SHOW|HIDE) "SHOW" ... > Using this element as a link would require remapping the XLink "show" attribute to something else. Cowan-XLink-Substantive-4: "xml:attributes" Should Be NMTOKENS The "xml:attributes" attribute is defined as CDATA, although its content is essentially a list of alphanumeric strings separated by white-space. Declaring it as NMTOKENS would permit validating XML parsers to take a first cut at making sure the syntax was correct. [Previous sentence has been altered to remove an error of mine.] Cowan-XLink-Substantive-5: All Attributes In XML Namespace Attribute remapping could be avoided altogether by using attributes solely from the "xml:" pseudo-namespace, namely "xml:href", "xml:inline", "xml:role", "xml:title", "xml:show", "xml:actuate", "xml:behavior", "xml:content-role", "xml:content-title" and (if other comments are adopted) "xml:link-title" and "xml:link-role". This change would increase verbosity, but we already have the precedent of the "xml:lang" attribute, which (unlike "xml:link" and "xml:space") can be expected to often appear explicitly in start-tags. Cowan-XLink-Substantive-6: New "link-title" Attribute The current draft allows titles to be specified for any of the resources of a link, whether local (through the "content-title" attribute) or remote (through the "title" attribute). However, there is no way to specify the title of the link itself. Both links and resources can be given roles, and in that respect are treated on an equal footing. It seems to me conducive to uniformity to treat links and resources equally in the matter of titles as well. My proposed attribute for this purpose is "link-title", which would be defined as part of the parameter entities "link-semantics.att" and "simple-link-semantics.att" in Section 4.1.2. Cowan-XLink-Substantive-7: Ambiguous "role" Attribute The attribute "role" is used in two different ways within XLink. In a simple link, "role" means the role of the content, whereas in an extended link, "role" means the role of the link itself. There is no way to mention the role of the link itself within a simple link, due to this conflation. I propose that the second usage be changed to employ the attribute "link-role". This name is analogous to "content-role", and is usable in both simple and extended links. The "role" attribute would then be reserved for simple link elements and locator elements, and would always refer to the role of the remote content. Section 4.1.2 would be affected by adding the attribute "link-role" to the parameter entity "link-semantics.att" and removing the attribute "role". The parameter entity "simple-link-semantics.att" would become unnecessary, and all references to it (e.g. in Section 4.2) would be changed to "link-semantics.att". Cowan-XLink-Substantive-8: "inline" Attribute Unnecessary I propose that the inline/out-of-line and simple/extended link distinctions be unified according to the following rule: all simple links are inline, all extended links are out-of-line. Making this change will promote simplicity (making the job of link readers easier) with very little cost to flexibility. Section 4.2 concedes that simple out-of-line links are "uncommon"; they are essentially links with only one resource. Since the physical location of such a link is irrelevant to its meaning, finding it entails the same difficulty as finding extended links. The syntax <one-ended-link href="..." .../> can be readily converted to: <extended-link ...> <locator href="..." .../> ... </extended-link> Similarly, extended links that need to reference their own content as a resource can readily do so by adding an extra locator element as follows: <inline-extended-link ...> ... </inline-link> becomes: <general-link ...> <locator href="#origin()"> ... </general-link> (Depending on the resolution of comment Cowan-XPointer-Editorial-1, the XPointer might need to be "#origin().ancestor(1)".) This would entail, however, that locator elements within the extended link would appear to be part of its resources. Link-following applications would need to be aware of this point and implicitly ignore locator elements. Alternatively, XPointer syntax could be enhanced, if necessary. Adopting this change would require various changes to the draft wording, including but not necessarily limited to: Section 4: change "usually inline" to "always inline" and "either inline or out-of-line" to "always out-of-line". Section 4.1.2: remove references to the attribute "inline" from the prose and the parameter entities "link-semantics.att" and "simple-link-semantics.att". Section 4.2: remove the explanation of out-of-line simple links; some of the content can be moved to the end of Section 4.3 as an explanation of what extended links with a single locator mean. **END OF DOCUMENT** -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jun 5 23:18:02 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:03 2004 Subject: Comments on VHG DTD 1.0alpha References: <3.0.1.16.19980605210532.314f92ac@pop3.demon.co.uk> Message-ID: <35785918.42F29AFF@locke.ccil.org> Peter Murray-Rust wrote: > <entryID> is an element and can be anything that #PCDATA can accept. Sorry, I meant element, of course. Your annotated DTD (which I worked from) says that the entryID element semantically overlaps the id attribute of termEntry, and that strikes me as bad; not fatal, just regrettable. > I struggled with this one. We have little experience communally of how much > ID is going to be used in XML. > The key aspect of IDs is that they must be unique - and parsers must > report errors here. Actually, only validating parsers must enforce the uniqueness and related ID/IDREF constraints. Nitwitted but fast parsers are free to pretend everything is CDATA, and there is very little that #PCDATA can do that CDATA can't (external entity references in IDs? Yuk!). > This was the bargain I had to make - uniqueness versus > flexibility of content. It is very important to have handles on the > termEntrys, so id really forces people to have to do it. (They can't put in > entailment without it). And remember that the authors will be curators, who > care about content and robustness and related things. So a unique string is > not a tragedy. Sounds like you're making my case here: keep the ID attribute, drop the sub-element. > Do the current authoring tools support > uniqueness? AFAIK no, but running through nsgmls afterwards isn't *that* hard. > >When the Itsy Bitsy stabilizes, you may want to use it as the > >content model for the admin, definition, and note elements. > > Indeed. I am also disappointed at the slow progress towards an DTD for > XHTML... So am I. There's a stalled project to create an SGML DTD to be a "static subset" of HTML for writing RFCs, which I tried to revitalize (so far it's still flatlined) by contributing an XML DTD closely related to the Itsy Bitsy; it included HTML3.2 table support and some stuff for HEADs and BODYs. I promise that I don't really create DTDs as fast as listfolk may be thinking: I'm drawing on my (all of two months of) prior work here. > >I believe that you should force (using #FIXED) inline=true for > >simple links, and inline=false for extended links. This is a > >general view of mine. > > Thanks. Again we have no experience. The simple links are not embedded in > mixed content, so does it matter? But I can and probably will do it. type=simple inline=true is the tried and true HTML model, and I think that a simple link that does *not* link its content is a bizarre anomaly; one-ended links should be handled as part of the extended-link model. Likewise, an extended link that does link its content can be easily created with a locator element referring to self. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Jun 5 23:43:29 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:03 2004 Subject: XSchema: Proposed Outline, Rev. 1 Message-ID: <UPMAIL17.199806052141160151@classic.msn.com> The latest outline for the XSchema specification follows. I've added notations and the DTD and XSchema for XSchemas. Entities remain outside the outline unless it becomes clear that they have to be here. If added, they'll go into section 2.0 someplace. I'm going to start filling in the blanks this weekend, so please let me know if you have comments or suggestions. Thanks! Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies ---------------------- 1.0 Introduction 1.1 Status 1.2 Origin and Goals 1.3 Relation to Other Standards 1.4 Terminology 2.0 XSchema Syntax 2.1 The XSchema Document 2.2 Element Declarations 2.3 Attribute Declarations 2.4 Content Model Declarations 2.5 Notation Declarations 2.6 XSchema Extensions 2.6.1 Documentation Extensions 2.6.2 Constraints on Extensions 3.0 XSchema and Namespaces 3.1 The XSchema Namespace 3.2 Interaction with Other Namespaces 3.3 Note regarding Namespace Usage 4.0 XSchema Transformation to XML 1.0 DTD 4.1 Transformation Models 4.2 Transformation Losses 5.0 Connecting XSchemas to XML Documents 5.1 Processing Models 5.2 Processing Instruction Appendices: A. XSchema DTD B. XSchema declared as XSchema Additional Notes: 1. XSchemas and XML 1.0 DTD Interactions xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Sat Jun 6 11:36:18 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:03 2004 Subject: Comments on VHG DTD 1.0alpha Message-ID: <199806060935.LAA17040@berlin.dvs1.tu-darmstadt.de> > I promise that I don't really create DTDs as fast as listfolk may be > thinking: I'm drawing on my (all of two months of) prior work here. Thank God. It's hard enough trying to learn one new spec a week, much less write one ;) -- Ron xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Sat Jun 6 14:53:23 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:03 2004 Subject: Unified XSchema draft available Message-ID: <199806061248.OAA17633@berlin.dvs1.tu-darmstadt.de> John Cowan wrote: > Although there are still a few things Ron and John disagree on, > I have written a unified draft, basically by taking Ron's draft > and hacking on it a bit. Ron hasn't seen it yet, though, so > it may change further in the process of converging. > > The URL: http://www.ccil.org/~cowan/XSchema-draft-DTD-19980605.txt . > You may also need: http://www.ccil.org/~cowan/ibtwsh.dtd . > In the interests of speed, I have not published new prose or a new > meta-XSchema yet. > > New and changed stuff from Ron's last draft (*s mark what Ron has > NOT approved-in-principle yet): > [change list snipped] I've read the changes and agree. I'm still a bit uneasy with the following two items, but I'm willing to agree to whatever the list decides, including leaving them as they are: 1) If an attribute type is not declared, it is assumed to be CDATA. I lean toward explicitness. 2) A Choice or Seq must have two or more elements. This makes logical sense, but I'm still a bit afraid that people will commonly include only a single element and that we ought to allow it. Perhaps it's due to one of my mother's favorite sayings: "We got vanilla [ice cream]. Waddya want?" My Web site now points to John's. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sun Jun 7 15:36:59 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:04 2004 Subject: XSchema Spec, Section 1.0 (Draft 1) Message-ID: <UPMAIL17.199806071335060837@classic.msn.com> Below is a initial draft of section 1.0 of the XSchema specification. This section provides an introduction to the XSchema specification, describing its relationship to standards, the goals developed earlier on this mailing list, and providing a glossary for terminology. The glossary is not yet developed, but will certainly grow as the specification progresses. Let's _not_ reopen the goals, please, but other comments and suggestions are welcome. I hope to have some of section 2.0 (the real guts of the spec) up Sunday or Monday. A prettier version (formatted using HTML) is available at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies ------------------------ 1.0 Introduction Extensible Markup Language (XML) uses notation inherited from the Standard Generalized Markup Language (SGML) to represent document structures and inclusions in its Document Type Definitions (DTDs). While this achieves considerable compatibility with SGML, it makes it impossible to extend the capacities of a DTD beyond those provided in SGML, requires developers to understand two different syntaxes for documents and DTDs, and forces tool builders to create a separate set of tools for managing DTDs. This XSchema specification describes an XML document representation for the structural information currently represented by DTDs, and a transformation from XSchema documents to DTDs. This specification also suggests mechanisms and processing models for connecting documents to XSchemas. This initial version of the XSchema specification is deliberately simple, providing an initial base for implementations while introducing as few complicating factors as possible. Authors accustomed to DTD creation may find their toolset constricted; it is hoped that supporting software and tools available from other standards will make up for this reduced toolset. 1.1 Status The XSchema specification is the product of discussions on the xml-dev mailing list. This document has no official status. The editors have no affiliation with the World Wide Web Consortium (W3C), the organization developing and maintaining the XML standard, nor any affiliation with any W3C member organizations. While it is hoped that this document may eventually be submitted to the W3C as a Note, it is not an official specification and should be considered experimental. 1.2 Origin and Goals Proposals for describing SGML document type definitions using document syntax rather than the separate declaration syntax have been under development for a number of years, and used by several tools for documentation. The current proposal arose from a number of concerns surrounding XML's usability and consistency. Originally conceived of as a mapping of DTD syntax to document syntax, the project has focused more on creating schemas describing element and attribute structures rather than preserving every function provided by XML 1.0 DTDs. The list of goals developed by the xml-dev discussion follows: 1. XSchema documents shall use XML document syntax, using element nesting and attributes to describe all constraints that may be verified by a processor using XSchema . 2. XSchema shall define a transformation from XSchema documents to DTDs. 3. XSchema documents shall be capable of representing the normalized element and attribute structures defined in XML 1.0 DTDs, and provide namespace support. 4. XSchema documents shall be parseable, manageable, and manipulable using the same tools used to parse, manage, and manipulate XML documents. 5. XSchema documents shall be easy to create, read, and modify, and shall provide authoring support for XML documents. 6. XSchema documents shall be easy to use in combination with a parser to provide structural validation of documents. 7. XSchema shall include an XSchema document and an XML 1.0 DTD defining the structure of XSchema documents . 8. XSchema shall suggest mechanisms for applying XSchema documents to documents. 9. XSchema shall include mechanisms for extending the information included in XSchema documents to support metadata. 10. The XSchema specification shall be readable, clear, and rigorous, using terminology and nomenclature as close to the XML 1.0 specification as possible. 11. The XSchema specification will comply with and be consistent with W3C recommendations. 12. XSchema documents shall provide constructs for human- and machine-readable documentation. 1.3 Relation to Standards XSchemas use XML 1.0 document instance syntax and may be applied to XML 1.0 documents. XSchemas are also designed to make use of XML namespaces. It is hoped that XSchemas and RDF Schemas may be mapped to each other. This specification has also been influenced by the discussion of the XML-Data proposal made to the W3C on 5 January, 1998. 1.4 Terminology may - XSchemas are permitted but not required to behave as described. must - XSchemas must behave as described. Failure to behave as described constitutes an error. error - A breach of the rules set forth in this specification. Software should report this error to the user. element attribute [to be filled in as the specification develops.] ----------------- 123456789112345678921234567893123456789412345678951234567896123456789712 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sun Jun 7 15:52:01 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:04 2004 Subject: MIME types and file extensions for XML (was XSchema Question 5) Message-ID: <UPMAIL17.199806071349590087@classic.msn.com> I remember that earlier on the list, there was a discussion of MIME types and XML, and I think the general consensus was that XML should use "application/xml" and not "text/xml". That's fine, except that I also remember a discussion about file extensions, where someone was complaining about the use of .xml as a file extension. (Maybe this was on XML-L; I can't find it in any case.) .xml, they argued, was way too generic and didn't really tell an application about how it should process the file it was going to get. Imagine thousands of XML files for all kinds of different applications lounging in a file system with no way to tell which goes where... As I'm pondering the top-level XSchema element, it's occurred to me that it might be useful to provide MIME type information and recommended file extensions for documents that use this XSchema, as well as the version information I currently plan on providing. Is there any discussion, a NOTE or something, that I can reference for guidelines on XML MIME types and/or file extensions? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From robin at ACADCOMP.SIL.ORG Sun Jun 7 16:45:54 1998 From: robin at ACADCOMP.SIL.ORG (Robin Cover) Date: Mon Jun 7 17:02:04 2004 Subject: MIME types and file extensions for XML Message-ID: <199806071453.JAA27722@ACADCOMP.SIL.ORG> Re: what Simon St.Laurent said > Date: Sun, 7 Jun 98 13:50:55 UT > From: "Simon St.Laurent" <SimonStL@classic.msn.com> > Message-Id: <UPMAIL17.199806071349590087@classic.msn.com> > To: "Xml-Dev (E-mail)" <xml-dev@ic.ac.uk> > Subject: MIME types and file extensions for XML (was XSchema Question 5) > > I remember that earlier on the list, there was a discussion of MIME > types and XML, and I think the general consensus was that XML should > use "application/xml" and not "text/xml". ... > Is there any discussion, a NOTE or something, that I can reference for > guidelines on XML MIME types and/or file extensions? Try: http://www.sil.org/sgml/xml.html#xmlMediaTypes - XML Media/MIME Types and more generally: http://www.sil.org/sgml/gen-apps.html#mime - MIME-SGML ------------------------------------------------------------------------- Robin Cover Email: robin@acadcomp.sil.org 6634 Sarah Drive Dallas, TX 75236 USA >>> The SGML/XML Web Page <<< Tel: +1 (972) 296-1783 (h) http://www.sil.org/sgml/sgml.html Tel: +1 (972) 708-7346 (w) FAX: +1 (972) 708-7380 ========================================================================= xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sun Jun 7 17:57:19 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:04 2004 Subject: MIME types and file extensions for XML Message-ID: <UPMAIL17.199806071555430181@classic.msn.com> Robin Cover pointed me to: http://www.sil.org/sgml/xml.html#xmlMediaTypes Which, in addition to providing all kinds of useful background, pointed me to an Internet Society Internet Draft on "XML Media Types" by E.J. Whitehead and Murata Makoto. ftp://ftp.ietf.org/internet-drafts/draft-whitehead-mime-xml-04.txt It's an excellent draft, and makes clear that character encoding issues need to be addressed in transfers. The only question I have is that they're registering text/xml and application/xml. Are we expecting all XML-encoded files to transfer under these two MIME types, or will more specific MIME types emerge for particular types of XML documents? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Sun Jun 7 18:30:32 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:02:04 2004 Subject: Parser differences In-Reply-To: <199806071453.JAA27722@ACADCOMP.SIL.ORG> Message-ID: <3.0.3.32.19980607122959.00b1cb2c@nexus.polaris.net> I've been struck by some notable differences among parsers. They all pretty much do "core XML" the same way (or at least to the same effect), but differ in the ways they handle (even accept/reject) some of the fringe portions of the spec, such as notations. These differences will probably blur over time; still.... Just curious: is there any effort underway somehow to tag a document indicating which parser(s) the document's developer used to validate it or check it for well-formedness? I'm thinking of something like a metadata attribute on the order of parse-with="aelfred" parse-with-version="1.0" -- a way to signal a SAX-aware application program that if the indicated parser is available, use it before defaulting to some other? I know that Jumbo, for one, permits the user to select a parser. It seems that embedding an identification of the preferred parser in the document instance would make it less likely that the user would "choose wrong," though. (Yes, it would also invite abuse of the "This document best viewed with X" sort.) John E. Simpson | It's no disgrace t'be poor, simpson@polaris.net | but it might as well be. | -- "Kin" Hubbard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmodre at edu.uni-klu.ac.at Sun Jun 7 21:09:06 1998 From: jmodre at edu.uni-klu.ac.at (Juergen Modre) Date: Mon Jun 7 17:02:04 2004 Subject: SAX compatibility & WF parsing questions Message-ID: <357B018A.402BFE80@edu.uni-klu.ac.at> Hello, Here are few questions to the SAX interface and XML parsing which arised when I implemented the SAX interface & compared the already existing implementations. Thanks for any hints. And forgive me if something is sun-clear for everybody except me. 1.) Parser.java Parser.java has the following javadoc header: * <p>All SAX parsers must also implement a zero-argument constructor * (though other constructors are also allowed).</p> What does this mean for this case? 2.) SAX callback events For which parts of an XML document should a SAX compatible parser give SAX callbacks? Looking at the XML start production [1] document ::= prolog element Misc* a) only from root-element to end of root element (= element production) b) from root-element to end of XML file (= element and Misc* production) c) the whole XML file (whole document production) Well, at least always the DTDHandler.notationDecl() and DTDHandler.unparsedEntityDecl() methods must be called always outside the element production, but which one is the correct way? 3.) Return value of systemId and publicId In the SAX documentation there is often the <p> * <p>If the system identifier is a URL, the SAX parser must * resolve it fully before reporting it to the application.</p> Does a SAX conformant parser now need to return always the "absolute URI" for the parameters systemId and publicId? e.g. If defined: <!NOTATION BMP SYSTEM "abc.exe"> The SAX parser must for instance return: <!NOTATION BMP SYSTEM "file:/C:/Files/XML-Files/abc.exe"> Is this the meaning of this <p>? 4.) WF parsing and: characters vs. ignorableWhitespace Looking at the XML start production [1] document ::= prolog element Misc* For prolog and Misc a parser should always return ignorableWhitespace. For the parts in the element production and WF parsing: a.) always charData b.) always ignorableWhitespace c.) or must be DTD aware, which means charData or ignorableWhitespace according to the DTD 5.) ByteStreamDemo.java When launching this example it gives a false usage hint: Usage: java -Dorg.xml.sax.parser=<classname> SystemIdDemo <document> should be Usage: java -Dorg.xml.sax.parser=<classname> ByteStreamDemo <document> 6.) EntityResolver.java I know that SAX 1.0 is finalized now but I think the name "resolveExternalEntity" would be better in this case than "resolveEntity" :-). ----------------------------------------------- JUERGEN MODRE Reisdorf 6 A-9371 Brueckl Austria (Europe) Phone: ++43 4214 2320 Mobile: ++43 664 233 22 22 E-mail: jmodre@edu.uni-klu.ac.at WWW: http://www.edu.uni-klu.ac.at/~jmodre ----------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sun Jun 7 23:13:38 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:04 2004 Subject: XSchema Question 5: Root element issues Message-ID: <UPMAIL17.199806072112130906@classic.msn.com> > Do we want to provide additional information in this root element regarding > XSchema version, for instance? > > We could add "version='0.1'" or something. Should we add elements (or attributes) for MIME type or recommended file extension? It seems like it would make maintaining libraries of XML documents a lot easier. Defaults could be "application/xml" and ".xml". Any thoughts? Writing this up is interesting - the issues kind of leap out. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Mon Jun 8 01:34:31 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:04 2004 Subject: Parser differences Message-ID: <001c01bd926b$b8b61aa0$2ee044c6@arcot-main> >I know that Jumbo, for one, permits the user to select a parser. It seems >that embedding an identification of the preferred parser in the document >instance would make it less likely that the user would "choose wrong," though. Nice idea except its a sort of chicken and egg problem. Don Park http://www.docuverse.com/personal/index.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From adam at cyber-guru.com Mon Jun 8 01:41:47 1998 From: adam at cyber-guru.com (Adam M. Donahue) Date: Mon Jun 7 17:02:04 2004 Subject: "SMDL"--work in progress In-Reply-To: <UPMAIL17.199806072112130906@classic.msn.com> Message-ID: <199806072341.TAA03415@wwwultra.sce.nyu.edu> Hi all, This is my first posting to xml-dev, as I'm still getting comfortable the XML specification. However, as an exercise I have begun putting together a first XML DTD (hopefully to be put together) which I'm tentatively calling the "Site Map Definition Language" or SMDL. (The name will most likely change.) The are currently hundreds of thousands (if not millions) of grouped collections of documents on the WWW which we often refer to individually at "sites." We can use XML to define the various types of information out there in a uniform language. We can further classify these different types of documents into groups, the most common of which right now is the idea of the Web site. Right now, the structure of any given site is usually laid out in a tree of documents. However, we have not yet seen a uniform way for expressing--in a single document--the contents of this tree. This has resulted in non-standard "site maps," which vary greatly between different locations on the Web. Compounding this is the fact that these maps, though often friendly to the user surfing the web, are highly machine unreadable (which is, of course, a general problem with HTML). That is, automated web robots dispatched by the major search engines have no easy way of gaining quick access to the layout of an individual site. These engines must then result to recursively searching sites for linked documents. This poses a problem for both the web content provider, who may have robots accessing and cataloging pages not meant to be cataloged; it also poses a problem to the web robots themselves, which have the time consuming and bandwidth hogging task of requesting several pages in the hopes of keep a database up-to-date. SMDL is a work in progress to solve the above problems. With it, I hope to define a uniform language which web content providers can use to offer both user agents and robots access to the full structure of a site--including information about the tree-like layout of a site; the frequency of updates of a particular resource; whether content is dynamic or not (now, with html files, for instance, the web robot cannot necessarily know if a page is server-parsed); and other information. Obviously there are a lot of possibilities. This is why I'm coming to the group a bit early to get feedback. What would you include in such a language? Also, is this a worthwhile endeavor? My proposal now is very small, and no doubt missing some important elements. (Again, I will post very soon; I want to make sure I've eliminated obvious DTD errors.) It's mainly an exercise as an early XML application. So don't be afraid to say it's unnecessary (I doubt you would anyhow) and anything else. I appreciate any feedback at all. Thanks in advance. I look forward to further participation in this group, especially with the somewhat exciting XSchema specification.  Adam mailto:adam@cyber-guru.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Mon Jun 8 02:03:50 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:02:04 2004 Subject: "SMDL"--work in progress In-Reply-To: <199806072341.TAA03415@wwwultra.sce.nyu.edu> References: <UPMAIL17.199806072112130906@classic.msn.com> Message-ID: <3.0.3.32.19980607200313.00bd0f70@nexus.polaris.net> At 07:38 PM 6/7/98 -0400, Adam M. Donahue wrote: >...as an exercise I have begun >putting together a first XML DTD (hopefully to be put together) which >I'm tentatively calling the "Site Map Definition Language" or SMDL. Hi Adam. SMDL is a great idea. But you might want to take a look at the IBM XML Parser for Java (xml4j), which comes with a sample app, SiteOutliner, which does approximately what you're talking about. The parser scans a site and creates a CDF file which can then be viewed either with their own CDFViewer or with MSIE. xml4j is available at: http://www.alphaworks.ibm.com/formula/xml Good luck. Sounds like a good project, no matter which way you go with it. John E. Simpson | It's no disgrace t'be poor, simpson@polaris.net | but it might as well be. | -- "Kin" Hubbard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From leehy at mail.posdata.co.kr Mon Jun 8 02:45:18 1998 From: leehy at mail.posdata.co.kr (Hyun Young Lee) Date: Mon Jun 7 17:02:04 2004 Subject: unsubscribe Message-ID: <357B339D.4B1247F8@mail.posdata.co.kr> unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From adam at cyber-guru.com Mon Jun 8 02:55:18 1998 From: adam at cyber-guru.com (Adam M. Donahue) Date: Mon Jun 7 17:02:04 2004 Subject: "SMDL"--work in progress In-Reply-To: <3.0.3.32.19980607200313.00bd0f70@nexus.polaris.net> References: <199806072341.TAA03415@wwwultra.sce.nyu.edu> Message-ID: <199806080055.UAA04026@wwwultra.sce.nyu.edu> > At 07:38 PM 6/7/98 -0400, Adam M. Donahue wrote: > >...as an exercise I have begun > >putting together a first XML DTD (hopefully to be put together) which > >I'm tentatively calling the "Site Map Definition Language" or SMDL. > > Hi Adam. SMDL is a great idea. But you might want to take a look at the IBM > XML Parser for Java (xml4j), which comes with a sample app, SiteOutliner, > which does approximately what you're talking about. The parser scans a site > and creates a CDF file which can then be viewed either with their own > CDFViewer or with MSIE. Yes, indeed. CDF appears to accomplish much of what I've proposed. Still, I will work away on SMDL as a learning exercise. (I completely forgot about CDF; I have worked with channels before but it slipped my mind that, of course, it can be used to offer almost precisely the site mapping functionality I had in mind.) Adam (BTW, sorry for all the typos in my previous message.) mailto:adam@cyber-guru.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Mon Jun 8 03:13:53 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:04 2004 Subject: MIME types and file extensions for XML In-Reply-To: <UPMAIL17.199806071555430181@classic.msn.com> Message-ID: <199806080115.AA01371@murata.apsdc.ksp.fujixerox.co.jp> Simon St.Laurent wrote: > It's an excellent draft, and makes clear that character encoding issues need > to be addressed in transfers. The only question I have is that they're > registering text/xml and application/xml. Are we expecting all XML-encoded > files to transfer under these two MIME types, or will more specific MIME types > emerge for particular types of XML documents? We are expecting more specific MIME types emerge for particular types of XML documents. In section 3 of the draft, we have a paragraph as below: XML provides a general framework for defining sequences of structured data. In some cases, it may be desirable to define new media types which use XML but define a specific application of XML, perhaps due to domain-specific security considerations or runtime information. This document does not prohibit future media types dedicated to such XML applications. However, developers of such media types are recommended to use this document as a basis. In particular, the charset parameter should be used in the same manner. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From adam at cyber-guru.com Mon Jun 8 05:20:36 1998 From: adam at cyber-guru.com (Adam M. Donahue) Date: Mon Jun 7 17:02:04 2004 Subject: Extending XML In-Reply-To: <199806080055.UAA04026@wwwultra.sce.nyu.edu> References: <3.0.3.32.19980607200313.00bd0f70@nexus.polaris.net> Message-ID: <199806080320.XAA05003@wwwultra.sce.nyu.edu> Has there been any discussion regarding using XML to extend XML itself? Let's see, how can I put this? For instance, say I want to be able to represent the grammar of C in an XML document. I could do that, I suppose. But how would I use this grammer to write a program? Obviously I don't want to turn a statement like: while (*a++ = *b++); into a series of elements. (Hmm. I just tried an example but this is definitely non-trivial!) Or something of this nature. Wouldn't it be nice to be able to use XML to define a structured format without having to use tags? Maybe this is not a good example. How about a way to encode all elements in fixed length fields, depending on the size of language? That way instead of having to parse for <XML> I could mask eight bits and do I quick comparison, for example. Do you see what I mean? Just some thoughts...  Adam mailto:adam@cyber-guru.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From scott at lumdata.com Mon Jun 8 06:41:16 1998 From: scott at lumdata.com (Scott Vanderbilt) Date: Mon Jun 7 17:02:05 2004 Subject: XSL Processors? Message-ID: <v03130302b1a1186b56f1@[24.130.5.248]> I was wondering whether anyone was aware of any XSL processors that may be in development. I am familiar with Microsoft's, as well as Henry James' xslj (not so much an XSL processor as an XSL -> DSSSL style sheet translator which can be used with Jade to output documents). However, each has their shortcomings for the application to which I wish to put them to use. Also, if anyone is aware of what progress is being made by the W3C towards adoption of XSL as a recommendation, that information would be appreciated as well. Many thanks in advance. ========================================================================== Scott D. Vanderbilt mailto:scott@lumdata.com Luminous Dataworks Phone: (310) 253-9918 Custom database solutions Fax: (310) 842-7025 for the World Wide Web ========================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 8 09:45:42 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:05 2004 Subject: MIME types and file extensions for XML In-Reply-To: <UPMAIL17.199806071555430181@classic.msn.com> Message-ID: <000101bd92b1$87f18120$9ebc38cb@NT.JELLIFFE.COM.AU> > From: owner-xml-dev@ic.ac.uk > The only question I have is that they're > registering text/xml and application/xml. > Are we expecting all XML-encoded > files to transfer under these two MIME types, > or will more specific MIME types emerge > for particular types of XML documents? Anyone can make their own MIME type. The media types have an extension mechanism. So if I made "Rick's Markup Language" I could use the media type "application/x-rml". The "x-" prefix allows user extension. Of course, if Robin Cover made up "Robin's Markup Language" with the same type name, there is a potential problem. This is the old "public identifier" problem. And the old solution is appropriate: the name should include some owner name which will promote uniqueness. If possible, this owner name should be from some registration authority. In my case, I am pretty sure there is no one else in the world with my name. So I can just say something like "application/x-rick-jelliffe-ml" and there will be no problems. Robin Cover might say "appplication/x-sil-org-sgml-ml" and use some version of his internet domain name, since his name is less rare and there is slightly more chance of collission (though still less!). You can also apply to the IETF and get your own registration tree. So Microsoft, for example, could apply for "ms": then they could have "appplication/ms-rml". (But no-one has done this yet, so it perhaps involves too much effort to be a viable alternative.) (For more on this subject, see chapter 13 "Formal Public Identifiers" and chapter 14 "Data Content Notations" in my book. The RFCs for MIME media-type registrations are useful too.) Rick Jelliffe ========================================================== The XML & SGML Cookbook, by Rick Jelliffe Charles F. Goldfarb Series on Open Information Management 656 pages + CD-ROM, Prentice Hall 1998, ISBN 0-13-614223-0 http://www.sil.org/sgml/jelliffeXMLAnn.html http://www.phptr.com/ > Book Search > "Jelliffe" http://www.amazon.com/exec/obidos/ASIN/0136142230/002-4102466-3352420 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 8 10:05:06 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:05 2004 Subject: Parser differences In-Reply-To: <3.0.3.32.19980607122959.00b1cb2c@nexus.polaris.net> Message-ID: <000201bd92b4$648c5950$9ebc38cb@NT.JELLIFFE.COM.AU> > From: John E. Simpson > I've been struck by some notable differences among parsers. They > all pretty > much do "core XML" the same way (or at least to the same effect), but > differ in the ways they handle (even accept/reject) some of the fringe > portions of the spec, such as notations. These differences will probably > blur over time; still.... It would be really great if someone can make up a list of these kind of differences. Then OASIS/XML WG/XML-DEV etc can try to work out a consensus. In my experience, newcomers have a great resistance to the central XML/SGML/MIME idea: that the identification of the notation ("type" in MIME terms") is just as important as having an element structure. The same this is actually also true of PIs and entities. People coming from HTML or PDF tend to reject them due to unfamilitiarity. I think this attribute can be seen in the XSchema development. When something is slackly defined, it works against portability and openness. And since people will need the functionality, they will try to reinvent it using their own mechanism. In fact, treating notation attributes properly is the key to strong lexical typing of element values: so the database people should be screaming for this, if they have sense. Tim Bray has made an excellent list of data content notations used by database products (dates, etc). And Martin Bryan has made a list of all the data content notations used in ISO standards (ISO 8601 date, ISO "C", lots of graphics notations) which are perhaps more appropriate for external non-XML entities. Rick Jelliffe ========================================================== The XML & SGML Cookbook, by Rick Jelliffe Charles F. Goldfarb Series on Open Information Management 656 pages + CD-ROM, Prentice Hall 1998, ISBN 0-13-614223-0 http://www.sil.org/sgml/jelliffeXMLAnn.html http://www.phptr.com/ > Book Search > "Jelliffe" http://www.amazon.com/exec/obidos/ASIN/0136142230/002-4102466-3352420 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jun 8 10:20:49 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:05 2004 Subject: Extending XML In-Reply-To: <199806080320.XAA05003@wwwultra.sce.nyu.edu> Message-ID: <000301bd92b6$8d6ce8b0$9ebc38cb@NT.JELLIFFE.COM.AU> You seem to be saying "Is there a way to use XML declaration syntax and processing model to define a language with a completely syntax?" The answer is "Yes, use SGML". XML is a subset of SGML. It represents a complete ratification of the basic model and syntax of SGML by industry, together with a rejection (for WWW purposes only) of some of the more hard-to-implement features of SGML. In the case of your question, in SGML you can remap all delimiters and keywords to different strings. You can make any symbol or text string act as a reference to a previously defined tag. These "short references" can be element-context-specific, and so change during the life of a document. You can switch in and out banks of predefined attribute values (LINK). You can define your own completely different external syntax which will be translated into an SGML syntax before the parser gets to it (Formal System Identifiers). All these things are possible now with existing SGML (not every SGML product has to support all of them). But XML's development philosophy was an explicit rejection of this kind of flexibility: the reasons are 1) SGML already supports them if you need them 2) they complicate writing parsers 3) they can make documents unreadable 4) people want to use XML to solve their domain problems--they do not want to have to become domain experts in markup languages too--and the SGML experience is that people get annoyed if too much power and configurability is offered 5) smaller documents are better achieved by compression, which also gives a better layering of software (less "coupling" in Constantine and Yourdan's termology) 6) modern GUIs reduces the importance of reducing keystrokes: at least for the upper layers of structure--the lower levels of a structure are often more conveniently hidden using infix-like delimiters (e.g. rather than having separate attributes for method, host, directory, filename, etc., people like to use URIs which lump them all together.) 7) these syntactic issues do not increase the expressive power of the language: XML is designed as a Web distribution language which also is not completely hopeless as a maintenance format. 8) XML already provides the notation mechanism, by which you can embed your own language inside elements or PIs. 9) You can define your own language and use that at any time anyway--but that is the mess which people got themselves into which triggered off XML (and SGML!). Open systems need open data: "Information wants to be free" in the slogan of the techno crowd (it is a song too). So the value of the "Standard" aspect (i.e. the "S" in SGML) is wothwhile considering. Rick Jelliffe ========================================================== The XML & SGML Cookbook, by Rick Jelliffe Charles F. Goldfarb Series on Open Information Management 656 pages + CD-ROM, Prentice Hall 1998, ISBN 0-13-614223-0 http://www.sil.org/sgml/jelliffeXMLAnn.html http://www.phptr.com/ > Book Search > "Jelliffe" http://www.amazon.com/exec/obidos/ASIN/0136142230/002-4102466-3352420 > -----Original Message----- > From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of > Adam M. Donahue > Sent: Monday, 8 June 1998 13:18 > To: xml-dev@ic.ac.uk > Subject: Extending XML > > > Has there been any discussion regarding using XML to extend XML > itself? Let's see, how can I put this? For instance, say I want to be > able to represent the grammar of C in an XML document. I could do > that, I suppose. But how would I use this grammer to write a > program? Obviously I don't want to turn a statement like: > > while (*a++ = *b++); > > into a series of elements. (Hmm. I just tried an example but this is > definitely non-trivial!) Or something of this nature. Wouldn't it be > nice to be able to use XML to define a structured format without > having to use tags? > > Maybe this is not a good example. How about a way to encode all > elements in fixed length fields, depending on the size of language? > That way instead of having to parse for <XML> I could mask eight > bits and do I quick comparison, for example. Do you see what I > mean? > > Just some thoughts... >  > Adam > > mailto:adam@cyber-guru.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the > following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jun 8 13:34:57 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:05 2004 Subject: SAX compatibility & WF parsing questions In-Reply-To: <33443330@toto.iv> Message-ID: <199806081132.HAA00305@unready.megginson.com> Juergen Modre writes: > Here are few questions to the SAX interface and XML parsing which > arised when I implemented the SAX interface & compared the already > existing implementations. > > Thanks for any hints. > And forgive me if something is sun-clear for everybody except me. > > 1.) Parser.java > Parser.java has the following javadoc header: > * <p>All SAX parsers must also implement a zero-argument constructor > * (though other constructors are also allowed).</p> > What does this mean for this case? That means that if you are creating a class SAXDriver, you need a public SAXDriver () constructor. > 2.) SAX callback events > For which parts of an XML document should a SAX > compatible parser give SAX callbacks? > > Looking at the XML start production > [1] document ::= prolog element Misc* > > a) only from root-element to end of root element (= element production) > b) from root-element to end of XML file (= element and Misc* production) > c) the whole XML file (whole document production) > > Well, at least always the DTDHandler.notationDecl() and > DTDHandler.unparsedEntityDecl() methods must be called > always outside the element production, but which one > is the correct way? You should report all processing instructions, notation declarations, and unparsed entity declarations (or at least, all of them that your parser can get to). The DocumentHandler.ignorableWhitespace() callback is only for ignorable whitespace in element content, so you should not use it for whitespace outside of the document element. > 3.) Return value of systemId and publicId > In the SAX documentation there is often the <p> > * <p>If the system identifier is a URL, the SAX parser must > * resolve it fully before reporting it to the application.</p> > > Does a SAX conformant parser now need to return always the > "absolute URI" for the parameters systemId and publicId? > e.g. > If defined: > <!NOTATION BMP SYSTEM "abc.exe"> > The SAX parser must for instance return: > <!NOTATION BMP SYSTEM "file:/C:/Files/XML-Files/abc.exe"> > > Is this the meaning of this <p>? That's a very good question -- it should certainly do so for other system identifiers, but nobody's really sure what the system identifier for a notation is supposed to be in the first place. Any suggestions? > 4.) WF parsing and: characters vs. ignorableWhitespace > Looking at the XML start production > [1] document ::= prolog element Misc* > > For prolog and Misc a parser should always return > ignorableWhitespace. No, it should not use the callback at all outside of the document element; note the first line of the JavaDoc comment: * Receive notification of ignorable whitespace in element content. ^^^^^^^^^^^^^^^^^^ > For the parts in the element production and WF parsing: > > a.) always charData > b.) always ignorableWhitespace > c.) or must be DTD aware, which means charData or > ignorableWhitespace according to the DTD If the parser is validating, it must distinguish it; if it is non-validating but DTD-aware, it may distinguish it; and if it is not DTD-aware, it cannot distinguish it. Tricky stuff, really (thanks to the XML 1.0 spec). > 5.) ByteStreamDemo.java > When launching this example it gives a false usage hint: > Usage: java -Dorg.xml.sax.parser=<classname> SystemIdDemo <document> > should be > Usage: java -Dorg.xml.sax.parser=<classname> ByteStreamDemo <document> Right -- thanks for the correction. > 6.) EntityResolver.java > I know that SAX 1.0 is finalized now but I think the name "resolveExternalEntity" > would be better in this case than "resolveEntity" :-). It probably would have been. Oh well. All the best, and thanks for the feedback, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From adam at cyber-guru.com Mon Jun 8 13:44:12 1998 From: adam at cyber-guru.com (Adam M. Donahue) Date: Mon Jun 7 17:02:05 2004 Subject: Extending XML In-Reply-To: <000301bd92b6$8d6ce8b0$9ebc38cb@NT.JELLIFFE.COM.AU> References: <199806080320.XAA05003@wwwultra.sce.nyu.edu> Message-ID: <199806081143.HAA05572@wwwultra.sce.nyu.edu> > You seem to be saying "Is there a way to use XML declaration syntax and > processing model to define a language with a completely syntax?" > In the case of your question, in SGML you can remap all delimiters and > keywords to different strings. You can make any symbol or text string act as Yes, this is what I was saying. I have little experience with SGML (unlike most of this group, it appears), so I was unaware of this feature. I guess the ability to implement the above was not included in the XML specification in order to keep with the working group's goal of making XML relatively simple and accessible. Thanks for your additional points.  Adam mailto:adam@cyber-guru.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Mon Jun 8 14:51:07 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:05 2004 Subject: The Itsy Bitsy Teeny Weeny Simple Hypertext DTD Message-ID: <006301bd92dc$528bdc80$1e09e391@mhklaptop.bra01.icl.co.uk> >It is often convenient for XML documents to have a bit of >documentation somewhere in them... Using HTML-compatible elements >and attributes allows the documentation to be passed straight >through to HTML renderers. > Yes indeed, very useful. In my application I also want to use XML-tags within the documentary text, e.g. a <SURNAME> tag within the text of an <LI> element, but that doesn't reduce the usefulness of what you are offering. I am trying to understand how I would use namespaces to allocate a prefix to the HTML-derived tags, and I confess myself baffled by the specs, in particular the concept of "schema" which the namespaces proposal relies on. If I incorporate the itsy-bitsy DTD into my own DTD using parameter entities as suggested, have I lost the ability to use prefixes for its tags? If not, is there some other way of combining the two DTD's? Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 8 16:16:29 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:05 2004 Subject: draft-whitehead-mime-xml-04 Message-ID: <357BF1C9.7528861C@locke.ccil.org> Since one of the primary purposes of Content-Type: is to instruct a receiving program (email client, Web browser, or what have you) on the proper application to deploy in order to interpret the MIME entity, it seems to me that it would be useful to standardize a "type" parameter with application/xml and text/xml. Legal values would be "document", "entity" (including both external parsed entities and external parameter entities), and "dtd". Typically, "documents" would be passed to an XML browser, whereas "entity"s and "dtd"s would be simply stored; alternatively, "dtd"s could be passed to a DTD viewer. Passing "entity" or "dtd" MIME entities to an XML browser would or could produce an unwanted parsing error from the browser. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Mon Jun 8 17:33:41 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:05 2004 Subject: draft-whitehead-mime-xml-04 In-Reply-To: <357BF1C9.7528861C@locke.ccil.org> Message-ID: <199806081535.AA01398@murata.apsdc.ksp.fujixerox.co.jp> John Cowan wrote: > Since one of the primary purposes of Content-Type: is to instruct > a receiving program (email client, Web browser, or what have you) on > the proper application to deploy in order to interpret the > MIME entity, it seems to me that it would be useful to standardize > a "type" parameter with application/xml and text/xml. Legal > values would be "document", "entity" (including both external > parsed entities and external parameter entities), and "dtd". Thank you for your comment. Although the Internet Draft proposes text/xml and application/xml, the XML WG plans another mechanism for XML packaging (packaging of a document entity, external entities, styles, a catalog file for resolving FPI's, and so on.) The Internet Draft is intended to provide minimum functionalities for successful interchange of XML. The rest is left to XML packaging. The XML WG might want to introduce many more parameters of text/xml (e.g, references to DTD's, references to stylesheets, references to programs, etc.) or might want to introduce another media type. I do not know yet. (I also have to admit that XML packaging has not been seriously studied, though. It would be a service if somebody thoroughly studies this issue and submits a technical note to W3C.) Regarding your proposal, an XML document entity can also be an external parsed entity. XML declartations and text declarations are designed to allow this duality. Thus, I do not think we should distinguish "document" and "entity". If we distinguish the two types, users cannot make an XML document that is also an external parsed entity. (However, one could argue that the type attribute should be multi-valued.) An external parameter entity can also be an external DTD subset. Thus, "dtd" and "entity" should not be distinguished, as I see it. The only reasonable thing is to distinguish "dtd" (including parameter entities) and "entity" (including document entities). Then, is it necessary to distinguish "dtd" and "entity"? Certainly, a text/xml-aware MIME recipient can invoke different programs for "dtd" and "entity". However, it is also possible for an XML-syntax-aware program to autodetect "dtd" and "entity". Are there any strong reasons to introduce the "type" parameter in a hurry? I can be pursuaded, but I am inclined to postpone this issue to XML packaging. After all, we cannot make a perfect solution at this stage of the game. In other words, text/xml and application/xml are not expected to provide enough information for launching XML applications. They merely provide the charset parameter. > Typically, "documents" would be passed to an XML browser, whereas > "entity"s and "dtd"s would be simply stored; alternatively, "dtd"s > could be passed to a DTD viewer. Passing "entity" or "dtd" MIME > entities to an XML browser would or could produce an unwanted > parsing error from the browser. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Mon Jun 8 17:40:43 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:05 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) Message-ID: <UPMAIL17.199806081539020200@classic.msn.com> Finally, some real specs to abuse. This is my first time out writing formal specifications, and undoubtedly there will be lots of things to fix. All discussion is welcome - please make suggestions as you think appropriate! Remember - "readable, clear, and rigorous". What follows is the beginning of the syntax descriptions, providing a description of the XSchema document and the XSchema element that serves as the parent element to all of the declarations. I have posted a prettier HTML version of this to http://purl.oclc.org/NET/xschema . Thanks for all the help, Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies ------------------------- 2.0 XSchema Syntax This section describes the XSchema document instance syntax. The XSchema document is an XML document containing a single XSchema element in which information describing the schema is nested. The XSchema element must be preceded by an XML declaration and may be preceded by other declarations, comments, and processing instructions. 2.1 The XSchema Element The XSchema element is the root element for all XSchema documents. The declaration for the XSchema element is: <!ELEMENT XSC:XSchema (Doc?, (ElementDecl | Entity | Notation | Namespace | XSchema)*)> <!ATTLIST XSC:XSchema XSC:Version CDATA #FIXED "1.0" XSC:MimeType CDATA "application/xml" XSC:FileExtension CDATA "xml"> The XSC:XSchema element contains other elements describing the XSchema and building a schema. These elements are described in later sections of this specification. The XSC:XSchema element may also contain other XSC:XSchema elements nested inside of it. The XSC:XSchema element's attributes include information about the version of XSchema used as well as information about the type of documents created using the XSchema. XSchema version information, contained in the XSC:Version attribute, is critical to proper handling of documents should the specification be updated in the future. This specification is identified as version 1.0. Future major and minor versions of XSchema should identify themselves differently. No provision is made at this time for nesting XSchemas of different versions under a parent XSchema element. The XSC:MimeType and XSC:FileExtension attributes are used to provide a suggested MIME (Multipurpose Internet Mail Extensions) Content-type and file extension for documents created using a particular XSchema. Applications may use this information to identify XML document types. A document library that generates XML documents dynamically could assign file extensions and MIME types based on the XSchema used. Applications using this information should use the values stored in the first XSchema encountered during processing. For instance, if an XSchema includes another nested XSchema, the values for the XSC:MimeType and XSC:FileExtension attributes of the root XSchema should be used. By default, most XML documents are assumed to have a MIME type of application/xml, as described in "XML Media Types" by E.J. Whitehead and Murata Makoto. Developers who need different MIME types for documents created using particular XSchemas may register other MIME types with the IETF, as described in RFC 1590, or use the 'x-' prefix syntax for subtypes, as described in RFC 1521. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Mon Jun 8 18:01:14 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:05 2004 Subject: XSL Processors? Message-ID: <199806081559.LAA24533@ruby.ora.com> [Scott Vanderbilt] > Also, if anyone is aware of what progress is being made by the W3C > towards adoption of XSL as a recommendation, that information would > be appreciated as well. You can track all W3C activity on their Web site. The XSL activity is visible at <URL:http://www.w3.org/Style/XSL/>, where you'll see: * 980328 The W3C Working Group for XSL met for three days in Seattle, WA, USA right after XML 98 (yes, on a weekend) and continued their work. The following schedule of expected release dates was announced: + Requirements document: April 1998 + First Working Draft of XSL 1.0: July 1998 + Second Working Draft of XSL 1.0: November 1998 + Third Working Draft of XSL 1.0: February 1999 + Proposed Recommendation for XSL 1.0: May 1999 ... which should lead to a Recommendation in July 1999. -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Mon Jun 8 18:15:05 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:02:05 2004 Subject: XSL Processors? In-Reply-To: <v03130302b1a1186b56f1@[24.130.5.248]> References: <v03130302b1a1186b56f1@[24.130.5.248]> Message-ID: <wklnr7ub0y.fsf@ifi.uio.no> * Scott Vanderbilt | | I am familiar with Microsoft's, as well as Henry James' xslj (not so | much an XSL processor as an XSL -> DSSSL style sheet translator | which can be used with Jade to output documents). There are two more XSL processors, although you're probably only interested in one of them (docproc). See <URL:http://www.stud.ifi.uio.no/~larsga/linker/XMLtools.html#C0SC2> -- "These are, as I began, cumbersome ways / to kill a man. Simpler, direct, and much more neat / is to see that he is living somewhere in the middle / of the twentieth century, and leave him there." -- Edwin Brock http://www.stud.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon Jun 8 18:18:23 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:05 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) In-Reply-To: <UPMAIL17.199806081539020200@classic.msn.com> Message-ID: <000d01bd92f9$2f249300$cbbc38cb@NT.JELLIFFE.COM.AU> > From: Simon St.Laurent > <!ELEMENT XSC:XSchema (Doc?, (ElementDecl | Entity | Notation | > Namespace | > XSchema)*)> > <!ATTLIST XSC:XSchema > XSC:Version CDATA #FIXED "1.0" > XSC:MimeType CDATA "application/xml" > XSC:FileExtension CDATA "xml"> Almost all DTDs, or fragments which can stand by themselves as reuseable components, end up with a similar stucture which allows metadata headers, the actual body, and a section for annotations and floating elements. So I suggest that you build this into XSchema from the start: you can do this simply by using HTML's meta element, and by adding HTML's body element at the end, to fit in any miscellaneous text that the person wants to add. (I know that this may seem to duplicate XSC:Doc, but for any sizeably documented DTD, the declaration elements should come before the documentation elements so that the receiveing processor does not have to wait for long periods for the stuff it is really interested in.) Also, I have allowed multiple title elements, to be differentiated according to language, for i18n. <!-- ===================================================== --> <!-- An XSchema has a top-level structure sinmilar to HTML --> <!ELEMENT XSC:XSchema (XSC:head?, XSC:body, HTML:body?)> <!ATTLIST XSC:XSchema XSC:Version CDATA #FIXED "1.0" > <!-- Multiple title for i18n. Multiple meta for information such as file extension and MIME types --> <!ELEMENT HTML:head (HTML:title*, HTML:meta*)> <!ELEMENT HTML:title ( #PCDATA )> <!ATTLIST HTML:title XML:lang CDATA "en-US" ><!-- i.e. this is the default --> <!ELEMENT HTML:meta <!ATTLIST HTML:meta http-equiv NMTOKEN #IMPLIED name NMTOKEN #IMPLIED content CDATA #REQUIRED XML:lang CDATA "en-US" > <XSC:Body ( Doc?, (ElementDecl | Entity | Notation | Namespace | XSchema)*)> ... <!-- ===================================================== --> (For more information on this approach, refer Chapter 7 "The Document Shell" in my book. ) Rick Jelliffe ========================================================== The XML & SGML Cookbook, by Rick Jelliffe Charles F. Goldfarb Series on Open Information Management 656 pages + CD-ROM, Prentice Hall 1998, ISBN 0-13-614223-0 http://www.sil.org/sgml/jelliffeXMLAnn.html http://www.phptr.com/ > Book Search > "Jelliffe" http://www.amazon.com/exec/obidos/ASIN/0136142230/002-4102466-3352420 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Mon Jun 8 18:33:32 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:05 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) In-Reply-To: <000d01bd92f9$2f249300$cbbc38cb@NT.JELLIFFE.COM.AU> (ricko@allette.com.au) Message-ID: <199806081631.MAA25593@ruby.ora.com> [Simon St.Laurent] > <!ELEMENT XSC:XSchema (Doc?, (ElementDecl | Entity | Notation | > Namespace | XSchema)*)> (1) Remember that namespaces confer no magic for validation; this declaration probably meant to be: <!ELEMENT XSC:XSchema (XSC:Doc?, (XSC:ElementDecl | XSC:Entity | XSC:Notation | XSC:Namespace | XSC:XSchema)*)> Me, I'm partial to lower-case, and would even prefer: <!ELEMENT xsc:xschema (xsc:doc?, (xsc:elementdecl | xsc:entity | xsc:notation | xsc:namespace | xsc:xschema)*)> (2) I feel very strongly that XSchema should not define entities for use in documents. If it does, you're only inventing a new syntax for DTDs, and inheriting all of their problems, to which I say: "big deal". The biggest problem with DTDs (IMO) is that they conflate definitions for a class of documents with definitions for a single document instance. A schema should try, as cleanly as possible, to refer only to the *class* of documents, and leave entities out of it. After XSchema is successful, then we can move on to tackle a new and better syntax for entity declaration. Now, it may be that the "Entity" element is only intended for use within the schema. If so, great, but I think the name should reflect that. Maybe call it "module"? <xsc:module id="para.content"> <xsc:mixed> <xsc:element idref="emph"/> <xsc:element idref="term"/> <xsc:element idref="quote"/> <xsc:element idref="literal"/> </xsc:mixed> </xsc:module> <xsc:elementdecl id="para"> <xsc:content> <xsc:modref idref="para.content"/> </xsc:content> </xsc:elementdecl> (Note: I'm making up the content model syntax here. But you get the idea.) -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Mon Jun 8 18:35:12 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:06 2004 Subject: draft-whitehead-mime-xml-04 In-Reply-To: <199806081535.AA01398@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <Pine.SUN.3.91.980608122843.25080A-100000@itrc.uwaterloo.ca> On Tue, 9 Jun 1998, MURATA Makoto wrote: > An external parameter entity can also be an external DTD subset. > Thus, "dtd" and "entity" should not be distinguished, as I see it. The only > reasonable thing is to distinguish "dtd" (including parameter > entities) and "entity" (including document entities). XML does not define a concept of "DTD" that can stand alone separate from an XML document. The closest you could come is "set of markup declarations." But all "sets of markup declarations" can be used as entities. The idea that "sets of markup declarations" are really "DTDs" is one of the most pernicious misunderstandings in SGML and XML processing. I think Eliot calls it one of the 10 big lies. This is one reason that XSchemas are not merely another syntax for "DTDs". They are a new schema language entirely. Any resembelance to DTDs is merely due to the fact that they have similar goals (document validation). Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jmodre at edu.uni-klu.ac.at Mon Jun 8 18:43:52 1998 From: jmodre at edu.uni-klu.ac.at (Juergen Modre) Date: Mon Jun 7 17:02:06 2004 Subject: SAX compatibility & WF parsing questions References: <199806080135.VAA00511@unready.megginson.com> Message-ID: <357C30FA.8476F5BF@edu.uni-klu.ac.at> David thanks for the fast answer to verify my SAX interface thoughts. This way I want to gratulate you after the event for the good work to initiate, drive and coordinate the development of a standard XML event based interface. Great work! Another hint to the DocumentHandler.characters javadoc header: It says: * Receive notification of character data. * * <p>The Parser will call this method to report each chunk of * character data. SAX parsers may return all contiguous character * data in a single chunk, or they may split it into several * chunks; however, all of the characters in any single event * must come from the same external entity, so that the Locator * provides useful information.</p> This event has also to reply the characters of CDATA in a XML document, but this is not made explicit in the above <p> and it would therefore be nice to add this explicit in the <p>. BTW: In my opinion it would be better to not return the CDATA characters in this event as long as we don't have a separate CDATA callback in the SAX interface specification. ----------------------------------------------- JUERGEN MODRE Reisdorf 6 A-9371 Brueckl Austria (Europe) Phone: ++43 4214 2320 Mobile: ++43 664 233 22 22 E-mail: jmodre@edu.uni-klu.ac.at WWW: http://www.edu.uni-klu.ac.at/~jmodre ----------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Mon Jun 8 18:50:01 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:06 2004 Subject: XSL Processors? In-Reply-To: <199806081559.LAA24533@ruby.ora.com> Message-ID: <000e01bd92fd$b8503f90$cbbc38cb@NT.JELLIFFE.COM.AU> > [Scott Vanderbilt] > > Also, if anyone is aware of what progress is being made by the W3C > > towards adoption of XSL as a recommendation, that information would > > be appreciated as well. I think Chris Maden's own article "Problems with Dynamically Assembled Document Portions, and Some Solutions" at http://www.oreilly.com/people/staff/crism/transclu.html might give some indication of where XSL might be headed. I am not an XSL insider, but I would guess that the article raises issues that the XSL & the XPtr WGs find important. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Mon Jun 8 19:07:31 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:06 2004 Subject: XSL Processors? In-Reply-To: <000e01bd92fd$b8503f90$cbbc38cb@NT.JELLIFFE.COM.AU> (ricko@allette.com.au) Message-ID: <199806081705.NAA26628@ruby.ora.com> [Scott Vanderbilt] > Also, if anyone is aware of what progress is being made by the W3C > towards adoption of XSL as a recommendation, that information would > be appreciated as well. [Rick Jelliffe] > I think Chris Maden's own article "Problems with Dynamically > Assembled Document Portions, and Some Solutions" at > http://www.oreilly.com/people/staff/crism/transclu.html > might give some indication of where XSL might be headed. I am not an > XSL insider, but I would guess that the article raises issues that > the XSL & the XPtr WGs find important. The article was co-written by Steve DeRose, so the XLink/XPointer group is well aware of the issues raised. I've also taken the paper as a starting point for hypertext requirements for XSL, along with some excellent work by Boris Moore and other members of the WG, but the issues are fairly complex, and you shouldn't expect to see them solved in the July '98 draft. -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 8 19:09:06 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:06 2004 Subject: Itsy Bitsy: new draft Message-ID: <357C1A2D.AE95C17C@locke.ccil.org> I have released a new draft of Itsy Bitsy at http://www.ccil.org/~cowan/XML/ibtwsh.dtd . Entity sets for it are now located at http://www.ccil.org/~cowan/XML/XMLlat1.ent, http://www.ccil.org/~cowan/XML/XMLsymbol.ent, and http://www.ccil.org/~cowan/XML/XMLspecial.ent . The only new feature is the XML element, which is a horizontal format element with a model of ANY, allowing random XML to be inserted into the HTML. (Good luck passing this to your browser, though.) Further comments are earnestly solicited so I can nail this sucker down, since my current draft of XSchema depends on it. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dvp4c at jefferson.village.virginia.edu Mon Jun 8 19:13:41 1998 From: dvp4c at jefferson.village.virginia.edu (Daniel Pitti) Date: Mon Jun 7 17:02:06 2004 Subject: XML Formal Public Identifier Message-ID: <3.0.1.32.19980608131224.00b3ee90@jefferson.village.virginia.edu> Is there an official (W3C) Formal Public Identifier for XML? And notation declaration? Daniel V. Pitti Project Director Institute for Advanced Technology in the Humanities Alderman Library University of Virginia Charlottesville, Virginia 22903 Phone: 804 924-6594 Fax: 804 982-2363 Email: dpitti@Virginia.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Jun 8 19:22:45 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:02:06 2004 Subject: XML Formal Public Identifier Message-ID: <3.0.32.19980608102151.00b61d00@pop.intergate.bc.ca> At 01:12 PM 6/8/98 -0400, Daniel Pitti wrote: >Is there an official (W3C) Formal Public Identifier for XML? And notation >declaration? No. XML 1.0 does not support FPIs. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 8 20:02:50 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:06 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) References: <199806081631.MAA25593@ruby.ora.com> Message-ID: <357C26DC.CD255EBA@locke.ccil.org> Chris Maden wrote: > The biggest problem with DTDs (IMO) is that they conflate definitions > for a class of documents with definitions for a single document > instance. A schema should try, as cleanly as possible, to refer only > to the *class* of documents, and leave entities out of it. After > XSchema is successful, then we can move on to tackle a new and better > syntax for entity declaration. I concede that many, perhaps most, general entities are document specific, but not all. Consider the MIXED element from the my early drafts of XSchema itself. The form <MIXED> <REF .../> <REF .../> ... </MIXED> declared #PCDATA-and-element content, whereas "<MIXED/>" declared #PCDATA-only content as a degenerate case. The DTD could have declared (though actually it didn't) <!ENTITY PCDATA "<MIXED/>"> to allow people to write "&PCDATA;" in XSchemas as a better-documented version of "<MIXED/>". Surely this entity would be worthy of declaration in the XSchema XSchema? > Now, it may be that the "Entity" element is only intended for use > within the schema. If so, great, but I think the name should reflect > that. Maybe call it "module"? No, not at all. There is no XSchema equivalent of parameter entities. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 8 20:05:32 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:06 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) References: <000d01bd92f9$2f249300$cbbc38cb@NT.JELLIFFE.COM.AU> Message-ID: <357C2780.B68137EF@locke.ccil.org> Rick Jelliffe wrote: > So I suggest that you build this into XSchema > from the start: you can do this simply by using HTML's meta element, Actually, an XML element that is ESIS-equivalent. > and by adding HTML's body element at the end, to fit in any > miscellaneous text that the person wants to add. I think this point is handled better by allowing Doc in XSchema elements to go anywhere, not just at the beginning. > Also, I have allowed multiple title elements, to be differentiated > according to language, for i18n. I think this is overkill: titles are metadata in HTML, and (Itsy Bitsy) HTML is metadata in XSchema, so these titles would be meta-metadata. Still, I'm not utterly opposed to it. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 8 21:06:15 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:06 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) References: <Pine.GSO.3.96.980608141621.14547A-100000@calum> Message-ID: <357C35C2.A7F04272@locke.ccil.org> Paul Prescod wrote: > Question 1: John, how do you see XSchemas working technically? I agree with everything you say except > all entities will have been resolved (or not resolved) by > the time the processor sees the data. where for "will have been resolved" read "may or may not have been resolved, depending on the kind of XML parser in use". (I know that you favor "should have been resolved".) As 5.2, bullet 2, of the XML spec says: # [A] non-validating processor [may or] may not [...] include # the replacement text of internal entities [...] where doing so # depends on having read declarations in external or parameter # entities. > Question 2: What is the role of a "schema" > > My definition is: "A document that describes a class of documents." > Do you agree? Yes. However, the use of certain entity references may be a part of the characterization of the class. For example, it is part of the characterization of HTML 4.0 documents (and also of Itsy-Bitsy-compliant document fragments) that they use the "-//W3C//ENTITIES *//EN//HTML" entities. > If so, then what would be the purpose of text substitution > macros in a schema language? XSchema processors don't have to do the macro-expansions themselves; hopefully, the XML processor will take care of that. > I went into these issues in detail in this message: > > http://www.lists.ic.ac.uk/hypermail/xml-dev/9805/0428.html Okay, I've been meaning to comment point-by-point (forgive me for not doing it before; I wasn't on XML-DEV when you posted it): #1: I agree that not all entity declarations belong in an XSchema, but that is not the same as saying that none do. #2: I don't understand the relevance of this. For a document instance (with varying DOCTYPE declaration) to be validatable by more than one DTD, the entities it uses must be declared by all the DTDs. Similarly but weaker, for a document to be validatable by more than one XSchema, the entities it uses must not be declared in conflicting ways by any pair of XSchemas: either no declaration, or only one, or more than one that agree. Sets of XSchema entity declarations can be brought into larger XSchemas using external general entities, just as is the case for DTD entity declarations. #3: I don't see this. DTDs cannot be reused as such, or even *used* as such; as you say, they are part of documents. But the external parameter entities that are loosely called "DTD"s, the contents of .dtd and .ent files, *they* can be reused. This is true for both DTD format and XSchema format, given that XSchemas can include other XSchemas. #4: Agreed. #5: Agreed. The purpose of including an entity in an XSchema is *not* to enable macro-expansion. #6: I'm not sure I understand this, given that XML entities are always synchronous: an external general entity looks like a document instance without a prologue, except that it need not have a root element either. The example seems to have to do with macro-expansion, and converges with #5. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Mon Jun 8 22:18:20 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:06 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) In-Reply-To: <357C26DC.CD255EBA@locke.ccil.org> (message from John Cowan on Mon, 08 Jun 1998 14:01:00 -0400) Message-ID: <199806082016.QAA06111@ruby.ora.com> [John Cowan] > I concede that many, perhaps most, general entities are document > specific, but not all. Consider the MIXED element from the my early > drafts of XSchema itself. The form > > <MIXED> <REF .../> <REF .../> ... </MIXED> > > declared #PCDATA-and-element content, whereas "<MIXED/>" declared > #PCDATA-only content as a degenerate case. The DTD could have > declared (though actually it didn't) <!ENTITY PCDATA "<MIXED/>"> to > allow people to write "&PCDATA;" in XSchemas as a better-documented > version of "<MIXED/>". > > Surely this entity would be worthy of declaration in the XSchema > XSchema? There are certainly cases where an entity is useful for a class of documents, but generally if an entity is of interest to more than one document, it's also of interest to more than one class of documents: for instance, the ISO character entity sets. I think the problem of defining entity replacements is fundamentally different from defining element structures, and should be addressed separately. Now, certainly a class of documents could be defined by a combination of element structure restrictions and an initial set of defined entities, but the two things should not be conflated as DTDs conflate them. > No, not at all. There is no XSchema equivalent of parameter > entities. That's unfortunate. We tried to kill them in XML, but couldn't because they're so useful. The processing concerns they introduced in XML go away if you treat them as ID'd objects and references thereto, so there's no reason to avoid them and very good reasons to include them. Especially since the syntax is going to be more verbose, the gain in reusing pieces is larger. -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Mon Jun 8 22:33:50 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:07 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) Message-ID: <UPMAIL17.199806082031550423@classic.msn.com> JC> No, not at all. There is no XSchema equivalent of parameter JC> entities. CM>That's unfortunate. We tried to kill them in XML, but couldn't CM>because they're so useful. The processing concerns they introduced in CM>XML go away if you treat them as ID'd objects and references thereto, CM>so there's no reason to avoid them and very good reasons to include CM>them. Especially since the syntax is going to be more verbose, the CM>gain in reusing pieces is larger. There is no XSchema 1.0 equivalent to parameter entities, but I expect that we'll certainly see entity usage, perhaps with 'traditional' entities filling in the gaps. I'd like to see XLink used for this, when and if we know whether XLink is willing to support outright text inclusions. The gain in reusing pieces is enormous, but the first step is building the schema as XML pieces that can be reused easily. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Mon Jun 8 22:49:04 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:07 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) In-Reply-To: <Pine.GSO.3.96.980608163055.22077A-100000@calum> (message from Paul Prescod on Mon, 8 Jun 1998 16:34:32 -0400 (EDT)) Message-ID: <199806082047.QAA07561@ruby.ora.com> [Paul Prescod] > Reuse is important, but it should be more structured than even IDs > and references. It should be strongly-typed. Something that is an > attribute type in one context should be an attribute type in all > contexts. It is the typelessness of parameter entities that causes > problems. Getting all of the object types right in XSchema 1.0 would > probably be a bigger project than we need. But if they're general entities in XSchema, then they get parsed in context, and their type is enforced by the XSchema DTD. Picture this: XSchema with XSchema DTD, before non-DTD entity mechanisms: <?xml version="1.0"?> <?xml:namespace ns="http://www.purl.org/NET/xschema" prefix="xsc"?> <!DOCTYPE xsc:xschema SYSTEM "http://www.purl.org/NET/xschema/xschema.dtd" [ <!ENTITY para.content "<xsc:mixed> <xsc:element idref="emph"/> <xsc:element idref="literal"/> <xsc:element idref="term"/> </xsc:mixed>"> ]> <xsc:xschema> <xsc:elementdecl id="para"> ¶.content; </xsc:elementdecl> </xsc:xschema> This is a bit ugly, but it's clean: the type of a "parameter" entity is validated because it's parsed in context. Unlike DTD parameter entities, they have to be declared in the prolog to the schema, but that makes parsing cleaner. But then, once there's a non-DTD way to declare entities: <?xml version="1.0"?> <?xml:namespace ns="http://www.purl.org/NET/xschema" prefix="xsc"?> <?xml:namespace ns="http://www.purl.org/NET/xents" prefix="xent"?> <my-document-bag> <xent:entitydecl id="para.content"><![CDATA[ <xsc:mixed> <xsc:element idref="emph"/> <xsc:element idref="literal"/> <xsc:element idref="term"/> </xsc:mixed> ]]></xent:entitydecl> <!-- this is one example of why I think that you shouldn't try to tackle entity declarations just yet... --> <xsc:xschema> <xsc:elementdecl id="para"> ¶.content; </xsc:elementdecl> </xsc:xschema> </my-document-bag> -Chris -- <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN"> <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN" "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487 <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 8 23:26:36 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:07 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) References: <Pine.GSO.3.96.980608153459.16454F-100000@calum> Message-ID: <357C5671.45E643F7@locke.ccil.org> Paul Prescod wrote: > If the entity is NOT resloved by the time that the XSchema processor sees > it, then I know of no way technically for the XSchema processor to tell > the XML parser to re-parse the document with a particular value for the > entity. SAX does not provide such a communication path. None of the other > parsers I have used do either. I hope they never do. The XML-specific part of the DOM, however, does allow you to determine what parts of the document were incorporated by reference to what entities. This is not the same as *changing* the entity replacement after the fact, to be sure. > So if XSchema processors are to be able to direct parsers to replace > entities, we will have to rewrite all of the parsers to allow that! We > will also have to make common the nasty habit of not processing entities > immediately. Correct. However, the appearance of entity declarations (not necessarily definitions) in the XSchema allows an XSchema validator to determine what particular entities were used, and whether they were replaced in accordance with the XSchema or not. The fact that the SAX parser interface doesn't provide the necessary information is neither here nor there. SAX intentionally does not provide full information about XML document instances. > cpy.xsc > <ENTITY NAME="COPYRIGHT">...</ENTITY> > > Now I've got a document that depends on it: > > <?XSC schema="cpy.xsc"> > <FOO> > ©right; > </FOO> > > That document is simply not well-formed in XML terms. The XSchema has no > opportunity to intervene, either technically via SAX, or from a linguistic > point of view according to the XML spec. The document is not XML. Nobody denies this, certainly not I. > The only way I know to get around it is to compile cpy.xsc to cpy.dtd and > change the processing instruction to a DOCTYPE. But then you've thrown > away extensibility and usability. I don't think this is the *only* thing to do with XSchemas, but I do think that it is *one* way to use them. Equivalently, one could compile an XSchema and a document instance purporting to conform to it into an XML document instance with only an internal DTD subset, and validate the result. The resulting document instance would be considered disposable, of course. > I don't see how XSchema will be any different if it requires close > communication between the parsers and the XSchema processor on entity > expansion. It wouldn't. > I can think of a few ways to handle entity sets like HTML's. One would be > to use separate declarations. Another would be to put both the entity > declaration and the schema declaration in an external entity that you > include in your doctype declaration. > > My primary philisophic complaint is that I see schemas not as providing > resources or definition to a document, but as describing a class of > documents. I might accept that a schema could say that © is allowed > in documents of type HTML, but as soon as you turn that around and say > "© is available to HTML documents and it means &U...;" I get > uncomfortable because we are back in the situation of having the language > do two things and back into our round-trip communication situation. As I keep saying.... XSchema processors should not expand entity references themselves, but allow that to be done by the XML processor. XSchema processors that know what entity references should exist in a document instance can validate that those references do exist, and that they refer to the proper thing. One approach, given that general references must be synchronous, would be to give the internal-entity declaration a content model of ANY, and let its content be the replacement itself, rather than #PCDATA which represents that replacement. Then validation would consist of checking that expanded entity references in the DOM of the document are EQUAL (in a Lisp-y sense) to entity definitions in the DOM of the XSchema. > Resources (namespaces, characters, entities, etc.) are one thing. > Constraints are another. I'd like to keep them separate. And I would like to keep them together. A matter of taste. > I would have > expected each XSchema to be applied individually as if the others did not > exist. It's like: "I've got this document..I'll test if it conforms to > HTML 2.0. It does! I'll test against HTML 3.0. It does! I'll test against > HTML 4.0. It doesn't." In other words, schema testing should be > "side-effect-free." That is what I meant. > If we go with this model, then the entities required would have to be > declared in all schemas. Only if validation requires that every entity in the document instance appear in the XSchema. I don't think that's a requirement, given that XSchema processors aren't responsible for entity reference expansion. IOW, a document may refer to entities that aren't defined in any XSchema (necessarily they are declared in the document's DTD, though). > (I don't like that because it requires > communication between the people who design the schemas. So if I want to > check a document (part-wise) against both MATHML and HTML, I would somehow > have to make sure that the two schemas had the same entities. More weakly, that they do not define the same entity in conflicting ways. > My point was that people misunderstand DTDs and there are many, many > subtle problems caused by the fact that documents and DTDs are so closely > tied. I don't want to repeat that in XSchema. I was basically concerned > about people trying to have DOCTYPE's pointing to XSchemas. > > #5: Agreed. The purpose of including an entity in an XSchema is > > *not* to enable macro-expansion. > > I don't understand this. What else do (text) entities do? Entities don't "do" anything. One thing to do with references to entities is to expand them to their referents. Another thing to do is to find out whether the content of the entity is what you expect it to be. Here's an example. Let's say that some XSchema named "foo" declares that the "Auml" internal entity has the value "Ä". A document purporting to conform to this XSchema might define "Auml" as "Å", either in its internal subset or in its external subset. Such a document would *fail* validation against "foo". Without entity declarations in "foo", that test would not be possible. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 8 23:28:38 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:07 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) References: <199806082016.QAA06111@ruby.ora.com> Message-ID: <357C5725.F7FA27FC@locke.ccil.org> Chris Maden wrote: > > No, not at all. There is no XSchema equivalent of parameter > > entities. > > That's unfortunate. We tried to kill them in XML, but couldn't > because they're so useful. The processing concerns they introduced in > XML go away if you treat them as ID'd objects and references thereto, > so there's no reason to avoid them and very good reasons to include > them. Especially since the syntax is going to be more verbose, the > gain in reusing pieces is larger. As stated elsewhere, piece reuse can be achieved with general entities declared within the (internal subset of) the DTD of the XSchema document. That doesn't mean that I wouldn't be interested in defining an XML-level mechanism for XSchema piece reuse using element/attribute machinery. The main question there is just what should be reusable. To my mind, the obvious choices are content models or parts thereof, and attributes or groups thereof. Do you see anything else that could usefully be reused? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jun 8 23:51:01 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:07 2004 Subject: [Somewhat Offtopic] Transclusion Message-ID: <357C5C7E.E3BA51F8@locke.ccil.org> The very interesting DeRose/Maden paper on transclusion at http://oreilly.com/people/staff/crism/transclu.html is an excellent discussion of transclusion for *quotation*, but it does not address transclusion for *reuse* at all. (This is not a complaint, just a comment.) To explain the distinction, consider transcluding a copyright license from some other document, such as the GPL. If you want to *quote* the GPL as it applies, say, to the gcc compiler, then you are transcluding it for *quotation*. If, OTOH, you want to apply the GPL to your own document, you are transcluding it for *reuse*. In that case, the GPL is not being quoted in your document, but rather replicated into the appropriate slot of your document --- the (virtual) copyright page. It should appear in the font & style appropriate to a copyright page, not to that appropriate to a (block) quotation. In either case, the stylesheet of the referring document is the controlling element. I believe that T.H. Nelson's original concern was with transclusion for reuse. Traditionally, authors have been faced with a dilemma: express a thought in your own words, or quote someone else's wording. Transclusion for reuse allows a third possibility: use someone else's wording to express your thought, in such a way that the curious can determine that someone else chose the wording (and with the possibility of compensating the original author). Transclusion for reuse is a way of making other people your co-authors, with credit and (possible) compensation, but without their specific consent. (Publishing one's document in transclusible form would constitute a general consent.) Comments? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 9 00:10:09 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:07 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) Message-ID: <UPMAIL17.199806082207490095@classic.msn.com> PP> Resources (namespaces, characters, entities, etc.) are one thing. PP> Constraints are another. I'd like to keep them separate. JC>And I would like to keep them together. A matter of taste. Unfortunately, I think it's a lot more than a matter of taste. Making XSchemas perform text substitutions requires a much more complex processing model. If we keep XSchema to constraints, the following processing model will work: Parse document for well-formedness (expand entities as nec.) Parse XSchema Check results of document parse against XSchema constraints If we add entities to XSchema, we get: Parse document for well-formedness (expand entities as nec.) Parse XSchema Reprocess document to expand entities from XSchema Check results of document parse against XSchema constraints It's a lot more work, and I think it's unnecessary. Well-formed documents can include entities, albeit with some weird restrictions on external entities. The parsers that are already available, even the simplest, can already perform this work quite simply, before the document reaches the XSchema verification process. Documents that used entities that were only declared in an XSchema would also no longer be interoperable with XML 1.0 parsers - a big problem in my book. By keeping entities _out_ of XSchema we can: a) take advantage of one of the things XML currently does reasonably well b) leave room for all kinds of entity madness in a _future_ standard c) ensure interoperability with well-formed XML documents d) make XSchema _much_ less work to implement Sound good? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From David.Brownell at Eng.Sun.COM Tue Jun 9 03:39:40 1998 From: David.Brownell at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:02:07 2004 Subject: draft-whitehead-mime-xml-04 Message-ID: <199806090138.SAA15240@argon.eng.sun.com> > Regarding your proposal, an XML document entity can also be an > external parsed entity. Not if it's valid ... <!DOCTYPE ...> isn't allowed by the grammar. That, and the way "<?xml ... encoding='...'?> isn't permitted in DTDs, have made me wonder if there are any other litle nudges away from traditional DTDs. XSchema anyone? - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From matthew at praxis.cz Tue Jun 9 11:10:47 1998 From: matthew at praxis.cz (Matthew Gertner) Date: Mon Jun 7 17:02:07 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) Message-ID: <01bd9386$50ab0d50$020b0ac0@xerius.ini.cz> >By keeping entities _out_ of XSchema we can: >a) take advantage of one of the things XML currently does reasonably well >b) leave room for all kinds of entity madness in a _future_ standard >c) ensure interoperability with well-formed XML documents >d) make XSchema _much_ less work to implement > >Sound good? Chalk up one vote for this. I just can get over the feeling that including a mechanism for entity declarations in XSchema would be a step in the wrong direction. Okay, this has a lot to do with the fact that I never liked the way entities are managed in the first place. It is extremely confusing to someone learning XML that referencing some external binary data and transcluding external text use the same mechanism. On top of this, an entity reference syntax is simply too terse. They is no way to document or parameterize the use of an entity reference (without resorting to comments), which is why it was necessary to invent XLink in the first place. As far as parameter entities are concerned, I sincerely hope that XSchema will evolve a way to handle content model reuse cleanly in the future. A combination of what is essentially text replacement combined with overloading of entire attribute lists and content model declarations is not going to cut it in the mass market. There seems to be general agreement about this. For other entity types (internal, external parsed and unparsed), using XLink instead of entity references seems to have overwhelming advantages. It is more flexible (e.g. enabling multiple targets), cleaner (e.g. enabling specification of link and content roles) and doesn't require the use of an additional low-level syntactic construct. As far as text transclusion is concerned: isn't this the purpose of the "embed" value for the "show" attribute? It would probably be legitimite to ask what this has to do with XSchema, but this just drives the point home. Text-replacement mechanisms have nothing to do with defining a class of document and certainly nothing to do with defining appropriate mechanism for schema reuse. Both of these issues would be fascinating areas for future discussion; IMO they should be kept separate from the initial XSchema spec. Regards, 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/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Tue Jun 9 11:30:27 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:07 2004 Subject: Entities in XSchema (was: XSchema Spec, Sections 2.0 and 2.1 ...) In-Reply-To: Chris Maden's message of "Mon, 8 Jun 1998 16:16:38 -0400 (EDT)" References: <199806082016.QAA06111@ruby.ora.com> Message-ID: <ud8ciapnh.fsf@digitivity.com> Chris> Chris Maden <URL:mailto:crism@oreilly.com> => In article <199806082016.QAA06111@ruby.ora.com>, Chris wrote: Chris> I think the problem of defining entity replacements is Chris> fundamentally different from defining element structures, Chris> and should be addressed separately. ... [T]he two things Chris> should not be conflated as DTDs conflate them. I'm in general agreement that a notation for defining general entities should be separated from XSchema, which shouldn't try to take on more than declaring element structure. The one case where the two meet is when a default value is specified for an attribute of type ENTITY or ENTITIES. If the two are separated, it becomes difficult or impossible for an XSchema processor to ensure that the entity exists. Chris> We tried to kill [parameter entities] in XML, but couldn't Chris> because they're so useful. ... [S]ince the syntax is going to Chris> be more verbose, the gain in reusing pieces is larger. You can declare general entities internal to a XSchema document (at least I think you can - the section on conformance needs to explicitly allow this). -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Jun 9 14:35:24 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:07 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) Message-ID: <199806091054.MAA03907@berlin.dvs1.tu-darmstadt.de> Simon St. Laurent wrote: > PP> Resources (namespaces, characters, entities, etc.) are one thing. > PP> Constraints are another. I'd like to keep them separate. > > JC>And I would like to keep them together. A matter of taste. > > Unfortunately, I think it's a lot more than a matter of taste. Making XSchemas > perform text substitutions requires a much more complex processing model. It's also a matter of what our goals are. My original hopes for XSchema were relatively modest -- I wanted a standard way to explore DTDs. A side-effect was that parsers could use the information for validation. I also had some vague hopes for schema reuse and laying a foundation for strong typing. When John pointed out that you couldn't validate an XML document without entities and notations, I had to agree and added both to my DTD. It simply didn't occur to me that such validation would be done outside the parser -- the back-and-forth between XML applications and parsers described by John and Paul. I just assumed that validating parsers would, in the future, read XSchemas as they now read DTDs. Having now read the multitudinous arguments on each side, I have come to the conclusion that entities don't belong in XSchema for two reasons: 1) Requiring that a parser include information (an entity definition) from an XSchema document just to get a well-formed document is a bad mistake. Evolutionary steps that require you to throw away existing software don't have much chance of success. 2) I find the view of XSchema-as-schema far more compelling than XSchema-as-DTD. Although both fit my original goal (DTD exploration), XSchema-as-DTD is a dead end, while XSchema-as-schema is a building block for the future. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jun 9 14:57:33 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:07 2004 Subject: Off topic (RE: XSchema Spec, Sections 2.0 and 2.1 (Draft 1)) In-Reply-To: <01bd9386$50ab0d50$020b0ac0@xerius.ini.cz> Message-ID: <000201bd93a6$67022550$b0bc38cb@NT.JELLIFFE.COM.AU> > From: Matthew Gertner > It is extremely confusing to > someone learning XML that referencing some external binary data and > transcluding external text use the same mechanism. In my experience, this happens when people expect an entity reference to be like a macro call, which it is not. Entity references are really kinds of links, with particular access semantics (in XML, these are basically two: "parse" and "don't parse"). > On top of this, an entity > reference syntax is simply too terse. They is no way to document or > parameterize the use of an entity reference (without resorting to > comments), > which is why it was necessary to invent XLink in the first place. Well, they are things that were left out of XML on purpose to simplify things. Just for people's information, since it helps understand "why is this not there?", SGML allows attributes on entity declarations (well, actually on things that have notations). So the reference is not parameterized (with attributes) but the declaration is. SGML even lets you chain entity declarations, to say "this entity is inside this entity is inside this entity" (Formal System Identifiers), for example for compressed archive files or patch systems. In any case, you can parameterize an entity reference: wrap it in an element with the appropriate attributes and write some code that can use that structure. Or use an ENTITY attribute even. It is a question of style more than substance, I think. SGML style was "remove constants to declararions in the header" and "declare something before you use it" while HTML is "declare and use in the same place". XML tries to allow both styles, whichever is appropriate for the scale of your document. XML was not designed to be a complete solution to all markup problems. It was meant to be simple, in the full knowledge that this simplicity would make it unsuitable for many real-life uses. Personally, I expect that as people get more used to the problems of electronic publishing and document construction, many of SGML's discarded features will get re-adopted (though in nice disciplined layers) under different guises, and branded with an "X" so people can pretend it is not SGML. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Tue Jun 9 14:59:07 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:07 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) In-Reply-To: <199806091054.MAA03907@berlin.dvs1.tu-darmstadt.de> Message-ID: <000301bd93a6$6de72140$b0bc38cb@NT.JELLIFFE.COM.AU> > From: Ron Bourret > Having now read the multitudinous arguments on each side, I have > come to the > conclusion that entities don't belong in XSchema for two reasons: An equivalent term for "entity" is "predeclared resource". So are you saying that all identifiers of resources are not allowed, or only that predeclarations are not allowed? Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From David.Rosenborg at xsse.se Tue Jun 9 15:15:14 1998 From: David.Rosenborg at xsse.se (David Rosenborg) Date: Mon Jun 7 17:02:07 2004 Subject: Entities (was Re: XSchema Spec, Sections 2.0 and 2.1 (Draft 1)) References: <199806082016.QAA06111@ruby.ora.com> <357C5725.F7FA27FC@locke.ccil.org> Message-ID: <357D3469.C15A3FF9@xsse.se> John Cowan wrote: > That doesn't mean that I wouldn't be interested in defining an > XML-level mechanism for XSchema piece reuse using element/attribute > machinery. The main question there is just what should be reusable. > To my mind, the obvious choices are content models or parts thereof, > and attributes or groups thereof. Do you see anything else that > could usefully be reused? Hi! I've been working on an XSchema-like (by concept) solution for a couple of weeks. My first intent was to do "literate programming" for our DTDs i.e integrate documentation into the DTDs. I ended up with something that looks very similar to your XSchema proposal with additional markup for documentation (which has also been discussed on this list). Having the power of managing my own framework for specification structures (which is a weakness too, naturally) I thought that I just as well could remove or rather replace the parameter entity machinery (which I dislike). My short analysis gave the following desired characteristics that I used parameter entities for earlier: * Modularity * Parameterisation * Reuse I implemented those with with the follwing constructs * Inheritance of type, an "IsA" relation * Inheritance of structure * Use of structure by reference Apart from the constructs you mention I also find it usful to parameterise enumeration values in attribute declarations. IMO parameter entities (or general entities in XSchema instances) are not good candidates for this. They work on a syntactic level rather than on a structural level and more important, they are imperative or explicit in contrast to declarative. This makes them hard to use and maintain (e.g you must know what will get expanded when and by whom). Instead I think it is of greatest importance that native constructs for basic inheritance and parameterisation are included XSchema. Since simplicity is a motto I think parameter entities (and alike) must go away. They might be somewhat simpler to implement and understand (as a concept) since they are more primitive, but in practice, the resulting schemas will be far more complex and hairy compared to a declarative solution. To be more concrete, the example below outlines my current implementation. I expect to make the results of this public as a case study on our website when it is complete. Currently I use DSSSL in Jade to convert the schemas into DTDs (and the code is fairly simple). Cheers, </David> ----------------------------------------------------------------------- David.Rosenborg@xsse.se Stockholm Stock Exchange Example: My schema have a section <fragments> which can hold definitions of parts of content models and attribute lists. The interesting parts are the "implements" attribute and the base/extends construct. First some common elements and constructs <document-type name="common"> <title>Common Elements ... chapter p ... The following is a simple document schema. Simple Document vanilla-document note strong ... The DTD generated for vanilla-doc: ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Jun 9 15:17:42 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:07 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) In-Reply-To: <357C5671.45E643F7@locke.ccil.org> Message-ID: On Mon, 8 Jun 1998, John Cowan wrote: > > Here's an example. Let's say that some XSchema named "foo" > declares that the "Auml" internal entity has the value "Ä". > A document purporting to conform to this XSchema might define "Auml" > as "Å", either in its internal subset or in its external subset. > Such a document would *fail* validation against "foo". Without > entity declarations in "foo", that test would not be possible. Why would you want to do that? Entities explicitly live in the user's namespace and I think that it is good that they should have complete control over their names. I can't imagine why a schema designer would complain that they were using the "wrong" definition. It seems to me that that would be like complaining that they used the "wrong" namespace prefix. SAX is relevant because it represents the communities combined idea of what a typical application should expect from a typical parser. I can see why an editor or database system might want more, but I don't think that a schema language should. It isn't "in the XML spirit" to require calisthetics from implementors for minor gains (verifying entity replacement strikes me as a very minor gain). Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Tue Jun 9 15:24:18 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:08 2004 Subject: draft-whitehead-mime-xml-04 In-Reply-To: Message-ID: <199806091326.AA01402@murata.apsdc.ksp.fujixerox.co.jp> Paul Prescod wrote: > XML does not define a concept of "DTD" that can stand alone separate from > an XML document. The closest you could come is "set of markup declarations." > But all "sets of markup declarations" can be used as entities. If you are saying that something is an external DTD subset only because it is referenced as such from a document entity, you are certainly correct. As an extreme case, consider a file containing a single comment. It can become an external DTD subset, external parameter entitiy, or external parsed entity, if it is referenced as such. Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 9 16:18:26 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:08 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) Message-ID: Rick Jelliffe wrote: >Almost all DTDs, or fragments which can stand by themselves as >reuseable components, end up with a similar stucture which allows >metadata headers, the actual body, and a section for annotations >and floating elements. and proposed: (cleaned up for my namespace error) > > ( XSC:Doc?, (XSC:ElementDecl | XSC:Entity | XSC:Notation | > XSC:Namespace | XSC:XSchema)*)> ***The full text of his DTD proposal is at the bottom of this message.*** I'm not completely opposed to this suggestion, though it does seem to add another layer of elements. What this raises for me is what information needs to be supported by these top level XSchema elements. Our Doc element, John's DTD, refers to a %horiz.model entity that isn't declared. Currently I've suggested that the XSchema element use the following attribute declarations: > XSC:Version CDATA #FIXED "1.0" > XSC:MimeType CDATA "application/xml" > XSC:FileExtension CDATA "xml"> Version, MIME, and File Extension are all very well, but what do we do for an XSchema title? Wouldn't it seem useful to provide human-readable titles or other information, much as the headers in Rick's proposal do? We could use the XSC:Doc element to provide this additional header information as well. Suggestions? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies Full proposal from Rick: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Jun 9 16:24:55 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:08 2004 Subject: XSchema Spec, Sections 2.0 and 2.1 (Draft 1) Message-ID: <199806091359.PAA04569@berlin.dvs1.tu-darmstadt.de> Rick Jelliffe wrote: > An equivalent term for "entity" is "predeclared resource". > > So are you saying that all identifiers of resources are not allowed, or only > that predeclarations are not allowed? Predeclarations. That is, XSchema should not support a mechanism for declaring entities. As Paul Prescod pointed out a while back, elements and attribute declarations define a logical structure for an XML document. Entity declarations and references define its physical structure. If we view XSchema as defining the logical structure, not as defining the physical structure or providing a wholesale replacement for the DTD (and I think we should), entity declarations have no place in XSchema. Another way of saying this is that XSchema applications should not be in the business of resolving entity references. This does not preclude the use of entity references in documents that refer to XSchema documents -- the requirement, for example, that a document that refers to an XSchema document can't include & is a bit onerous, to say the least. It might not even preclude the declaration and use of general entities in XSchema documents themselves -- this is still up for discussion, but a frequent suggested replacement for parameter entities in XSchema is the use of parsed general entities in the XSchema document itself. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 9 17:33:25 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:08 2004 Subject: Entities in XSchema References: <199806082016.QAA06111@ruby.ora.com> Message-ID: <357D5465.7226E8EF@locke.ccil.org> Many, many XML-DEVers wrote, in effect: > Entities in XSchemas suck big ones. I surrender. Even when the XSchema-processors-can't-expand-entities meme has worked its way out of the system, there remains the Why-would-you-want-to-do-that???? meme, and I very well realize there's no end to that argument. "Eleven men well armed", as Jno. Swift has it, "will certainly subdue one single man in his shirt." If, however, purely declarative information is to be removed from XSchemas, then I think that parts of the attribute-type and attribute-value declaration syntax should go. In particular, attribute types are reduced to Name (ID, IDREF, ENTITY, NOTATION), Names (IDREFS, ENTITIES, NOTATIONS), Nmtoken, Nmtokens, and CData; attribute values are reduced to #REQUIRED, #FIXED "foo", and other. Without information on the names of valid entities and notations, and potentially without information on IDs, then ID, IDREF, ENTITY and NOTATION are indistinguishable; IDREFS, ENTITIES, and NOTATIONS also all look the same. The only remaining distinction is syntactic. Saying what the specific default value is or whether there is none is overspecific (the DTD must bear this information, and an XSchema would be either redundant or conflicting, a Bad Thing); the only three cases are: a) the value must be present and must be "foo" (#FIXED), b) the value must be present but can be anything (#REQUIRED), or c) the value need not be present. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From paul at arbortext.com Tue Jun 9 18:27:13 1998 From: paul at arbortext.com (Paul Grosso) Date: Mon Jun 7 17:02:08 2004 Subject: XML Formal Public Identifier Message-ID: <98Jun9.122112edt.26886@thicket.arbortext.com> At 13:21 1998 06 08 -0400, Tim Bray wrote: >At 01:12 PM 6/8/98 -0400, Daniel Pitti wrote: >>Is there an official (W3C) Formal Public Identifier for XML? And notation >>declaration? > >No. XML 1.0 does not support FPIs. -Tim I'm not sure how Tim is using "support" in this case. In the XML Rec, production 12 [1] is for PubidLiteral which is described in the XML Rec [2] as follows: In addition to a system identifier, an external identifier may include a public identifier. All FPIs are public identifiers (the set of FPIs is a subset of the set of public identifiers). Finally, whether or not you consider this "support" of FPIs, the original question is not unreasonable; the W3C could still opt to define an FPI for the XML Rec so that people could write a notation declaration such as: (Note that XML notation declarations [3] do not require a system identifier as external identifiers for entity declarations do.) I am not aware of this issue being raised before, so I believe the current answer to the question is "no, there is no official FPI for XML," but I see no technical reason there couldn't be. [1] http://www.w3.org/TR/REC-xml.html#NT-PubidLiteral [2] http://www.w3.org/TR/REC-xml.html#sec-external-ent [3] http://www.w3.org/TR/REC-xml.html#dt-notation xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 9 19:56:29 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:08 2004 Subject: Entities in XSchema - moving toward a processing model Message-ID: John Cowan wrote: >Many, many XML-DEVers wrote, in effect: > >> Entities in XSchemas suck big ones. > >I surrender. Good... one less section to write, and a lot less to explain about processing. >If, however, purely declarative information is to be removed from >XSchemas, then I think that parts of the attribute-type and >attribute-value declaration syntax should go. In particular, >attribute types are reduced to Name (ID, IDREF, ENTITY, NOTATION), >Names (IDREFS, ENTITIES, NOTATIONS), Nmtoken, Nmtokens, and CData; >attribute values are reduced to #REQUIRED, #FIXED "foo", and other. I think you're going a little too far here, though I could support that reduction to a certain extent. >Without information on the names of valid entities and notations, >and potentially without information on IDs, then ID, IDREF, >ENTITY and NOTATION are indistinguishable; IDREFS, ENTITIES, and >NOTATIONS also all look the same. The only remaining distinction >is syntactic. How do people feel about this? Is getting a normalized list of entities from an XML parser too hard? How about notations? Or should notations be brought into the XSchema spec? (They have a section in the current outline.) >Saying what the specific default value is or whether there is none >is overspecific (the DTD must bear this information, and >an XSchema would be either redundant or conflicting, a Bad Thing); >the only three cases are: a) the value must be present and must >be "foo" (#FIXED), b) the value must be present but can be anything >(#REQUIRED), or c) the value need not be present. Conflicts between DTDs and XSchemas are something we need to consider for processing in general, not just with entities. (Which we seem to have resolved.) I have to admit that when I first started out on this path, I wanted to strip XML down to its barest syntactical foundations - what I call simple XML - and rebuild the DTD syntax, entities and all. The more I've looked at DTDs, with help from many of the contributors on this list, the less I wanted to rebuild the entire structure. DTDs do too damn many things, not all of them well. (In this regard, they remind me very much of HTML, actually.) The processing model I'd like to be able to use for XSchema revolves around _well-formed_ documents, not the simple documents I was talking about earlier. (For those interested in simple XML, there's a chapter on it in my next book, and it more or less is similar to the tools covered in Chapter 3 of XML: A Primer.) Using the full possibilities of well-formed documents allows us to use general entities without any difficulties, and means we don't have to create anything weird that tells parsers not to touch the entities. In short, we can build on the non-validating parsers already available, and create 'real' applications with XSchema. The fun part comes in building a separate validator. I'd like to see a validator (we need to come up with a different name for it) that can use the SAX API to read in both the document and the XSchema. Applications that use XSchema will need to avoid validating parsers, unless we can figure out a way to allow DTD validation and XSchema validation/verification/whatever to co-exist. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 9 21:00:59 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:08 2004 Subject: XSchema Spec, Section 1.0 (Draft 2) Message-ID: So far, only the introduction to the section has been criticized. Fortunately, the critic (thanks, Paul!) included a nearly complete suggestion for fixing it. What follows is the revised 1.0, not including information in sections 1.1 and later. A complete version of the latest draft of the entire section is available at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies -------------------------- 1.0 Introduction In order for document processing to be reliable, it is necessary to be able to describe classes of documents and to verify individual documents' membership in these classes -- in other words, to be able to express constraints on documents and thus define 'document types'. XML inherits a mechanism for doing this from SGML: the Document Type Definition. XML DTDs can perform a subset of the functions of SGML DTDs. DTDs have many well-documented flaws and it is necessary to experiment with new ideas in schema design. These ideas include a syntax that is more like that of XML document content, certain kinds of extensibility and a cleaner separation between parsing and verifying. XSchema is an experimental schema language designed to provide a starting point for these experiments. So that XSchemas will be immediately useful with existing software, the XSchema specification will describe a conversion from XSchema documents to DTDs. This initial version of the XSchema specification is deliberately simple, providing an initial base for implementations while introducing as few complicating factors as possible. Authors accustomed to DTD creation will find their toolset constricted; it is hoped that supporting software and tools available from other standards will make up for this reduced toolset. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Tue Jun 9 21:01:02 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:08 2004 Subject: XSchema current status - 6/9/98 Message-ID: I missed doing this yesterday, but we seem to have resolved some key issues this morning, so hopefully that's okay. More information about XSchema, including the latest drafts, is available at http://purl.oclc.org/NET/xschema. Please don't reply publicly to this message - instead, reply to the subjects provided in the report. Draft Specification Status: A complete second draft of Section 1.0 is available for comment. [Reply to subject Re: XSchema Spec, Section 1.0 (Draft 2)] A second draft of sections 2.0 and 2.1 is in progress. Questions remain regarding metadata for the XSchema root element itself. I'm currently planning to leave most of them to be solved in the Doc element. [Reply to subject Re: XSchema Spec, Sections 2.0 and 2.1 (Draft 1)] Sections 2.3 and 2.4 are in progress. If anyone would like to adopt a section of the outline, please contact me privately. Questions: We seem to have moved on from these general questions to the details of the spec. In large part, this is thanks to the efforts of John Cowan and Ron Bourret in moving ahead with DTD creation. The questions are repeated below with the conclusions reached as I understand them. Drafts should provide the main current of conversation from here on out. We have four questions in current circulation: 1)How will XSchema use/relate to RDF? [Was subject Re: XSchema Question 1: RDF] In designing XSchemas, we should leave RDF syntax out of the way but definitely keep in mind what Tim Bray said: >But it is easy to tell if something can easily be made into RDF. Here's >the test: if what you are building can be expressed as a bunch of 3-tuples > >(object, propertyname, propertyvalue) > >then it's RDF-able. 2)How will XSchema use namespaces? [Was subject Re: XSchema Question 2: Namespaces] Namespaces will be used throughout the XSchema draft. For now I'm using XSC as the prefix (yes, I know it doesn't matter.) The namespace name (which does matter) will be xschema.org, courtesy of James Tauber, who got to the name before I did. There will be a discussion of the use of namespaces to make certain that users can figure out how to use this without tripping over multiple standards documents. 3)Should XSchema provide internal and external subsets, as do XML DTD's? [Was Re: XSchema Question 3: Internal/External subsets] This question seems to have settled down - for XSchema 1.0 ONLY - to a no. It's functionality people want, but it doesn't seem likely for this iteration because of the complexity of resolving conflicts. 4)Should the use of traditional DTD entity (and other) notation be encouraged in the design, development, and use of XSchemas? [Was Re: XSchema Question 4: XML 1.0/XSchema interactions] There wasn't much interest on this one, but the recent discussions of entities have brought it back. It looks like anything you can do in a well-formed document, including the traditional DOCTYPE notations, will be encouraged. We're still sorting out the delightful issue of XSchemas and DTD validation when used together. 5)Do we want to provide additional information in the XSchema root element regarding XSchema version, for instance? We could add "version='0.1'" or something. [Was subject: XSchema Question 5: Root elment issues; is now subject Re: XSchema Spec, Sections 2.0 and 2.1 (Draft 1)] This is still open, but discussion on it has moved to discussion of the draft. No one seemed interested, so I wrote something for everyone to shoot at. Seems to have worked to some extent. 6)Question: Should entity support be provided in XSchema? [Was XSchema Question 6: Entities] Seems to have resolved into a NO for XSchema 1.0 under the "Re: Entities in XSchema" thread. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Tue Jun 9 21:25:52 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:08 2004 Subject: Entities in XSchema In-Reply-To: <357D5465.7226E8EF@locke.ccil.org> Message-ID: On Tue, 9 Jun 1998, John Cowan wrote: > > Without information on the names of valid entities and notations, > and potentially without information on IDs, then ID, IDREF, > ENTITY and NOTATION are indistinguishable; IDREFS, ENTITIES, and > NOTATIONS also all look the same. The only remaining distinction > is syntactic. Well, XML is funny that way. Text entities are clearly physical. You cannot refer to them in any official way in the logical structure at all. But unparsed entities are probabaly more logical than physical. They can only be used in attribute values. SAX can lead us here too: notationDecl(String, String, String) Receive notification of a notation declaration event. unparsedEntityDecl(String, String, String, String) Receive notification of an unparsed entity declaration event. So NOTATION and (unparsed) ENTITY declarations are considered application level information. ESIS also provides this information. SAX provides information on ID/IDREF attributes, but I don't think that ESIS did, so this is more debatable. Anyhow, I wouldn't care much if we cut loose all of those types. I just don't think that removing them is the natural extension of not checking text entities. > Saying what the specific default value is or whether there is none > is overspecific (the DTD must bear this information, and > an XSchema would be either redundant or conflicting, a Bad Thing); > the only three cases are: a) the value must be present and must > be "foo" (#FIXED), b) the value must be present but can be anything > (#REQUIRED), or c) the value need not be present. We might not need fixed attributes. A fixed attribute is merely an attribute with a single choice. Can't that be represented directly as a choice attribute with a single choice (yes, this implies that we would open up "choice" attributes beyond names...any arguments with that?) So that would allow us to reduce the "optionality" requirement to "optional or required". Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Tue Jun 9 21:31:53 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:08 2004 Subject: [Somewhat Offtopic] Transclusion In-Reply-To: <357C5C7E.E3BA51F8@locke.ccil.org> (message from John Cowan on Mon, 08 Jun 1998 17:49:50 -0400) Message-ID: <199806091930.PAA13669@ruby.ora.com> [This should probably go to alt.hypertext, but I haven't been reading that.] [John Cowan] > The very interesting DeRose/Maden paper on transclusion at > http://oreilly.com/people/staff/crism/transclu.html is an excellent > discussion of transclusion for *quotation*, but it does not address > transclusion for *reuse* at all. (This is not a complaint, just a > comment.) We certainly thought about it. The best way to use transclusion for reuse, though, is with entities. If something's part of your document, make it so. Since a system identifier in XML is a URI, and a URI can include a fragment, and that fragment can be an XPointer, there's really no limitation on what an entity can be. I recognize that there are resources you may want to reuse that don't fit into your DTD, and so are unsuitable to be entities. In that case, transclusion is necessary. But as you say: > Transclusion for reuse is a way of making other people your > co-authors, with credit and (possible) compensation, but without > their specific consent. (Publishing one's document in transclusible > form would constitute a general consent.) I strongly disagree with this. The reason Steve and I proposed always distinguishing transclusion is that otherwise, there will be too much fear of intellectual property theft, and the Web could stagnate. Theft is always a possibility (copy and paste always works), but it shouldn't be made easy. > In that case, the GPL is not being quoted in your document, but > rather replicated into the appropriate slot of your document --- the > (virtual) copyright page. It should appear in the font & style > appropriate to a copyright page, not to that appropriate to a > (block) quotation. In either case, the stylesheet of the referring > document is the controlling element. The stylesheet should be able to control the presentation of the transclusion. I don't agree that it should be able to completely override the browser's border or other delimiter on the transcluded text, though; if you really need it to be seamless, just copy it into your document. I don't have a problem making you do a little bit of work to take someone else's content, even if you do have the right. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 9 22:20:45 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:08 2004 Subject: Entities in XSchema References: Message-ID: <357D98C4.409C2F55@locke.ccil.org> Paul Prescod wrote: > SAX provides information on ID/IDREF attributes, but I don't think that > ESIS did, so this is more debatable. But not all SAX-compliant parsers do: attribute type checking is a validity constraint only, so non-validating parsers are free to return CDATA as the type of all attributes. As one who is fairly SGML-ignorant, I would like to know: Just what is in the ESIS? (If you will, limit the answer to things XML also has.) > Anyhow, I wouldn't care much if we cut loose all of those types. I just > don't think that removing them is the natural extension of not checking > text entities. I was attempting to adopt the distinction between "what IS so" and "what MUST BE so" (which DTDs conflate) and see where it led. Content models say what must be so, and entity declarations say what is so, that much is clear. Attribute declarations are a mixture. > We might not need fixed attributes. A fixed attribute is merely an > attribute with a single choice. Can't that be represented directly as a > choice attribute with a single choice (yes, this implies that we would > open up "choice" attributes beyond names...any arguments with that?) > > So that would allow us to reduce the "optionality" requirement to > "optional or required". Okay, that leads to a model with the following (meta-)attributes of attributes: name CDATA #REQUIRED syntax (name | nmtoken | names | nmtokens | general) #IMPLIED choices CDATA #IMPLIED -- a list of choices or "free" if none -- optionality: (optional | required) "optional" -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Tue Jun 9 22:30:07 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:08 2004 Subject: Entities in XSchema In-Reply-To: <357D5465.7226E8EF@locke.ccil.org> (message from John Cowan on Tue, 09 Jun 1998 11:27:33 -0400) Message-ID: <199806092028.QAA15348@ruby.ora.com> [John Cowan] > If, however, purely declarative information is to be removed from > XSchemas, then I think that parts of the attribute-type and > attribute-value declaration syntax should go. In particular, > attribute types are reduced to Name (ID, IDREF, ENTITY, NOTATION), > Names (IDREFS, ENTITIES, NOTATIONS), Nmtoken, Nmtokens, and CData; > attribute values are reduced to #REQUIRED, #FIXED "foo", and other. Nay. ID, IDREF, and IDREFS are important to identify; an XSchema- based validator can ensure that IDs are unique, and that IDREFs all have a corresponding ID. Likewise, NOTATION(S) says, "here's the attribute on which the element's content is declared". I think keeping ENTITY and ENTITIES is also a good idea. It says that the attribute points to an entity, but doesn't mean that the same schema has to actually declare the permitted entities. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jun 9 22:33:31 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:08 2004 Subject: [Somewhat Offtopic] Transclusion References: <199806091930.PAA13669@ruby.ora.com> Message-ID: <357D9BA6.589DF2C8@locke.ccil.org> Chris Maden wrote: > The best way to use transclusion for > reuse, though, is with entities. If something's part of your > document, make it so. Since a system identifier in XML is a URI, and > a URI can include a fragment, and that fragment can be an XPointer, > there's really no limitation on what an entity can be. Au contraire, h?las! XML spec section 5.2: # The SystemLiteral [specified for an external entity] is called the # entity's system identifier. It is a URI, which may be used to retrieve # the entity. Note that the hash mark (#) and fragment identifier # frequently used with URIs are not, formally, part of the URI itself; # an XML processor may signal an error if a fragment identifier is given # as part of a system identifier. "May", of course, is not synonymous with "must", but one cannot count on reliable transclusion of document parts in this way. XLink does allow it. > The reason Steve and I proposed always > distinguishing transclusion is that otherwise, there will be too much > fear of intellectual property theft, and the Web could stagnate. > Theft is always a possibility (copy and paste always works), but it > shouldn't be made easy. An essential part of Xanadu, which the WWW does not have, was a chargeback mechanism, whereby the original author of a transcluded document is paid pro rata when someone buys the right to read the transcluding document. This is related to the "mechanical licensing" policy for sound recordings: one may always, on payment of compensation, play someone else's copyrighted sound recording even without permission. A variety of clearinghouses are used to implement this policy. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RMcDouga at JetForm.com Wed Jun 10 00:17:11 1998 From: RMcDouga at JetForm.com (Rob McDougall) Date: Mon Jun 7 17:02:08 2004 Subject: 10 big lies (was RE: draft-whitehead-mime-xml-04) Message-ID: <7BB2D3AA23EDD111A9F600805FCC37AB123EDE@ROSSINI> Are the "10 big lies" posted on the internet anywhere? I'd like to see what the other 9 are :). Rob -----Original Message----- From: Paul Prescod [mailto:papresco@technologist.com] Sent: Monday, June 08, 1998 12:34 PM To: MURATA Makoto Cc: XML Dev; ejw@ics.uci.edu; murata@fxis.fujixerox.co.jp Subject: Re: draft-whitehead-mime-xml-04 [snip] The idea that "sets of markup declarations" are really "DTDs" is one of the most pernicious misunderstandings in SGML and XML processing. I think Eliot calls it one of the 10 big lies. [snip] Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Jun 10 02:04:20 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:09 2004 Subject: XSchema Spec Section 2.2, Draft 1 Message-ID: As usual, all comments, suggestions, rantings, etc. are welcome. I'm having a hard time describing these very simple parts, so I'd especially appreciate terminology improvements. Notes: I've expanded parameter entities and added namespace prefixes; otherwise this section (and content models and attributes, coming up next) are based entirely on John Cowan and Ron Bourret's combined DTD. Anything prefixed and postfixed with ... is in italics in the HTML version. The HTML version will be available shortly (as soon as AOL's servers stop giving me read-only filesystem errors, anyway) at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.2 Element Declarations Element declarations in XSchemas are made using the XSC:ElementDecl element and its contents: The XSC:id attribute identifies the name of the element, and is required. An element declaration would look like: ...additionalDeclarations... This declaration would declare an element named "Species", which would appear in an instance as: ...content... The XSC:id attribute must be unique, as it provides the name of the element as declared here, and is also used by other elements to refer to this element in their content model declarations. Note that an element must declare a content model, even if that content model is empty. Documentation (in the XSC:Doc element) and attribute declarations (using XSC:AttDef elements) are optional. Documentation about the element, content-model information, and attribute information are stored as sub-elements of the XSC:ElementDecl element. Documentation is covered in 2.6.1, Documentation Extensions. Content Model is covered in 2.3, Content Model Declarations, and attributes are covered in 2.4, Attribute Declarations. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Wed Jun 10 02:18:35 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:09 2004 Subject: XSchema Spec Section 2.2, Draft 1 In-Reply-To: (SimonStL@classic.msn.com) Message-ID: <199806100017.UAA25981@ruby.ora.com> I believe XSC:id to be redundant; by default, an attribute is assumed to belong to the element on which it is found. Attributes should only need qualification when they're somehow foreign to the element type, as global attributes (like xml:lang) are. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From d.harris at netcom.co.uk Wed Jun 10 10:17:41 1998 From: d.harris at netcom.co.uk (Daniel Harris) Date: Mon Jun 7 17:02:09 2004 Subject: (no subject) Message-ID: <357E403B.813C5A9C@netcom.co.uk> unsubscribe xml-dev xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 10 12:48:31 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:09 2004 Subject: XSchema Spec Section 2.2, Draft 1 References: <199806100017.UAA25981@ruby.ora.com> Message-ID: <357E63E7.8B428953@technologist.com> Chris Maden wrote: > > I believe XSC:id to be redundant; by default, an attribute is assumed > to belong to the element on which it is found. Attributes should only > need qualification when they're somehow foreign to the element type, > as global attributes (like xml:lang) are. XSC:id is for element constraint declarations, no? Are you reading a different spec than the one I am reading? Anyhow: when I first started using SGML, it really bothered me that attribute constraint declarations were not buried in element type declarations. But now I think that it is better to strictly separate them. It should be possible to attach attributes to any list of elements (including ALL). I think that SGML and XML had it right, and we should go back to that way of doing it. If we want to allow nesting of attribute constraint declarations in element constraint declarations, it should be a short-hand for the expanded version. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 10 13:01:26 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:09 2004 Subject: XSchema Spec Section 2.2, Draft 1 In-Reply-To: Message-ID: On Wed, 10 Jun 1998, Simon St.Laurent wrote: > Element declarations in XSchemas are made using the XSC:ElementDecl element > and its contents: We need to align this terminology with XML. We certainly are NOT declaring individual elements!. One way to fix this up would be to call these "Element Type Declarations". But philosophically, you have to ask yourself: "Are we really declaring element types?" This would be more right than what we have, but still not quite right, in my book. The word "type" implies a "type system", which we are probably not interested in. And the word "declaration" implies that this is the one and only place that the element type is "declared". That made sense in DTD-land, but in schema land, I think the terminology is a little out of whack. In my mind, the element type exists long before the XSchema processor sees it. And if a document has no XSchema the element types still conceptually exist. I suggest "element constraint declaration" and "attribute constraint declaration" with the GIs XSC:Element and XSC:Attribute. That implies that this is the one and only one declaration of this particular constraint -- which is a tautology. > XSC:Empty | XSC:Any | XSC:PCData | XSC:Mixed), XSC:AttDef*)> > > I don't have time to go into this in detail, but I would urge you to consider aligning the handling of content models with regular expression theory. For instance, consider allowing XSC:Any *anywhere* in a content model. This will go a long way towards the flexibility that people need when they ask for "inheritance." Because of the festering hole that is XML whitespace (if there is a clean solution, I don't know it), the situation with XSC:Mixed and XSC:Pcdata is more complicated. Will XSchema's be used to guide the ignoring of whitespace? If so, we should be constrained to the simple models XML allows. If not, we could mix in XSC:Pcdata and XSC:Mixed anywhere, as SGML does. I think that we should go for it: make the whole thing simple, orthogonal and consistent. This is an experimental language, right? If we can't try out potential over-simplifications here, then when can we try them out? > The XSC:id attribute identifies the name of the element, and is required. I don't think that ID/IDREF is going to be powerful enough for us, unfortunately. We will want to be allowed to reuse the same name for and element and an attribute, for instance. So the name need only be unique across a particular type. XML doesn't support this well, but a "linking schema" language could (in the future) or some future version of XSchema could support it directly. Michael Sperberg-McQueen described a nice syntax for describing these kinds of constraints once. I propose: XSC:name NAME -> required and must be unique among element constraint declarations. XSC:longname CDATA -> for use in XML editors, viewers and other places where a longer name might be appropriate. (e.g. never referenced, always just used for output) Paul Prescod xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Wed Jun 10 14:38:07 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:02:09 2004 Subject: Entities in XSchema Message-ID: <3.0.32.19980610083505.0069aa50@polaris.net> At 04:19 PM 6/9/98 -0400, John Cowan wrote: >Okay, that leads to a model with the following (meta-)attributes >of attributes: > > name CDATA #REQUIRED > syntax (name | nmtoken | names | nmtokens | general) #IMPLIED > choices CDATA #IMPLIED -- a list of choices or "free" if none -- > optionality: (optional | required) "optional" IMO "syntax" is too general a name for the second (meta-)attribute. How about something like "nameclass"? (Sorry if this is off-subject or a misreading of what you were saying... wasn't able to keep up with all the XSchema stuff over the last week or so.) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricko at allette.com.au Wed Jun 10 15:08:59 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:09 2004 Subject: XSchema Spec, Section 1.0 (Draft 2) In-Reply-To: Message-ID: <000501bd9471$20cc30f0$dabc38cb@NT.JELLIFFE.COM.AU> > From: Simon St.Laurent in his draft > DTDs have many well-documented flaws and it is necessary to > experiment with > new ideas in schema design. I strongly object to this sentence. The "design flaws" of DTDs are not well-documented. In the absense of any HCI studies in DTDs which might give a scientific veneer, there is the anecdotes of 1) a lot of people who use them 2) some people who dont use them but use something else (e.g. EDD) 3) a lot of people who have never used anything 4) some people who have never used anything but think they would prefer to use something else, for cosmetic or intellectual reasons The use of a specialized syntax in DTDs is certainly not a design flaw. The use of regular expression syntax in content models is not a design flaw. The modest functionality of DTDs is not a design flaw. Parameter entities are not a design flaw. That sentence is polemical and wrong. Why not say > DTDs have a limited expressiveness and it is necessary to > experiment with > new ideas in schema design. since that can be agreed on by everyone. The danger is that the mythologies arise fast, especially in difficult areas like text, which people expect to be easy but is not. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Jun 10 15:56:39 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:09 2004 Subject: XSchema Spec, Section 1.0 (Draft 2) Message-ID: Rick Jelliffe wrote: >That sentence is polemical and wrong. Why not say > > DTDs have a limited expressiveness and it is necessary to > experiment with > new ideas in schema design. > >since that can be agreed on by everyone. The danger is that the mythologies >arise fast, especially in difficult areas like text, which people expect to >be easy but is not. You're right. I'll make the changes. The AOL site I've been using is mysteriously refusing to accept uploads, so it may be behind for a little while, though hopefully not for very long. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Jun 10 16:36:10 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:09 2004 Subject: XSchema Spec Section 2.2, Draft 1 Message-ID: Chris Maden wrote: >I believe XSC:id to be redundant; by default, an attribute is assumed >to belong to the element on which it is found. Attributes should only >need qualification when they're somehow foreign to the element type, >as global attributes (like xml:lang) are. Do you mean that the namespace prefix XSC is redundant? (I agree it probably is, though the namespaces spec uses QName in ATTLIST declarations.) Or you mean that the whole id thing is pointless? It's currently used for content models, not just attributes. Thanks, Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 10 17:14:32 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:09 2004 Subject: PROPSAL: XSchema declarations and constraints References: <357D98C4.409C2F55@locke.ccil.org> Message-ID: <357E9D31.2F78F2ED@technologist.com> John Cowan wrote: > > I was attempting to adopt the distinction between "what IS so" and > "what MUST BE so" (which DTDs conflate) and see where it led. This is an excellent way of phrasing the distinction. But the clarity of it leads to a troubling question, but also a big opportunity. Metadata is an important part of what we want XSchema to support. But metadata is inherently about "what IS so" versus "what MUST BE so". The big opportunity is the idea going "click" in my head. -- In the XML SIG, I have promoted the idea that "what IS so" should be cleanly separated conceptually from "what MUST BE so" in the namespaces specification. The "what IS so" document could be called a "vocabulary" or "dictionary" or "namespace" or "directory." Vocabulary documents would have textual descriptions of element types and attribute types, knowledge-representation information, and so forth: metadata. It could also contain or link to a "default" stylesheet or "default" schema. SGML always had dictionaries, but they never existed in standardized formats. TEI's dictionary was in the TEI DTD ("the TEI Guidelines"), DocBook's was in DocBook, HTML's is in HTML ("the HTML 4.0 spec"). A schema is about "what MUST BE so". It defines a class of languages. Of course schemas will (almost?) always be tied to vocabularies, just as stylesheets will be tied to vocabularies. That doesn't mean that they are the same thing, but merely that they are often related. It is undeniably convenient to be able to specify metadata and schema information in the same document. The distinction is philisophical, technical and also practical. I've just described the philisophical distinction. Now on to the technical and practical ones: #1. We don't want to duplicate document-type metadata in multiple schemas for closely related schemas. HTML 1.0, 2.0, 3.2 and 4.0 all have more or less the same semantics for the A element. It exists, it stands for "anchor", it is a type of hypertext link, it marks both sides of the links, etc. etc. etc. But they all have different content models and attributes for A. If schemas are separate from metadata, then we don't have to repeat the metadata in each document. Repetition gets us back to the issue of redundancy/conflict. What happens if two versions of HTML accidently describe a different semantic for the A element? That strikes me as a problem. #2. Elements can have multiple constraints applied to them. The constraints are just each tested one after the other. But an element can only have a single definition. That's why I originally suggested an XSL-like syntax for describing constraints: ... ... but now we have ended up with an "element-definition"-like syntax: ... The first is from a "this must be true and maybe there are other things around that must be true" mentality. The second is from a "this and only this is true" mentality. I'm not proposing the first TODAY, but I am asking that we leave ourselves open to full patterns and multiple constraint rules per element type, just as there can be full patterns and multiple stylesheet rules per element type in XSL. The only difference would be in XSL a single matching rule is chosen. In our schema language ALL would be tested. When you combine this with schema inclusion (in some future version), you also get the ability to "tighten up" constraints from an imported DTD. Note that the way I describe it above is inherently extensible in two ways. Patterns can become more advanced. Constraints can also become more advanced. #3. It would be nice to have a clear way of distinguising metadata about element types from metadata about constraints. For instance we might want to describe an element's semantics separate from where we describe why it has a particular content model in the schema, or allows or doesn't allow a particular attribute. --- Now I realize that we often want to put schema and vocabulary information in the same document. Simple uses of XML should not be penalized for the complexity of complex applications of it. In fact, simple uses of XML will only have a single stylesheet: maybe those stylesheet rules should be able to go "cheek to cheek" with schema and type declaration information. What we need is to maintain the distinction between these different kinds of information: type information, constraint information, style information etc., but not require a separate file per information type. We probably also want to allow the declarations to go right beside each other, for maintenance simplicity. In other words, we do not want to *conflate* the types of declarations, but we do want to allow them in the same document. I propose that the namespaces facility is the perfect solution to this problem. We can break the XSchema specification into three parts (or perhaps three sections of the same specification). XDocTypeInfo -- a "bag" DTD that contains a list of declarations. XSchema -- the definition for the XSC:Rule, XSC:ContentModel, etc. XVocab -- XVC:ElementType, XVC:Attribute declarations Here's what I think that this would look like: This is the anchor element. ... A short form for a set of declarations all of the same element might be: In this case, you could leave out the patterns in the various rules, because the target would be implied by the context. We can't force the XSL and XLink people to go along with this plan, but we can certainly use it to differentiate our own schema information from our element type information. I won't have much time in the near future to defend this proposal, so I hope that it stands on its own merits. No, I still don't think that it necessarily means we want to go back into entity provision territory. At least not text entities. There is still no legal communication mechanism between the parser and the XSchema processor. XML would have to be updated to allow the application to supply entity replacement texts "automatically." And verifying that entities have a particular value still doesn't seem very interesting. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Wed Jun 10 17:16:10 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:10 2004 Subject: XSchema Spec Section 2.2, Draft 1 In-Reply-To: <357E63E7.8B428953@technologist.com> (message from Paul Prescod on Wed, 10 Jun 1998 06:45:59 -0400) Message-ID: <199806101513.LAA10823@ruby.ora.com> > Chris Maden wrote: > > I believe XSC:id to be redundant; by default, an attribute is > > assumed to belong to the element on which it is found. Attributes > > should only need qualification when they're somehow foreign to the > > element type, as global attributes (like xml:lang) are. > > XSC:id is for element constraint declarations, no? Are you reading a > different spec than the one I am reading? Yes. My comment was unclear; I was referring only to the namespace qualifier on XSC:id. It should just be "id". -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Wed Jun 10 17:24:41 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:10 2004 Subject: XSchema Spec Section 2.2, Draft 1 In-Reply-To: (SimonStL@classic.msn.com) Message-ID: <199806101522.LAA11291@ruby.ora.com> [Simon St.Laurent] > Do you mean that the namespace prefix XSC is redundant? Yes. > (I agree it probably is, though the namespaces spec uses QName in > ATTLIST declarations.) There was a lot of debate about that. The rationale for allowing QName for attribute names is that some attributes are globally applicable - like xml:lang. But an attribute that is inherently bound to its element type (which I would maintain that the id is, at least in this case), the namespace prefix is both redundant and confusing. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 10 17:30:51 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:10 2004 Subject: XSchemas and DTDs Message-ID: <357EA50E.8F2107B1@technologist.com> I am going to be offline for several days. Today, I am trying to get out the issues I have been thinking of. I don't think that there need be any hard decisions about the interaction of XSchemas and DTDs. They are two different types of schemas they need not have any effect on each other at all. If there is a DTD present, and the user has a validating parser, the user can validate against the DTD. If there is a schema present, and the user has an XSchema processor, the user can validate against the XSchema. If the DTD is algorithmically derived from the XSchema, then the document is guaranteed to pass both tests if it passes the XSchema. Otherwise each test is performed and reported separately by the appropriate software. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Wed Jun 10 17:44:34 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:10 2004 Subject: Entities in XSchema References: <357D98C4.409C2F55@locke.ccil.org> Message-ID: <357E8A33.A9B1F89F@technologist.com> John Cowan wrote: > > Paul Prescod wrote: > > > SAX provides information on ID/IDREF attributes, but I don't think that > > ESIS did, so this is more debatable. > > But not all SAX-compliant parsers do: attribute type checking is a > validity constraint only, so non-validating parsers are free to > return CDATA as the type of all attributes. Doh! I didn't think of it before, but it doesn't really matter whether ID/IDREF are passed through SAX. The question is whether we want our schema language to be able to say that a) a particular attribute's values must be unique document-wide. b) a particular attribute's value must refer to the previously described globally unique value. I would give a qualified yes: Yes, we want to be able to say that eventually. No, we don't have time to think it through completely now. For instance, do we want a single ID namespace as XML/DTD has? Or do we want one namespace per attribute? The latter seems more powerful to me! So a "FIG" element could have both a FIGID and an ID. The FIGID might be only available on "FIG" elements, and thus a unique identifier for classes, without invading the namespace of "EXAMPLEs". Note that I use the word namespace in a sense more or less unrelated to that of the "namespaces" specification. IDREF should also be more powerful. It should allow full XPointers (though an XSchema processor might only check local ones). In other words, I say leave linking (ID/IDREF) out for now, but plan great things for them in the future. ENTITY and NOTATION seem more or less harmless. There is no obvious way to make them more powerful, and they are inherently tied to information that SHOULD BE available to an application of XML anyhow. After all, binary entity and notation declarations are completely useless if the application doesn't have access to them. Since they are fairly simple and in the realm of application-level information, I think that we should support them. > As one who is fairly SGML-ignorant, I would like to know: Just what > is in the ESIS? (If you will, limit the answer to things XML also > has.) I think that the best summary is here: http://www.jclark.com/sp/sgmlsout.htm Things that must be turned on with a -o option are NON-ESIS. For example: Aname val The next element to start has an attribute name with value val which takes one of the following forms: IMPLIED The value of the attribute is implied. CDATA data The attribute is character data. This is used for attributes whose declared value is CDATA. NOTATION nname The attribute is a notation name; nname will have been defined using a N command. This is used for attributes whose declared value is NOTATION. ENTITY name... The attribute is a list of general entity names. Each entity name will have been defined using an I, E or S command. This is used for attributes whose declared value is ENTITY or ENTITIES. TOKEN token... The attribute is a list of tokens. This is used for attributes whose declared value is anything else. ID token The attribute is an ID value. This will be output only if the -oid option is specified. Otherwise TOKEN will be used for ID values. The last line indicates that ID differentiation is non-ESIS. Note that ENTITY and NOTATION are supported, as in SAX. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Jun 10 17:55:15 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:10 2004 Subject: XSchemas and DTDs Message-ID: Paul Prescod wrote: >If the DTD is algorithmically derived from the XSchema, then the document >is guaranteed to pass both tests if it passes the XSchema. Otherwise each >test is performed and reported separately by the appropriate software. This is going to be one of the 'hard' issues in the weeks to come, I fear. I wish that the XML spec had discussed processors (non-validating processors, that is) and validation as a module on top of those processors, instead of describing validating processors as a single unit. Of course, this would have required building the spec quite differently. Non-validating processors and interfaces like SAX seem like useful starting points for the processing discussion, upon which we can build our schema-verifying layers. I'd love to see a verification implementation that behaves like David Megginson's XAF - using SAX to parse the document and its XSchema (XAF is about architectural forms), then using SAX to return the 'verified' document to the application above. This kind of 'layering' seems like an appropriate model to me. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Wed Jun 10 18:00:56 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:10 2004 Subject: XSchema Spec Section 2.2, Draft 1 Message-ID: <199806101523.RAA13838@berlin.dvs1.tu-darmstadt.de> Paul Prescod wrote: > > The XSC:id attribute identifies the name of the element, and is required. > > I don't think that ID/IDREF is going to be powerful enough for us, > unfortunately. We will want to be allowed to reuse the same name for and > element and an attribute, for instance. So the name need only be unique > across a particular type. XML doesn't support this well, but a "linking > schema" language could (in the future) or some future version of XSchema > could support it directly. Michael Sperberg-McQueen described a nice > syntax for describing these kinds of constraints once. This is a mistake in the current DTD, where we use id attributes for both ElementDecl and Notation (but not AttDef). It's not quite clear to me if notations are in or out at the moment. If they stay in, we could retain an ID attribute on ElementDecls and get uniqueness checking from validating parsers for free. On the other hand, because a validator is looking like a reasonable application to build, there seems no reason to do this, since the validator would need to check uniqueness for non-validating parsers anyway. Note also that attribute names are required to be unique only within the attributes of a single element, not all attributes. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 10 18:06:16 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:10 2004 Subject: Entities in XSchema References: <3.0.32.19980610083505.0069aa50@polaris.net> Message-ID: <357EA922.500957C@locke.ccil.org> John E. Simpson wrote: > IMO "syntax" is too general a name for the second (meta-)attribute. How > about something like "nameclass"? My point was that ID, IDREF, and ENTITY have the same syntax (Names), and so do IDREFS and ENTITIES (lists of Names). > (Sorry if this is off-subject or a misreading of what you were saying... > wasn't able to keep up with all the XSchema stuff over the last week or so.) No more have I, no more have I. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From m.mower at unl.ac.uk Wed Jun 10 18:45:18 1998 From: m.mower at unl.ac.uk (Matt Mower) Date: Mon Jun 7 17:02:10 2004 Subject: Roots of the DTD In-Reply-To: References: Message-ID: <35989ff2.198373921@tara.unl.ac.uk> On Fri, 05 Jun 1998 13:12:59 +0000 (UT), "Simon St.Laurent" wrote: Please forgive me for jumping into this conversation at this late stage, and let me prefix my comments with the information that I am a relative novice in XML with no SGML background.... >>I don't like telling people they can use DOCTYPE or XSchema PIs but not both. > I >>also don't like having to write a long list of conflict resolutions -- it >just >>makes XSchemas harder to use. In both cases, it feels like we are imposing >>requirements not in the XML spec. Ideas? > >Perhaps the simplest way to deal with this is to leave roots _out_ of the >XSchema PI. I always thought it was kind of silly to declare it in DOCTYPE - >after all, the root element should be the first and last thing you see in a >document, and an application should be able to figure it out. It seems to me >like redundancy, though there may be reasons for it which I haven't fathomed. > If you want a reason for specifying a root element type external to a particular document type then I think I can give you one: I agree that once you have a document the root element is obvious, however when creating new documents it is less so. My particular focus is on editing tools for users who will not easily grasp XML. We are looking at tools to edit certain types of document, and ideally want the tool to do most of the work. Hence we need as much intelligence in the document definition as possible (DTD's seem pretty poor in this respect). Given that the DTD doesn't define the root element a tool cannot immediately know how to start creating the document - leaving this choice up to the user, who may also not know. When writing a particular DTD I would like the *option* of being able to specify what the root element *must* be for a document that wants to conform (is that right word?) It's my type of document after all! >The other reason for ignoring roots is that we _can't_ change DOCTYPE, so I >think we'd better just stay out of its way. > In my case once it has been set then you are safe to leave it alone. I hope I am not missing the point too much. Best regards. Matt. p.s. I have been a bit vague with my use of 'document definition', when I say DTD I usually mean it in an external sense. -- Matt Mower, Information Systems Team, University of North London T: +44-(0)171-753-3288 F: +44-(0)171-753-5120 E: m.mower@unl.ac.uk xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 10 18:56:52 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:10 2004 Subject: Entities in XSchema References: <357D98C4.409C2F55@locke.ccil.org> <357E8A33.A9B1F89F@technologist.com> Message-ID: <357EBA2F.2EF5C043@locke.ccil.org> Paul Prescod wrote: > For > instance, do we want a single ID namespace as XML/DTD has? Or do we want > one namespace per attribute? The latter seems more powerful to me! I don't think it is, or at least you haven't shown so below. > So a > "FIG" element could have both a FIGID and an ID. The FIGID might be only > available on "FIG" elements, and thus a unique identifier for classes, > without invading the namespace of "EXAMPLEs". Note that I use the word > namespace in a sense more or less unrelated to that of the "namespaces" > specification. I used the term "IDspace" in a previous posting. However, your FIGID value can be just an ID value if it is prefixed with "FIG-"; where you would assign a FIG-unique FIGID value, just assign a prefixed and document-unique ID value. (One could get broader than that and qualify all ID values with the URI of the document to which they belong, thus making them globally unique, but URIs don't offer strong enough guarantees of non-reusability.) > IDREF should also be more powerful. It should allow full XPointers (though > an XSchema processor might only check local ones). This is rebuilding XLink. ID/IDREF have the advantage of being very small and very cheap. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 10 19:01:04 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:10 2004 Subject: ESIS (was: Entities in XSchema) References: <357D98C4.409C2F55@locke.ccil.org> <357E8A33.A9B1F89F@technologist.com> Message-ID: <357EBB55.A49D8B19@locke.ccil.org> Paul Prescod wrote: > Things that must be turned on with a -o option are NON-ESIS. For example: For future reference, then, it seems that only the following XML things are non-ESIS: 1) The fact that an attribute is of type ID. 2) The system identifier (if any) in a notation declaration. 3) Declarations of external parsed entities. 4) Declarations of *unreferenced* unparsed entities. 5) The fact that an element has declared EMPTY content. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jun 10 19:15:10 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:02:10 2004 Subject: PROPSAL: XSchema declarations and constraints Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA3B1@red-msg-08.dns.microsoft.com> Could someone provide a crisp definition of what you mean by the term "metadata" in the context of this discussion. I ask this for two reasons: 1. A commonly-offered definition ("data about data") is vacuous in actual practice, if not conditioned by further information, since it indicates no operational or essential distinction between metadata and any other kind of data. That is, all data is data about something, and consequently there are no structural, operational or other requirements that obtain for data-about-data absolutely that do not also obtain for other kinds of data. 2. I actually think that there is a valid use of the term "metadata," but I notice that the same word is used in different contexts to mean very different things, so I need to know what it means _here_. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 10 19:23:29 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:10 2004 Subject: WD-xml-names-19980327 Message-ID: <357EC05D.1056F9E2@locke.ccil.org> The namespace draft allows PI targets, but not notations, to be qualified with namespace prefixes. A notation declaration, however, is the only standard way in which a PI target can be predeclared. Thus, the following is not allowed: ]> yet this seems entirely reasonable. What was the reasoning behind forbidding qualified names in notation declarations? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Jun 10 20:06:36 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:10 2004 Subject: PROPSAL: XSchema declarations and constraints Message-ID: Andrew Layman asked: >Could someone provide a crisp definition of what you mean by the term >"metadata" in the context of this discussion. To be honest, I think this is a discussion we should avoid, and answer only in practice. The 'metadata' swamp is unmapped, yet well known to be enormous and filled with quicksand. Rather than wandering into this swamp on foot, I'd prefer that we build roads into it, stiffening the ground below us as we move from place to place. >A commonly-offered definition ("data about data") is vacuous in >actual practice, if not conditioned by further information, since it >indicates no operational or essential distinction between metadata and any >other kind of data. 'Data about data' may be vacuous, but also has the benefit of accuracy in its very being vacuous. In my (admittedly limited) world, practice is the only way to define such mushy concepts. "What is metadata?" is meaningless; "Is that metadata?" can lead to interesting discussion. Funny, I used to really love philosophy... but always hated epistemology. For right now, the two forms of metadata encoded in an XSchema are: 1) Acceptable structures for elements and attributes (one kind of constraint) 2) Documentation for elements, attributes, and the XSchema itself. Paul's proposal appears (to me) to be about making certain that our constraints are extensible, which seems like a laudable goal we have some chance of building into our structures. Its relationship to metadata seems less important to me than its relationship to the extensibility of XSchemas. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Jun 10 20:10:00 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:10 2004 Subject: Roots of the DTD Message-ID: Matt Mower wrote: >Given that the DTD doesn't define the root element a tool cannot >immediately know how to start creating the document - leaving this >choice up to the user, who may also not know. > >When writing a particular DTD I would like the *option* of being able to >specify what the root element *must* be for a document that wants to >conform (is that right word?) It's my type of document after all! This seems like an excellent idea - one I would have missed, given my crazy tendencies toward hand-building XML documents. It's certainly something we should consider as part of the Doc element for the XSchema, or perhaps it deserves its own place. At the very least, I would hope this information would appear in the human-readable documentation we're enabling in XSchemas. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jun 10 20:52:36 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:10 2004 Subject: ANN: Draft Sildeset for Links and Relations in XML Message-ID: <357ED59D.D453423A@locke.ccil.org> Ingo Macherius asks: > 4 : Is the notation urn:http://foo.com/ correct ? It is formally correct, but I have not seen any drafts documenting such a thing as URL-based URNs. > 6 : What really is the difference between document and group ? An extended link group is just a kind of extended link, and an extended link document is just a kind of locator. The point about extended link groups is that (unlike other extended links) they necessarily refer to whole documents, and their semantics is that the documents are associated in some way. > Do you consider the visualization an oversimplification ? Yes. "Locator" should not have a separate picture, and "document,group" should just be "group" and should show a part of a document that refers toa bunch of *whole documents* (shown in reduced size). > 7 : Any idea how to generally visiualize the concept of a > link without discriminating inline/off-line and simple/extended? No, nor do I know how to show a picture of apples which does not discriminate between "two apples" and "many apples". Sometimes a word is worth a thousand pictures. > May a locator really be a link of type locator? A locator is just part of the machinery of an extended link; it has no independent use. So locators are not links. > 9 : Have I missed a feature ? Relative locations should be at least mentioned, even though they are explained on the next slide. > 10: Formalisms tend to be erroneous, please check. The "preceding" list should be 1, 2, 5; the "following" list should be 7, 2, 3, 4, 8, 12, 9, 1. You can see this by writing out the XML format: and applying the rules given at 3.3.7 and 3.3.8. Ancestors always both precede and follow; descendants never precede or follow. > 11: " " " " " " " . 2nd example is in error. "Root()" gets the "speech" element; the second child counting from the right is the content "Fare you well, my lord", and then you want the 3rd sibling previous to that --- but there are only 2 siblings previous. Change to "root().child(-2,#all).psibling(2,#all)". 3rd example is also in error. The term "descendant(-1)" means "descendant(-1,#element)" and cannot select a string. You will get the whole treewise rightmost element, namely "To Ros.". 4th example is also in error. Since neither "root()" nor "origin()" is present, "root()" is assumed, but nothing follows the root, since descendants (see last slide) are neither following nor preceding. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Thu Jun 11 01:04:26 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:10 2004 Subject: PROPSAL: XSchema declarations and constraints References: <5BF896CAFE8DD111812400805F1991F7038CA3B1@red-msg-08.dns.microsoft.com> Message-ID: <357F0EFC.D9AB3786@technologist.com> Andrew Layman wrote: > > Could someone provide a crisp definition of what you mean by the term > "metadata" in the context of this discussion. Well, we do not speak with one voice, but I can tell you what I mean. > I ask this for two reasons: > > 1. A commonly-offered definition ("data about data") is vacuous in > actual practice, if not conditioned by further information, since it > indicates no operational or essential distinction between metadata and any > other kind of data. That's true. In our discussion the data is "a schema" and so in my opinion, the metadata would be "information about the schema." Since I have urged that we should separate information about types (known elements, attributes and their semantics) from information about constraints (how they may be used), I have also urged that we should keep their metadata separate: "information about types" vs. "information about constraints." BTW, XML conflates types (specified in dictionaries) and constraints (specified in schemas), and the namespaces spec. does also. This causes much of the confusion and (unnecessary) argumentation about that spec. > 2. I actually think that there is a valid use of the term "metadata," > but I notice that the same word is used in different contexts to mean very > different things, so I need to know what it means _here_. I would be glad to hear what you think metadata is. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 11 01:48:33 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:10 2004 Subject: XSchema Spec Section 2.2, Draft 1 References: <199806100017.UAA25981@ruby.ora.com> <357E63E7.8B428953@technologist.com> Message-ID: <357EB1A3.3A4F7A46@locke.ccil.org> Paul Prescod wrote: > Anyhow: when I first started using SGML, it really bothered me that > attribute constraint declarations were not buried in element type > declarations. But now I think that it is better to strictly separate them. > It should be possible to attach attributes to any list of elements > (including ALL). I think that SGML and XML had it right, and we should go > back to that way of doing it. I assume this is an error for "SGML had it right". In XML, there is no reason to assume that the "id ID #IMPLIED" attribute in one element has anything to do with the "id ID #IMPLIED" attribute in another. There is no way of declaring in XML DTDs that two elements have the *very same* attribute, only that they have attributes that agree in name and type. XML DTDs do not reify attributes. > If we want to allow nesting of attribute constraint declarations in > element constraint declarations, it should be a short-hand for the > expanded version. I disagree. I am willing to accept a shorthand, either by way of general entities in XSchemas or otherwise, for copying attribute declarations from one element to another by way of shorthand, but not for reifying attributes independently of the elements they are attached to. Perhaps the practical result would be the same, but the theoretical implications are very different. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Jun 11 01:51:01 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:11 2004 Subject: XSchema Spec Section 2.2, Draft 1 Message-ID: Paul Prescod wrote: >If we want to allow nesting of attribute constraint declarations in >element constraint declarations, it should be a short-hand for the >expanded version. The other enormous question which arose today, tied into these identifier issues as well, is declarations of attributes _outside_ of the element declaration. Thoughts? And content models? Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Jun 11 01:53:10 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:11 2004 Subject: XSchema Spec Section 2.2, Draft 1 Message-ID: Ron Bourret writes: >This is a mistake in the current DTD, where we use id attributes for both >ElementDecl and Notation (but not AttDef). It's not quite clear to me if >notations are in or out at the moment. If they stay in, we could retain an >ID attribute on ElementDecls and get uniqueness checking from validating >parsers for free. On the other hand, because a validator is looking like a >reasonable application to build, there seems no reason to do this, since the >validator would need to check uniqueness for non-validating parsers anyway. > >Note also that attribute names are required to be unique only within the >attributes of a single element, not all attributes. It's not quite clear to me either whether NOTATION is in or out, though it does have a place in the current outline. If NOTATION is in, ID attributes should not be used for both types of declarations. We need to define behavior for the verifier (my term for validator, since I don't want to get twisted in DTDs). The verifier could check that all element names are unique, or it could accept the first or last element declaration made. Allowing repeated declarations - which override would make it easier to combine XSchemas, but could also create a mess. (Attributes? Content models?) Whatever we decide, the verifier is going to have some work to do. I would like to be able to build XSchema applications on top of non-validating parsers - dealing with validation as well as XSchemas seems like a lot of redundant effort to me. I don't think we gain that much from using ID. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 11 02:05:31 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:11 2004 Subject: XSchema Spec Section 2.2, Draft 1 References: Message-ID: <357EB449.C114FE91@locke.ccil.org> Paul Prescod wrote: > We need to align this terminology with XML. We certainly are NOT > declaring individual elements!. I agree, although the XML spec does use the term "ElementDecl" for the syntactic nonterminal in question. (The XSchema names are taken, for the most part, directly from the XML spec.) > One way to fix this up would be to call these "Element Type Declarations". > But philosophically, you have to ask yourself: "Are we really declaring > element types?" This would be more right than what we have, but still not > quite right, in my book. The word "type" implies a "type system", which > we are probably not interested in. I disagree. Element types are "types" in the sense of a type vs. token distinction; the elements themselves (in document instances) are tokens. This use of "type" does not imply any type system: the types of English, e.g., do not constitute a system in any meaningful sense (more like a historical rag-bag). > And the word "declaration" implies > that this is the one and only place that the element type is "declared". Again, I disagree. There is a document commonly called the "Declaration of Independence", but that is not the unique repository of claims to independence, or even the United States' claims. You will tell me that the words "type" and "declaration" have specific meanings as terms of art in computer science. I reply that this is not computer science, in the sense commonly understood by that term. > I don't have time to go into this in detail, but I would urge you to > consider aligning the handling of content models with regular expression > theory. For instance, consider allowing XSC:Any *anywhere* in a content > model. This will go a long way towards the flexibility that people need > when they ask for "inheritance." I think that this suggestion (loosening what is allowed in a content model) has some merit to it, although IMHO it would need to be a hypothetical AnyElement rather than true ANY, to preserve unambiguous parsing. > Because of the festering hole that is XML whitespace (if there is a clean > solution, I don't know it), What "festering hole"? XML's solution is simple: all whitespace is meaningful, just as all non-whitespace is meaningful. If a particular application chooses to ignore whitespace in certain circumstances, it is free to do so, just as it can ignore letter case, or even (*gasp*) ignore element structure or attribute values. > the situation with XSC:Mixed and XSC:Pcdata > is more complicated. Will XSchema's be used to guide the ignoring of > whitespace? If so, we should be constrained to the simple models XML > allows. If not, we could mix in XSC:Pcdata and XSC:Mixed anywhere, as > SGML does. I don't claim familiarity with SGML theory or practice, but I note the existence of something called the "SGML mixed content problem". As far as I can see, the standard solutions to this problem are exactly what XML mandates: the simple (#PCDATA | foo | bar)* content models. > I don't think that ID/IDREF is going to be powerful enough for us, > unfortunately. We will want to be allowed to reuse the same name for and > element and an attribute, for instance. So the name need only be unique > across a particular type. See my earlier posting on attributes. In particular, the attribute "foo" of element BAR and the attribute "foo" of element BAZ need have nothing else in common, so even having separate IDspaces for names and attributes isn't enough. The current XSchema draft dodges the problem by embedding the attributes (but may be extended to allow cross-referencing via an ID that is *not* the attribute name). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Thu Jun 11 06:01:52 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:11 2004 Subject: Entities in XSchema References: <357D98C4.409C2F55@locke.ccil.org> <357E8A33.A9B1F89F@technologist.com> <357EBA2F.2EF5C043@locke.ccil.org> Message-ID: <357F55D5.76C2F7DE@technologist.com> John Cowan wrote: > > I used the term "IDspace" in a previous posting. However, your > FIGID value can be just an ID value if it is prefixed with "FIG-"; where > you would assign a FIG-unique FIGID value, just assign a prefixed > and document-unique ID value. Unfortunately, this means that the *name* of objects must also have the prefix. To get back the unprefixed name you must other do string hacks or have another attribute with the name. More subtly, but also more importantly, we are making the system redundant. You are well aware, I am sure, that redundancy can be useful, but you also no that it can be fatal. Using my simple example of FIG, I might someday rename the FIG element to GRAPHIC. Now I must change all of those ID values as well. Anyhow, the most important reason to want more sophisticated ID-uniqueness checking is because it is painful to have IDs that are the moral equivalent of FIG-NAMED-SPAM-IN-CHAPTER-NAMED-MONTY. Coordinating and communicating the convention is nigh impossible. > > IDREF should also be more powerful. It should allow full XPointers (though > > an XSchema processor might only check local ones). > > This is rebuilding XLink. ID/IDREF have the advantage of being > very small and very cheap. I'm not suggesting we rebuild XLink. I'm suggesting that we build on it. If we are going to check hypertext links in XML, we should check XPointers, not ID/IDREF. ID/IDREF is mostly there for backwards compatibility. The XLink group has decided not to explicitly support ID/IDREF, so we should probably follow their lead. Of course XLink is still under development, so that part of the XSchema spec. should probably just be left out for now. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Thu Jun 11 06:01:55 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:11 2004 Subject: XSchemas and DTDs References: Message-ID: <357ECDD8.54A45441@technologist.com> Simon St.Laurent wrote: > > This is going to be one of the 'hard' issues in the weeks to come, I fear. I > wish that the XML spec had discussed processors (non-validating processors, > that is) and validation as a module on top of those processors, instead of > describing validating processors as a single unit. Of course, this would have > required building the spec quite differently. I don't see this as a complicated issue. View an XSchema processor as merely another application. What happens if an XHTML browser loads an XHTML document and finds out that a URL does not conform to the URL specification? It triggers an error. This does not affect the validity of the document -- it is just an application error. What happens if a DSSSL or XSL stylesheet triggers an error in the processing of a document. This doesn't affect the validity of the document either -- it is just an application error. If a stylesheet is a converter that converts XML documents + stylesheets to renditions of those documents, then a schema processor is a converter that converts XML documents + schemas to truth values. I don't think that we need to state a relationship to DTD validation anymore than a stylesheet language does. The DTD (if any) does "the DTD thing" (validation) and the XSchema does verification. > Non-validating processors and interfaces like SAX seem like useful starting > points for the processing discussion, upon which we can build our > schema-verifying layers. I'd love to see a verification implementation that > behaves like David Megginson's XAF - using SAX to parse the document and its > XSchema (XAF is about architectural forms), then using SAX to return the > 'verified' document to the application above. This kind of 'layering' seems > like an appropriate model to me. That's one model. In other cases, the application will want to just hand a tree or event stream to the XSChema verifier and see if the verifies or not. Since verification does not affect the document, you may or may not want to invoke the penalty of re-triggering the SAX events. Only time will tell if that is efficient enough if there are several layers of verification. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From adam at cyber-guru.com Thu Jun 11 06:20:53 1998 From: adam at cyber-guru.com (Adam M. Donahue) Date: Mon Jun 7 17:02:11 2004 Subject: regarding RDF Message-ID: <199806110420.AAA17162@wwwultra.sce.nyu.edu> Tim, I just read your piece at XML.com on the RDF, and, using your, example, I want to make sure I have each part the RDF clear: Tim Bray All right, let's see: The resource being described here is the resource at location http://www.textuality.com/RDF/WhyRDF.html The PropertyType resources here are Author and Home-Page. The Property is Description. It consists of the resource, the property types Author and Home-Page, and each one's corresponding value. Now, given that, we could perhaps add an id attribute to the RDF element, say, "description", and then further describe this entire property with something like: Adam Donahue Now the resource is the Description property, and the property type of *this* resource is Person, indicating here, for example, the person who indexed the original description. Further, I could add an id attribute to the Person element, say, persontype, and then describe to a particular the Person PropertyType in the Indexer resource, like: ... Now, if this is true, I'm a bit confused. What if I have several elements in my document. How do I describe, *in general*, a Person PropertyType? It would appear that if I point to a particular instance (as in this example), it would only apply to this instance? Does this make sense? That is, I have a unique ID as an attribute to the Person PropertyType in the above. I am pointing to it in , but this element only points to the ID of *that* particular Person PropertyType (namely, the one containing "Adam"). What if I have one with Bob? And what if I just want to describe the PropertyType itself, in general? I'm missing something here. Please clarify... Thanks, Adam mailto:adam@cyber-guru.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Thu Jun 11 06:29:43 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:11 2004 Subject: Encoding dcl in external DTD subsets( (Re: draft-whitehead-mime-xml-04) In-Reply-To: <199806090138.SAA15240@argon.eng.sun.com> Message-ID: <199806110432.AA01423@murata.apsdc.ksp.fujixerox.co.jp> David Brownell wrote: > > That, and the way " isn't permitted in > DTDs, have made me wonder if there are any other litle nudges As you pointed out in your private mail to me, encoding declarations in external DTD's are permitted. You are right that the XML spec is not clear enough. xp does support encoding declarations. 1) text.xml 2) test.dtd 3) xp Start document Start element: a Attribute: atr CDATA "default" End element: a End document Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Thu Jun 11 06:32:51 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:11 2004 Subject: XSchema Spec Section 2.2, Draft 1 References: Message-ID: <357F5BC2.C10A5BF2@technologist.com> Simon St.Laurent wrote: > > It's not quite clear to me either whether NOTATION is in or out, though it > does have a place in the current outline. If NOTATION is in, ID attributes > should not be used for both types of declarations. I say keep notation checking. They are harmless, sometimes useful, and do not completely duplicate any other W3C spec. coming down the line. > We need to define behavior for the verifier (my term for validator, since I > don't want to get twisted in DTDs). Good! > The verifier could check that all element > names are unique, or it could accept the first or last element declaration > made. Allowing repeated declarations - which override would make it easier to > combine XSchemas, but could also create a mess. (Attributes? Content models?) > Whatever we decide, the verifier is going to have some work to do. If you adopt my model described today, you do not have this problem. Each rule that applies to an element is checked. There could be a dozen, or one. If an element has multiple content models, then its content must conform to all of them.

    The constraints that relate to attributes can also be checked easily. For instance most elements will have an "open" list of attributes. So the constraints would only be that the attributes that exist in the document match the declarations in the XSchema when they exist: CDATA Elements that have a "closed" list of attributes would have a declaration that specifies that the list is closed: > I would like to be able to build XSchema applications on top of non-validating > parsers - dealing with validation as well as XSchemas seems like a lot of > redundant effort to me. I don't think we gain that much from using ID. I agree. I don't want to push my XDocInfo/constraint model too hard, because I can't help people to figure it out over the next few days. I think that it is promising enough that if XSchema takes the more conserative (and well-tested) route, I will pursue the XDocInfo stuff on my own. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 11 07:59:44 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:11 2004 Subject: Entities in XSchema In-Reply-To: <357F55D5.76C2F7DE@technologist.com> from "Paul Prescod" at Jun 10, 98 11:58:14 pm Message-ID: <199806110636.CAA22742@locke.ccil.org> Paul Prescod wrote: > The XLink group has decided not to explicitly support > ID/IDREF, so we should probably follow their lead. Of course XLink is > still under development, so that part of the XSchema spec. should probably > just be left out for now. Do you have inside information on this? The published XPointer draft encourages the use of ID, because it provides an unambiguous set of anchors; indeed, ID is supported directly, whereas other attribute values are supported only through the general attribute machinery. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From papresco at technologist.com Thu Jun 11 08:32:21 1998 From: papresco at technologist.com (Paul Prescod) Date: Mon Jun 7 17:02:11 2004 Subject: Entities in XSchema References: <199806110636.CAA22742@locke.ccil.org> Message-ID: <357F795B.78447D00@technologist.com> John Cowan wrote: > > Do you have inside information on this? The published XPointer draft > encourages the use of ID, because it provides an unambiguous > set of anchors; indeed, ID is supported directly, whereas other > attribute values are supported only through the general attribute > machinery. I have no information on this. IDREF is ignored by XLink. You can't use an element with an IDREF attribute as an XLink. The use of ID is indeed encouraged, but I will be very curious to see how it will be managed with parsers that can optionally skip attribute declarations. Depending on your parser, your XLinks could start breaking because IDs may or may not be flagged as such. XML processing would be much simpler if we had stuck strictly to the "no options" rule. Of course XPointer would also support my proposed variant of ID, but would do so through the general attribute mechanism. This is not a burden, because the whole point of my ID variant is to allow the author to specify which IDSpace she is interested in. Paul Prescod - http://itrc.uwaterloo.ca/~papresco Three things are most perilous: Connectors that corrode Unproven algorithms, and self-modifying code http://www.geezjan.org/humor/computers/threes.html xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rtennant at library.berkeley.edu Thu Jun 11 16:18:24 1998 From: rtennant at library.berkeley.edu (Roy Tennant) Date: Mon Jun 7 17:02:11 2004 Subject: regarding RDF In-Reply-To: <199806110420.AAA17162@wwwultra.sce.nyu.edu> Message-ID: Oh, boy, am I glad to see this. I thought I was the only idiot who couldn't understand RDF. Now I see there are at least two of us. When presented with two possible solutions, my tendency is to favor the best one technically. For example, Beta instead of VHS or Syquest EZ 135 over the Iomega Zip. You all know where that got me. But with RDF I find myself repelled from the best technical solution (the current model and syntax) because it is about as understandable as the U.S. Tax Code. I predict that RDF will either: 1) die a dark and lonely death because no one can understand it well enough to use it; or, 2) be metamorphosed through use into something that looks nothing like the current spec. If you don't believe me on number 2, just go take a look at the "RDF" at the Netscape and Wired sites, then explain to me how it conforms to the spec. Thanks for listening, Roy Tennant On Thu, 11 Jun 1998, Adam M. Donahue wrote: > Tim, > > I just read your piece at XML.com on the RDF, > and, using your, example, I want to make sure I > have each part the RDF clear: > > href='http://www.textuality.com/RDF/WhyRDF.html'> > Tim Bray > /> > > > All right, let's see: > > The resource being described here is the > resource at location > http://www.textuality.com/RDF/WhyRDF.html > > The PropertyType resources here are Author and > Home-Page. The Property is Description. It > consists of the resource, the property types > Author and Home-Page, and each one's > corresponding value. > > Now, given that, we could perhaps add an id > attribute to the RDF element, say, > "description", and then further describe this > entire property with something like: > > > Adam Donahue > > > Now the resource is the Description property, > and the property type of *this* resource is > Person, indicating here, for example, the person > who indexed the original description. > > Further, I could add an id attribute to the > Person element, say, persontype, and then > describe to a particular the Person PropertyType > in the Indexer resource, like: > > > ... > > > Now, if this is true, I'm a bit confused. What > if I have several elements in my > document. How do I describe, *in general*, a > Person PropertyType? It would appear that if I > point to a particular instance (as in this > example), it would only apply to this instance? > Does this make sense? That is, I have a unique > ID as an attribute to the Person PropertyType in > the above. I am pointing to it in href="..">, but this element only points to the > ID of *that* particular Person PropertyType > (namely, the one containing "Adam"). What if I > have one with Bob? And what if I just want to > describe the PropertyType itself, in general? > I'm missing something here. Please clarify... > > Thanks, > Adam > > > > > > mailto:adam@cyber-guru.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Jun 11 18:44:01 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:11 2004 Subject: XSchema Spec Section 2.3, Draft 1 Message-ID: This one is much longer than its predecessors, for which I apologize. Section 2.3 defines the Content Model Declarations, which presently appear as sub-elements of the Element Declaration. This section is based on the unified John Cowan/Ron Bourret DTD, except that I added PCData back into the Mixed Declaration. All comments, suggestions, alternative proposals, and giggles are welcome. I haven't had time to modify this for suggestions made about section 2.2. Hopefully I'll be able to put it together next week. I hope to have 2.4 on attributes out tomorrow or possibly Saturday, depending on how quickly I can write a chapter on Proxy Servers that's due tomorrow. I'm moving from Greensboro, NC, to Ithaca, NY on Monday, so my communications will be more intermittent than usual. It's difficult to check email while driving a U-Haul truck, and I don't have a cellular modem or phone anyway. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies ------------------------ 2.3 Content Model Declarations Content model declarations are made within the declaration for the element to which they apply. 2.3.1 Empty Content Model The simplest content model is empty, which indicates that the parent element has no sub-elements and no character data content. The XSC:Empty element indicates that an element is empty. If the Species element shown in the previous section were to be declared as empty, the XSchema declaration for that element would look like: This would not allow the Species element to contain any text or sub-elements. 2.3.2 Any Content Model The Any content model, which allows the element to contain parsed character data or any other elements as content, is equally simple: Using the Any content model is much like using the Empty content model. If the Species element had a content model of any, the XSchema declaration for the Species element would look like: This would allow the Species element to contain text and any sub-elements an author desired. 2.3.3 PCData Content Model The PCData content model, which allows the element to contain only parsed character data, is also represented by a single empty element. Using the PCData content model is much like using the Empty and Any content models. If the Species element had a content model of PCData, the XSchema declaration for the Species element would look like: This would allow the Species element to contain text, but no sub-elements. 2.3.5 Reference Content Model The Reference content model allows an element to specify other elements which it may contain, as well as their quantity. XSC:Ref elements identify the element to be contained, as well as the frequency with which it must appear: An XSC:ElementDecl element may contain only a single XSC:Ref element. To define content models that permit or require the use of more elements, the Any, Mixed, Choice, or Sequence content models should be used as appropriate. If the Species element were to contain a single CommonName element, and nothing else, the declaration would look like: This would require the Species element to contain a single CommonName element. To make the CommonName element optional - though it may still only appear once, set the Frequency attribute to 'Optional': Optional is the equivalent of the ? occurrence indicator in XML 1.0 DTDs. To require the Species element to contain at least one but possibly multiple CommonName elements, set the Frequency attribute to 'OneOrMore': OneOrMore is the equivalent of the + occurrence indicator in XML 1.0 DTDs. Finally, to allow the Species element to contain any number (including zero) of CommonName elements, set the Frequency attribute to 'ZeroOrMore': OneOrMore is the equivalent of the * occurrence indicator in XML 1.0 DTDs. 2.3.6 Mixed Content Model Mixed content models allow the unordered use of different element types and character data. Content within an element that uses a mixed declaration must be PCData (if PCData is declared) or one of the elements referenced by an XSC:Ref element nested within the XSC:Mixed declaration. If the Species element were to contain a mix of CommonName elements, LatinName elements, and PreferredFood elements in any order, the declaration would look like: If the Species element were to allow PCData as well as those declarations, the PCData element must appear first in the listing: 2.3.7 Choice Content Model The Choice content model allows for either-or inclusions of elements and groups of elements. The Choice content model represents groups of element content possibilities and must contain at least two sub-elements. Situations where only one element is needed should use the Ref content model instead of Choice. At its simplest, an XSC:Choice element will contain two Ref elements and a frequency attribute. The XSC:Choice element may also indicate a frequency, allowing the content model defined by the XSC:Choice model to appear one, one or zero, one or more, or zero or more times. By default, the XSC:Choice element's content model is required to appear once. If the Species element were to allow either a Common Name or a Latin Name, but not both, the following declaration would be appropriate: The XSC:Ref elements in an XSC:Choice element may also specify the frequency with which they appear, as may the XSC:Seq elements described in section 2.3.8. The XSC:Choice element is the equivalent of the choice group (element | element) in XML 1.0 DTDs. The ordering of the XSC:Ref elements within an XSC:Choice element has no effect. 2.3.8 Sequence Content Model The Sequence content model allows for the sequential appearance of sub-elements. Elements, if they are required to appear, must appear in the order of the XSC:Choice and XSC:Ref sub-elements in the XSC:Seq element. At its simplest, an XSC:Seq element will contain two Ref elements in the order in which they should appear and a frequency attribute. The XSC:Seq element may also indicate a frequency, allowing the content model defined by the XSC:Seq model to appear one, one or zero, one or more, or zero or more times. By default, the XSC:Seq element's content model is required to appear once. If the Species element were to require a Common Name and a Latin Name, in that order, the following declaration would be appropriate: The XSC:Ref elements in an XSC:Seq element may also specify the frequency with which they appear, as may the XSC:Choice elements. The XSC:Seq element is the equivalent of the sequence group (element , element) in XML 1.0 DTDs. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 11 19:22:05 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:11 2004 Subject: XSchema Spec Section 2.3, Draft 1 References: Message-ID: <35801163.C64BCD5C@locke.ccil.org> Simon St.Laurent wrote: > I added PCData back into the Mixed > Declaration. I think (and I believe Ron also thinks) that this is completely unnecessary. A mixed-content model without #PCDATA is not mixed content at all; it's just a limited kind of Choice (only Refs as children). The whole point of Mixed is that it signals that both PCDATA and elements are permitted. It occurs to me that the Mixed element should have a Frequency attribute declared #FIXED "ZeroOrMore". -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Jun 11 19:50:34 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:11 2004 Subject: XSchema Spec Section 2.3, Draft 1 Message-ID: >The whole point of Mixed is that it signals that >both PCDATA and elements are permitted. > >It occurs to me that the Mixed element should have a >Frequency attribute declared #FIXED "ZeroOrMore". I can accept dropping the PCData - it takes out a nuisance declaration - but now I wonder about PCData elements. They're technically Mixed but without any optional elements. Do we need PCData elements? Also, why does the element need a frequency attribute? Isn't that built into the nature of Mixed? It's not like you can nest a Mixed content model under a Choice or Seq directly or anything... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jun 11 20:31:05 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:12 2004 Subject: XSchema Spec Section 2.3, Draft 1 References: Message-ID: <35801ECB.FC7FB399@locke.ccil.org> Simon St.Laurent wrote: > I can accept dropping the PCData - it takes out a nuisance declaration - but > now I wonder about PCData elements. They're technically Mixed but without any > optional elements. Do we need PCData elements? That was my original design. Ron thought it was clearer to allow an explicit PCData element equivalent to an empty Mixed element, and I acquiesced. > Also, why does the element need a frequency attribute? Isn't that built into > the nature of Mixed? It's not like you can nest a Mixed content model under a > Choice or Seq directly or anything... It *is* "built in", which is why it can sensibly be represented by a #FIXED attribute. That way, people can see Mixed, Seq, and Choice as adhering to a common "frequency architecture". Just a thought, not anything I'm fanatical about. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Thu Jun 11 20:41:08 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:02:12 2004 Subject: Question about Architectures and Versioning Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA3DE@red-msg-08.dns.microsoft.com> How does one go about using Architectures to solve the following problem.   Suppose in version one of my documents, I have instances that look like   Gone With the Wind   In version 2, I have instances that look like       Gone With the Wind                         Margaret             Mitchell               How do I write my architectures so that the v2 instance is mapped to the v1 architecture?   Thanks,   Andrew Layman xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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.Brownell at Eng.Sun.COM Thu Jun 11 23:49:05 1998 From: David.Brownell at Eng.Sun.COM (David Brownell) Date: Mon Jun 7 17:02:12 2004 Subject: Encoding dcl in external DTD subsets Message-ID: <199806112147.OAA28618@argon.eng.sun.com> > From: MURATA Makoto > Date: Thu, 11 Jun 1998 13:32:08 +0900 > > David Brownell wrote: > > > > That, and the way " isn't permitted in > > DTDs, have made me wonder if there are any other litle nudges > > As you pointed out in your private mail to me, encoding declarations > in external DTD's are permitted. You are right that the XML spec is > not clear enough. > > xp does support encoding declarations. That'd be the most current version; an earlier one didn't. Some other parsers (you _should_ know who you are :-) still don't. I'm now persuaded that the spec does do what I thought it should do. An earlier scan was less conclusive, particularly in conjunction with several parsers that rejected such decls !! - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From xiaokui at richsight.com Fri Jun 12 02:42:11 1998 From: xiaokui at richsight.com (Luoxiaokui) Date: Mon Jun 7 17:02:12 2004 Subject: unsubscribe Message-ID: <35806B55.BF4D698D@richsight.com> unsubscribe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Fri Jun 12 06:08:15 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:02:12 2004 Subject: Another member of the family Message-ID: <3.0.32.19980611210532.00bc0c10@pop.intergate.bc.ca> [from http://www.zdnet.com/zdnn/stories/zdnn_display/0,3440,325742,00.html ] XML gets a boost from powerful allies A group of major software vendors today proposed that the Open Management Group adopt XML as the standard for exchanging programming data over the Internet. The proposal, submitted in outline form at an Orlando, Fla., meeting of the standards body, targets Extensible Markup Language as the cornerstone of an open information interchange model. Under the proposal, XML would be used as the standard for exchanging data between tools, applications and repositories-a major benefit within team development environments. Companies submitting the proposed standard included IBM, Unisys Corp., Oracle Corp. and Platinum Technologies Inc. Also joining the group was the Distributed Systems Technology Centre, an Australian research group comprising the government and private sector. Supporters included Select Software Tools Inc., Inline Software and Sybase Inc. The companies will submit an official version of the proposed XML Metadata Interchange Format specification during the Open Management Group's July meeting in Helsinki. XML is a standard set by the World Wide Web Consortium for defining, validating and sharing document formats on the Web. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Fri Jun 12 07:05:31 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:12 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <3.0.1.16.19980504090531.2fa7aec0@pop3.demon.co.uk> Message-ID: <199806120507.AA01440@murata.apsdc.ksp.fujixerox.co.jp> Peter Murray-Rust wrote: > The XML Recommendation creates a category of attributes which have intent. > (2.10 xml:space, 2.12 xml:lang). I believe that this raises implementation > problems for which we may wish to devise a common protocol. The same > problem arises in implementing XLink which, although not final, appears > likely to contain the same (or closely related constructs). By the way, do you think that an element of one namespace should be able to inherit attributes from another element of a different namespace? If we would like to forbid such inheritance, we can simply say "Inheritance stops when namespaces switch" or explicitly say "an element whose namespace is different from that of its immediate superior must explicitly specify xml:space and xml:lang". Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Fri Jun 12 08:29:24 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:02:12 2004 Subject: IE5 support for XML and CSS Message-ID: <01bd95cc$1cba99a0$aeacdccf@bckman.ix.netcom.com> In case you missed it IE5 will support much of CSS2, and will also allow embedding of an XML document via an tag or a