From SimonStL at classic.msn.com Wed Jul 1 00:29:09 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:32 2004 Subject: 'Optional' vs 'Implied' in XSchema Message-ID: Jarle Starbell wrote: >I think it is unecessary confusing to have both of the pairs >('Required', 'Optional') >and >('Required', 'Implied') > >in the XSchema vocabulary. >... >I know that 'Implied' is what is used within DTDs, but personally I find >'Optional' to be much more "to the point", I find 'Implied' quite >"mysterious". Implied is very mysterious. It's been an open question throughout how closely to stick to the spec's terminology, including its mysterious parts. If people feel strongly about this, we should ponder change. I think at this point the weight is more toward keeping the mysteries of the past alive, while explaining them better, but I could be persuaded to change this. Opinions? 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 richard at cogsci.ed.ac.uk Wed Jul 1 00:35:47 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:02:32 2004 Subject: PCDATA vs CDATA In-Reply-To: Tom Otvos's message of Tue, 30 Jun 1998 15:53:29 -0400 Message-ID: <28211.199806302235@cockburn.cogsci.ed.ac.uk> > Hmm, is that the only case where an XML parser might do the "wrong thing" if > it came across a document without a supporting DTD? Yes. There are some things an XML parser can't do without a DTD: - validating (obviously) - determining which whitespace is ignorable - normalising attributes and inserting default values - expanding entity references but despite those constraints it can parse the document and determine whether it is well-formed. > It seems to me that if > a document comes through without a DTD, and an element contained data not > explicitly escaped, then it would not be unreasonable to assume PCDATA and > try to parse it. However, if a DTD is there to provide more info, then use > it. I am not sure I see how it is significantly different than validating > that an element may, or may not, be a child of another element. If the parser doesn't know that the content of an element is CDATA it will very likely parse a correct document wrongly. This is not the case if it just doesn't know what children are allowed. For example, if c were declared CDATA and the parser didn't have the DTD, it would report a syntax error for > Various other features of SGML have been omitted for the same reason, in particular start- and end-tag omission. Similarly a new syntax has been created for empty elements, because without the DTD a parser can't tell that an element must be empty. -- 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 SimonStL at classic.msn.com Wed Jul 1 00:39:06 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:32 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) Message-ID: James Anderson wrote: >the extra resolution mechanism, should it be necessary, still does not >require an additional means of expression. We have two choices: a) we can use the same means of expression already provided, and make it harder to distinguish XSchema namespaces from the namespaces used for the contents of those XSchemas. It may seem more elegant to those who would like one and only one way of declaring something. b) we can use an additional means of expression. This may not seem as consistent, but brings other advantages, like the ability to provide documentation about what a namespace is really representing, anyway. I'm still in the b) camp. I really don't want XSchemas to have to rely on _any_ PIs; I'm even irritated by the PI needed for the XSchema namespace itself. PIs are gradually blooming across the XML landscape like hideous rotten flowers. (Yes, I'm strongly biased against PIs, if you hadn't noticed already.) 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 Jul 1 00:43:34 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:32 2004 Subject: Cross linking inside XSchema documentation? (XSchema Spec Section 2.6) Message-ID: >I wonder how one should make (possible) hyperlinks in the doc to other >items inside the XSchema, something "equivalent" to the below: This sounds interesting; it would be more dependent on changes to the IBTWSH format than changes to XSchema. John? 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 Wed Jul 1 01:10:21 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:32 2004 Subject: PCDATA vs CDATA In-Reply-To: <28211.199806302235@cockburn.cogsci.ed.ac.uk> (message from Richard Tobin on Tue, 30 Jun 1998 23:35:26 +0100) Message-ID: <199806302308.TAA02754@ruby.ora.com> [Richard Tobin] > For example, if c were declared CDATA and the parser didn't have the > DTD, it would report a syntax error for > > > He means, of course < A better example is: In SGML, if has CDATA declared content, then the content of is the string "". In XML+CDATA, without a DTD, this is indistinguishable from containing an empty element . -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 SimonStL at classic.msn.com Wed Jul 1 03:12:30 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:32 2004 Subject: Obscure Ignore production Message-ID: Could someone explain what Ignore [65] in the XML 1.0 spec is? It seems to duplicate content from [64] to no apparent purpose. It may just be my EBNF illiteracy, but something weird's up here. I didn't see any annotation in the xml.com version, either. Reading specs too closely is fun... Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jul 1 03:23:17 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:32 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) In-Reply-To: <35991B1E.2AF350B1@mecomnet.de> Message-ID: <3.0.1.16.19980701022402.54df3a78@pop3.demon.co.uk> At 19:06 30/06/98 +0200, james anderson wrote: [...] > >and yes, this is an aspect of the namespace proposal (if not xml as a whole) >which i believe is dented, if not broken: name qualification should apply to >all values which either are tokens or denote tokens (ie the various attribute >values and notations). othrwise the whole thing becomes unworkable. It is important to remember that the namespace proposal is still in draft. I am party to the XML-SIG discussions on namespaces but am bound by confidentiality. I have no information about when the next draft or any prior announcements may occur. Therefore this section will have to include some caveats about being mutable. 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 aray at q2.net Wed Jul 1 03:34:32 1998 From: aray at q2.net (Arjun Ray) Date: Mon Jun 7 17:02:32 2004 Subject: Obscure Ignore production In-Reply-To: Message-ID: On Wed, 1 Jul 1998, Simon St.Laurent wrote: > Could someone explain what Ignore [65] in the XML 1.0 spec is? Any string that that doesn't have marked section delimiters ('') in it. > It seems to duplicate content from [64] to no apparent purpose. The point is that there can be marked sections nested inside an IGNORE MS. So, a straight scan for an ending ']]>' isn't enoguh. Arjun xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 1 06:17:31 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:32 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <3.0.1.16.19980618193555.1aa7f7ae@pop3.demon.co.uk> Message-ID: <199807010420.AA01545@murata.apsdc.ksp.fujixerox.co.jp> Peter Murray-Rust wrote: > > This is very clear :-). It is exactly this sort of thing that concerns me. > It's not that it's intrinsically difficult, but: > - a it's easy for someone to overlook when writing an *application*. > (Remember that - at present - inheritance is implemented by the application. > - *every* application - potentially - has to consider whether > 'inheritance' applies to it. It may decide it doesn't need to worry, but > the author of the documents may assume that all applications are > 'inheritance-aware'. This will certainly not be true. > - the word 'inheritance' is understood differently by different SGML/XML > experts and therefore may lead to differences in implementation. We can implement attribute inheritance by SAX or other event-driven API's (e.g., XML in perl). We only have to introduce one method of the class DocumentHandler. setInheritedAttributes(String) This sets names of inherited attributes. By default, "xml:lang" and "xml:space" are inherited. An attributeList (the second argument for startElement) now contains attribute-value pairs for inherited attributes. Does such an API cover your concern? Of course, this has to become namespace-aware. That is, the argument of setInheritedAttribute should be a pair of URI and local part. Does this cause troubles to your implementation? > Paul 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 tbray at textuality.com Wed Jul 1 07:55:14 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:02:32 2004 Subject: PCDATA vs CDATA Message-ID: <3.0.32.19980630225454.00a5bbac@pop.intergate.bc.ca> At 02:32 PM 6/30/98 -0400, Tom Otvos wrote: >Why can an element's mixed content only be declared as PCDATA, not CDATA? SGML compatibility, sigh. Because CDATA content is broken as designed in SGML; for example, you can't declare element to be of type CDATA and then do: xxx..xx Because the rules say that a CDATA element is terminated not, as you might expect, by its end tag, but by the first occurrence of ETAGO, a.k.a. "" or "]]>" are just amateurish and broken. We've known for years how to do this; either escape delimiters or put in a byte count. The idea of a built-in signal for a base64 encoding is starting to look better and better to me. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jul 1 09:36:24 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:32 2004 Subject: extensibility in XSchema? In-Reply-To: <199806301717.TAA13169@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980701082152.54df65f4@pop3.demon.co.uk> At 19:17 30/06/98 +0200, Ron Bourret wrote: [...] >By the way, I'm currently writing an XSchema-to-DTD processor built on top of >SAX (first version available tomorrow if I figure out namespaces), but my next >project will be an XSchema conformance checker also built on SAX. Assuming this >code also generates SAX events, it can be easily be reused by others, so >conformance becomes even less of a problem. This is wonderful Ron. As for namespaces - I think it's worth *experimenting* and publishing our results. Remember that (a) the final version is not there (b) namespaces are not required to *do* anything other than uniquify names. I would advise against attaching any semantics to any part of the current public namespace draft. I think following the current public draft minimally and faithfully will be valuable. In JUMBO I have started to apply a minimalist approach the namespaces which: - can generate a UniqueName by the concatenation of the prefix and the local name - checks for uniqueness as required by the draft - can retrieve the Namespace determined by a prefix and that's all. Clearly you have to use the UniqueName in the interpretation of the Schema just as a validating parser might have to expand the name and check it against a namespace-aware DTD (if/when such a thing exists). P. > >-- 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) > > 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 Jul 1 09:36:25 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:32 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <199807010420.AA01545@murata.apsdc.ksp.fujixerox.co.jp> References: <3.0.1.16.19980618193555.1aa7f7ae@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980701083530.560f1a56@pop3.demon.co.uk> Thank you very much for your suggestion. At 13:20 01/07/98 +0900, MURATA Makoto wrote: [...] >We can implement attribute inheritance by SAX or other event-driven >API's (e.g., XML in perl). > >We only have to introduce one method of the class DocumentHandler. > > setInheritedAttributes(String) > > This sets names of inherited attributes. By default, > "xml:lang" and "xml:space" are inherited. > >An attributeList (the second argument for startElement) >now contains attribute-value pairs for inherited >attributes. > >Does such an API cover your concern? If we agree on it I think it's undoubtedly the best way forward :-). IOW we build a public implementation of 'inheritance' - make the code and examples public and that effectively defines what the community at large understands by the spec. In this way anyone on the SIG or WGs who has a differently interpretation can speak up now. The only qualification is that the API has to be very well documented so we all agree what it does! P. > >Of course, this has to become namespace-aware. That is, the argument >of setInheritedAttribute should be a pair of URI and local part. Of course. And working this out in public would be valuable. 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 murata at apsdc.ksp.fujixerox.co.jp Wed Jul 1 10:12:01 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:33 2004 Subject: Example XML documents in Japanese In-Reply-To: <199805190652.AA01126@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <199807010814.AA01551@murata.apsdc.ksp.fujixerox.co.jp> MURATA Makoto wrote: > Example XML documents in Japanese are available. Now, you can get each XML file via the HTTP protocol. The media type is "text/xml". The charset parameter is provided. On purpose, I omitted encoding declarations. These XML files can be found from this URL: http://www.fxis.co.jp/DMS/sgml/xml/charset/ Have fun and perfect I18N of XML! Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Wed Jul 1 10:42:33 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:33 2004 Subject: 'Optional' vs 'Implied' in XSchema Message-ID: <199807010838.KAA15243@berlin.dvs1.tu-darmstadt.de> > >I know that 'Implied' is what is used within DTDs, but personally I find > >'Optional' to be much more "to the point", I find 'Implied' quite > >"mysterious". > > Implied is very mysterious. It's been an open question throughout how closely > to stick to the spec's terminology, including its mysterious parts. If people > feel strongly about this, we should ponder change. I think at this point the > weight is more toward keeping the mysteries of the past alive, while > explaining them better, but I could be persuaded to change this. This is a good point. On the naming ballot, the second list of possible names was meant to be non-mysterious names and for some reason I missed Implied. I will change it there. Simon -- does this go away anyway with the changes to the AttDef element proposed by Chris Maden? I wasn't completely sure how those were being implemented. -- 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 Wed Jul 1 10:56:04 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:33 2004 Subject: XSchema: root element Message-ID: <199807010850.KAA15401@berlin.dvs1.tu-darmstadt.de> Simon St. Laurent wrote: > Ron Bourret wrote: > >I now believe we should bring RootElement back as an optional attribute > >(NMTOKEN, #IMPLIED). The primary reason is for authoring, although it would > >also be useful in DTD exploration. > > I think you're right, but where do you want the attribute? In the XSC:XSchema > element, or in the element declarations themselves? The XSC:XSchema solution > would only allow you to define one root element (you could go to NMTOKENS, of > course), while the element solution is messier but allows multiple possible > root elements for authoring. I think it's actually cleaner on the element declarations than on the XSchema element -- we don't have to have language in the spec about ignoring the attribute. All we say is that any element that can be the root of a meaningful document should set the attribute to True. You might also want to explain the conditions in which you might have zero, one, or many root elements. The DTD syntax is: xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jul 1 12:19:04 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:33 2004 Subject: Attributes with Intent (and namespaces) Message-ID: <359A0DA0.FB0E8D64@mecomnet.de> what is the advantage to leaving the articulation (URI x local) part open in this interface? why isn't the parameter an opaque object? i'm not sure what the application concern is, but, for the relations which occurred to me, there are better ways to do that than having to broaden all name-related interfaces. if the issue is to "identify" symbols which, by prefix, reside in different regions of the articulated namespace, it could be done on a prefix to prefix basis or on a region to region basis - depending on whether the specification has a dynamic or an indefinite extent. if the issue is that one wants to do that on a name-by-name basis, there are better ways for that too. one could use a combination of importing and exporting names among regions. if the issue is that one whats to articulate the mapping per element, there are other ways to do that too, though i'm unclear why one would. MURATA Makoto wrote: > [re remarks from Peter Murray-Rust re attribute inheritance] > > Of course, this has to become namespace-aware. That is, the argument > of setInheritedAttribute should be a pair of URI and local part. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jul 1 12:21:03 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:33 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) Message-ID: <359A0E09.3DB48392@mecomnet.de> if the namespace pi becomes the standard way to express the binding between a prefix and a namespace region, then parsers will need to support it. if it doesn't then some other mechanism will become standard. i really don't care what the mechanism is. (seven months ago my associations with neither "element" nor "pi" were pleasant, as they were still dominated by a certain "ms.godsee" and "mr.goldstein", nether of whom were particularly inspiring...) what matters is that, once one is standard, the mechamisms to provide for symbol distinction / identity will already exist. it doesn't make sense to require that a second mechanism duplicate (part of) the behaviour of the first. any processor which can read a document which follows the scahem spec will already have to be "namespace aware". it makes much more sense to require of the first mechanism, that it offer an (additional) interface function of the form (document X qualified-name ) -> symbol. yes, this is missing in the present namespace proposal. which is reason to fix it (given that it's still in flux), not reason to do something else. for documentary purposes, or to bind a schema to the ns identifier if/once the src attribute gets dropped from the namespace pi, a namespace declaration for xschema makes perfect sense. Simon St.Laurent wrote: > > James Anderson wrote: > >the extra resolution mechanism, should it be necessary, still does not > >require an additional means of expression. > > I'm still in the b) camp. I really don't want XSchemas to have to rely on > _any_ PIs; I'm even irritated by the PI needed for the XSchema namespace > itself. PIs are gradually blooming across the XML landscape like hideous > rotten flowers. (Yes, I'm strongly biased against PIs, if you hadn't noticed > already.) an encoding which requires that information appear redundantly makes sense only in the face of noise or some other potential for misinterpretation. that's not the problem 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 murata at apsdc.ksp.fujixerox.co.jp Wed Jul 1 13:19:44 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:33 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <359A0DA0.FB0E8D64@mecomnet.de> Message-ID: <199807011122.AA01557@murata.apsdc.ksp.fujixerox.co.jp> james anderson wrote: > > what is the advantage to leaving the articulation (URI x local) part open in > this interface? why isn't the parameter an opaque object? i'm not sure what > the application concern is, but, for the relations which occurred to me, there > are better ways to do that than having to broaden all name-related interfaces. The designer of a namespace merely provides a URI as well as element type names and attribute names. They do not provide unique prefixes. Prefixes within documents are merely local proxies. It would be dead wrong for application programs to rely on prefixes. 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 Wed Jul 1 15:27:30 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:33 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) Message-ID: >it doesn't make sense to >require that a second mechanism duplicate (part of) the behaviour of the >first. Philosophically, XSchema's already a massive second mechanism. >any processor which can read a document which follows the scahem spec >will already have to be "namespace aware". it makes much more sense to >require of the first mechanism, that it offer an (additional) interface >function of the form > (document X qualified-name ) -> symbol. >yes, this is missing in the present namespace proposal. which is reason to >fix it (given that it's still in flux), not reason to do something else. As I said before, this is one option. I don't think the namespace proposal adds anything to our processing of the XSchema at this point which the namespace element doesn't do better. I don't see XSchemas needing to including both the namespace declaration for XSC-whatever and the declarations for the instance elements; this separates the NS declaration for the XSchema itself from the namespace declarations of documents-to-be-processed quite neatly and adds extra functionality (documentation, etc.) that I think is needed to make namespaces friendlier. >for documentary purposes, or to bind a schema to the ns identifier if/once >the src attribute gets dropped from the namespace pi, a namespace declaration >for xschema makes perfect sense. Precisely. >an encoding which requires that information appear redundantly makes sense >only in the face of noise or some other potential for misinterpretation. >that's not the problem here. Yes, the information will have to appear in the namespace declaration of the document and in the namespace element of the XSchema used to define it. The issue isn't noise; the issue is independence from a painful search-and-replace should the document or the XSchema owner change the prefix. The information will need to appear in both the document and the XSchema in one form or another. 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 amitr at abinfosys.com Wed Jul 1 15:39:29 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:02:33 2004 Subject: Passing #FIXED values through para. entity refrences Message-ID: <014701bdbbc0$63b78b50$0201a8c0@amit.abinfosys.com> Martin , >Unfortunately there is currently no standardized mechanism for passing >parameters to default attribute values. Is there no other way (except parameter passing), that can solve the problem of encapsulating two attribute declarations (which are identical except for their fixed default values) in one entity? (The reason I thought there could be one was because if it makes sense to encapsulate something which is 100% identical , then something which is 90% same (except for the fixed default values) should also be a possible candidate for encapsulation.) A new proposal for >the modularization of SGML DTDs through entity references may make this >possible later, but not for the time being in XML. Is any such proposal being worked on?If so when is it expected? Is there any formal documentation of DTD modularization and compaction techniques you would be knowing of? Thanking You, AMIT >Amit > >Unfortunately there is currently no standardized mechanism for passing >parameters to default attribute values. When fixed values are required to be >defined in the DTD you must declare them individually. (A new proposal for >the modularization of SGML DTDs through entity references may make this >possible later, but not for the time being in XML.) > >Martin Bryan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980701/5209333d/attachment.htm From CallaghanN at NPRI70.NPT.NUWC.NAVY.MIL Wed Jul 1 16:06:05 1998 From: CallaghanN at NPRI70.NPT.NUWC.NAVY.MIL (Callaghan Nancy NUWCDIVNPT) Date: Mon Jun 7 17:02:33 2004 Subject: unsubscribe Message-ID: unsubscribe callaghann@npri70.nuwc.npt.navy.mil xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 1 16:08:27 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:33 2004 Subject: XSchema Spec Section 2.0 and 2.1, Draft 3 Message-ID: The third (and hopefully final) draft of sections 2.0 and 2.1 follows. There was a mystery 2nd draft that I failed to post; it just removed entities from the spec. This version adds the XSC:More extension element. Both versions will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.0 XSchema Syntax This section describes the XSchema document syntax. The XSchema document is an XML document containing a single XSchema element in which information describing the schema is nested. The XSchema element must be preceded by an XML declaration and may be preceded by other declarations, comments, and processing instructions. 2.1 The XSchema Element The XSchema element is the root element for all XSchema documents. The declaration for the XSchema element is: The 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. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jul 1 16:10:42 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:33 2004 Subject: Attributes with Intent (and namespaces) References: <199807011122.AA01557@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <359A437A.AD3BDB30@mecomnet.de> there are two situations. in a global context the uri is correct. if one wishes to resolve a name in the dynamic context of a document or of an element, the prefix, in addition to the uri, would be correct. although this (the prefix qualification), in any case, is not something an application should have to do (therefore the concern for an opaque object, which question still stands), it is something which a specification which is part of an encoded document would need to express. within the document itself it would be wrong ( i won't say 'dead wrong', but it would be more cumbersome) to specify relations among symbols and or namespace regions according to uri, particularly given that there are already prefix bindings in effect in that dynamic context. which is where the prefixes come in. in global context, one shouldn't be worrying about qualification any more, the tokens which the parser generates whould be globally unique. (the opaque objects again...) MURATA Makoto wrote: > > james anderson wrote: > > > > what is the advantage to leaving the articulation (URI x local) part open in > > this interface? why isn't the parameter an opaque object? i'm not sure what > > the application concern is, but, for the relations which occurred to me, there > > are better ways to do that than having to broaden all name-related interfaces. > > The designer of a namespace merely provides a URI as well as element type > names and attribute names. They do not provide unique prefixes. Prefixes > within documents are merely local proxies. It would be dead wrong for > application programs to rely on prefixes. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jul 1 16:31:19 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:34 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) References: Message-ID: <359A48BD.D59D6CFA@mecomnet.de> you've lost me here. i thought that's what the namespace pi was for. Simon St.Laurent wrote: > > ... The > issue isn't noise; the issue is independence from a painful search-and-replace > should the document or the XSchema owner change the prefix. The information > will need to appear in both the document and the XSchema in one form or > another. > as with the initial discussion of this issue (the "biting the bullet" note - http://www.lists.ic.ac.uk/hypermail/xml-dev/9806/0150.html) i don't see the problem. as i said then, an example might help. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 1 17:13:16 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:34 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) Message-ID: >i thought that's what the namespace pi was for. Then you've missed my point. The namespace PI applies namespaces to documents - namespace-aware applications should expand the prefix to the full name provided in the ns production. XSchemas need one of these for the XSC: stuff, and extensions (the XSC:More area) will require additional declarations for their extension namespaces. For instance, an XSchema in the current version will begin: The namespace above is a total waste of time The exciting document might look like: The XSchema could instead have been written: But as you can see, the namespace declaration has to appear both places in one form or another for the src information to line up if the prefix changes, as is likely. Since we're making the rest of the declarations more documentable, why not namespaces? It gets them out of the way and gives them a good home within the XSchema, where they can be documented, manipulated, and edited with relative ease. Actually, I'm beginning to consider namespaces a plot to keep authors from meeting their deadlines rather than a great help to society. I've got to turn in chapters tomorrow, so I'll be off the air for the rest of today. 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 Jul 1 17:15:07 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:34 2004 Subject: XSchema Spec Section 2.6, Draft 1 In-Reply-To: from "Simon St.Laurent" at Jun 30, 98 01:46:38 am Message-ID: <199806301501.LAA25906@locke.ccil.org> Simon St.Laurent scripsit: > Any element allowed in the horiz.model set of elements (A, BR, SPAN, XML, > CITE, CODE, DFN, EM, KBD, SAMP, STRONG, VAR, FONT, or parsed character data) > may be used in the XSC:Doc element. > > ***- John - Any thoughts on namespaces for IBTWSH? Any connections to style > sheets, or should that be PIs like XML? IBTWSH excludes namespaces for the present, because the whole point of it is to be HTML-compatible (except for the XML element, which is for recursively included XML). An application should be able to forward the content of the XSC:Doc element straight to an HTML process without inspecting it. I invite comment on style sheets, of which I have little understanding. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jul 1 17:36:44 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:34 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) Message-ID: <359A580B.C1A1BCEE@mecomnet.de> you are suggesting a problem where there is none. leave the prefix <-> namespace-region mechanism alone. it's not bothering you. unless the purpose is to document the prefix, then the schema encoding should take the form The namespace (region) above is a total waste of time otherwise, you're encoding things which you do not mean. Simon St.Laurent wrote: > > For instance, an XSchema in the current version will begin: > > > > > The namespace above is a total waste of time > > > > > > > The exciting document might look like: > > > > > > ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 1 17:43:29 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:34 2004 Subject: XSchema: Sample naming ballot In-Reply-To: <199806301136.NAA12051@berlin.dvs1.tu-darmstadt.de> from "Ron Bourret" at Jun 30, 98 01:36:32 pm Message-ID: <199806301530.LAA27150@locke.ccil.org> Ron Bourret scripsit: > 1) I will mail a ballot to the list on Friday, July 3 (is this a US holiday?), Technically, no; 4 July (Saturday) is the U.S. national day. However, many people will be away from work (and email) for the entire Friday-Sunday period, as many companies allow 3 July as an effective holiday. I suggest postponing the ballot for that reason. -- 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 Wed Jul 1 17:57:52 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:34 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) In-Reply-To: <35991B1E.2AF350B1@mecomnet.de> from "james anderson" at Jun 30, 98 07:06:48 pm Message-ID: <199806301545.LAA28056@locke.ccil.org> james anderson scripsit: > and yes, this is an aspect of the namespace proposal (if not xml as a whole) > which i believe is dented, if not broken: name qualification should apply to > all values which either are tokens or denote tokens (ie the various attribute > values and notations). othrwise the whole thing becomes unworkable. The fact is that the Namespace draft as it is (which is what we have to work with) doesn't provide for parsers doing colon-ectomies on attribute values. IMHO it shouldn't; there is no reason to think a priori that an attribute value that happens to contain a colon is necessarily a namespace-qualified name. If XML had retained attributes of type NAME, there might have been some case for them, but NMTOKENs are just too broad. [many "should"s deleted] > it's not messy, it's very simple. don't think strings. think symbols. it > doesn't matter where they came from, or what prefix they had at the time they > wre interned, just whether or not they're equal. once they've been parsed, you > should only ever have too look at the prefix again if you should need to > serialize. - that's why the parser needs to intern all values which can are, > or which can denote, tokens. But just which attribute values are those? Lisp has syntax to distinguish symbols from strings, but we have only inference: therefore, general parsers must assume that attribute values are strings. -- 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 Wed Jul 1 18:04:08 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:34 2004 Subject: XSchema: root element In-Reply-To: <199806301651.SAA13109@berlin.dvs1.tu-darmstadt.de> from "Ron Bourret" at Jun 30, 98 06:51:21 pm Message-ID: <199806301551.LAA28298@locke.ccil.org> Ron Bourret scripsit: > For example, suppose I have a generic XML editor. I pick an XSchema from a list > of XSchemas and want to start writing. But where do I start? If the XSchema is > just a set of elements, I can pick my own root. But if the XSchema creator had > a starting place in mind, like the element in HTML, I need to start in > the correct place or I won't create a valid file. What does "valid" mean here? If it has its technical XML sense, thenn no, the document instance will be valid staring from any root as long as you mention that element in the DOCTYPE declaration. If you mean that some later-stage application will barf unless it sees a specific root, then you may be right. I would rather see an optional attribute in the ElementDecl element marking that it makes (semantic) sense for this element to be a root. -- 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 Wed Jul 1 18:10:27 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:34 2004 Subject: PCDATA vs CDATA In-Reply-To: <002d01bda455$7e998e50$160410ac@nebula.everyware.com> from "Tom Otvos" at Jun 30, 98 02:32:52 pm Message-ID: <199806301557.LAA28603@locke.ccil.org> Tom Otvos scripsit: > Why can an element's mixed content only be declared as PCDATA, not CDATA? Primarily, IMHO, because non-valididating parsers don't need to understand content models. Such parsers can assume that what looks like markup *is* markup, except specifically within the brackets "". -- 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 Wed Jul 1 18:23:11 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:34 2004 Subject: Cross linking inside XSchema documentation? (XSchema Spec Section In-Reply-To: from "Simon St.Laurent" at Jun 30, 98 10:41:52 pm Message-ID: <199806301610.MAA29030@locke.ccil.org> Simon St.Laurent scripsit: > >I wonder how one should make (possible) hyperlinks in the doc to other > >items inside the XSchema, something "equivalent" to the below: > > This sounds interesting; it would be more dependent on changes to the IBTWSH > format than changes to XSchema. John? Well, you could use the A element and assume that enlightened HTML processors will understand XPointer syntax when dereferencing XML URLs, or you could use the XML element and use non-inline XLinks. I would prefer the first option myself; currently, HTML processors understand fragment-ids only on HTML URLs, but that situation won't last forever. -- 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 Wed Jul 1 18:39:23 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:35 2004 Subject: PCDATA vs CDATA In-Reply-To: <3.0.32.19980630225454.00a5bbac@pop.intergate.bc.ca> from "Tim Bray" at Jun 30, 98 10:55:59 pm Message-ID: <199806301626.MAA29565@locke.ccil.org> Tim Bray scripsit: > Anyhow, the more I think about it, any of these schemes that depend > on a magic end-delimiter, e.g. "" or "]]>" are just > amateurish and broken. We've known for years how to do this; > either escape delimiters or put in a byte count. Byte counts lean over too far toward the "DP" view of XML. Documents that can be edited with general editors shouldn't contain counts of any sort. As for escaping delimiters, this is just the dual of the current scheme, with ">" as the representation of plaintext ">". (IMHO the Recommendation should have made this mandatory.) -- 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 Wed Jul 1 18:46:25 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema: root element In-Reply-To: <199807010850.KAA15401@berlin.dvs1.tu-darmstadt.de> from "Ron Bourret" at Jul 1, 98 10:50:44 am Message-ID: <199806301633.MAA29907@locke.ccil.org> Ron Bourret scripsit: > The DTD syntax is: > > As I posted earlier today, I favor this idea, but I dislike this syntax. Because of the #*$# interoperability restriction, we should avoid using "True" and "False" for any attribute values. Also, boolean attributes in general often indicate a poorly thought out design (See _Writing Solid Code_). Just what is "true" or "false" anyway? That it must be a root? No. That it can be a root? No (anything can be a root). That it should be a root? No. "False" ends up meaning "It shouldn't be a root", but "true" has no specific meaning. I propose: Root (Useful | NotUseful) "NotUseful". -- 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 Wed Jul 1 18:59:20 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) In-Reply-To: <359A0E09.3DB48392@mecomnet.de> from "james anderson" at Jul 1, 98 12:23:06 pm Message-ID: <199806301646.MAA00586@locke.ccil.org> james anderson scripsit: > what matters is that, once one is standard, the mechamisms to provide for > symbol distinction / identity will already exist. it doesn't make sense to > require that a second mechanism duplicate (part of) the behaviour of the > first. any processor which can read a document which follows the scahem spec > will already have to be "namespace aware". it makes much more sense to require > of the first mechanism, that it offer an (additional) interface function of > the form > (document X qualified-name ) -> symbol. > yes, this is missing in the present namespace proposal. which is reason to fix > it (given that it's still in flux), not reason to do something else. This argument proves too much. XSchemas mostly duplicate what DTDs do, so why create them at all? XSchemas, however, are made of general mechanisms and so provide the potential for extensibility, which DTDs -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jul 1 20:13:30 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) References: <199806301545.LAA28056@locke.ccil.org> Message-ID: <359A7CD1.74F90437@mecomnet.de> John Cowan wrote: > > james anderson scripsit: > > > and yes, this is an aspect of the namespace proposal (if not xml as a whole) > > which i believe is dented, if not broken: name qualification should apply to > > all values which either are tokens or denote tokens (ie the various attribute > > values and notations). othrwise the whole thing becomes unworkable. > > The fact is that the Namespace draft as it is (which is what we have > to work with) doesn't provide for parsers doing colon-ectomies on > attribute values. IMHO it shouldn't; there is no reason to think > a priori that an attribute value that happens to contain a colon > is necessarily a namespace-qualified name. If XML had retained > attributes of type NAME, there might have been some case for them, > but NMTOKENs are just too broad. hmm..., i agree, but for a different reason. in some respects, it's not broad enough. what happens, for example when/if xpointers come to pass. an xpointer library (that is, an "application") will need to identify elements and attributes on the basis of universal identifiers. that is, there are attribute value domains, other than names, components of which (eg "http://abcd.html|child(1,my:element)") will be interpreted in (or as if they were in) the dynamic scope of the prefix bindings. which means that, while the "decoder" cannot make this decision on a syntactic basis, it must realise a machanism which among other things, takes the encoding for an universal name and transforms it - whether based on syntactic rules or upon request - into an universal identifer. [one should changed to must :-] note please, that i use the term "decoder" here, since if i were to use "parser" i would mean something else than most people on the list would expect it to mean. > > [many "should"s deleted] > > > it's not messy, it's very simple. don't think strings. think symbols. it > > doesn't matter where they came from, or what prefix they had at the time they > > wre interned, just whether or not they're equal. once they've been parsed, you > > should only ever have too look at the prefix again if you should need to > > serialize. - that's why the parser needs to intern all values which can are, > > or which can denote, tokens. > > But just which attribute values are those? Lisp has syntax to distinguish > symbols from strings, but we have only inference: therefore, general > parsers must assume that attribute values are strings. as noted above, syntax would not be sufficient. in any case, a name encoded as a string must, at some point, become a universal identifier. it makes no sense to delay this operation, since, as a prefix binding is valid during the dynamic context of the document parse only, the intended result will never change. once the transformation has been performed it makes no sense to expose the internals of an identifier. which means anywhere outside of the en/decoding layer. which means that, by the time the "processing" part of an xschema processor gets its hands on the namespace element, all the symbols should already have been interned, the prefix attribute has no meaning and can be ignored, and the element's is strictly documentary. a declarative means to control this mechanism would be nice. i don't know what it would be. in particular, with regard to xpointers, i've taken to interning element attribute values during element initialization. which happens in the document's dynamic context and thereby permits one to intern constituent names with respect to the correct prefix bindings. it's not a general solution, since this is controlled in class declarations specific to the implementation language and i don't see how one would declare this in a dtd. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Wed Jul 1 20:19:19 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) Message-ID: >unless the purpose is to document the prefix, then the schema encoding should >take the form > > > > > > > The namespace (region) above is a total waste of time > > > > > > >otherwise, you're encoding things which you do not mean. Great. So now I get to do the namespace declaration three times? (Once with the PI, once with the XSC:Namespace just to document the ns, and once in the document itself?) Talk about redundancy! Forget it. This one's staying where it is, unless I hear from an angry crowd. And yes, you could document both the ns info and the prefix if you felt like it. 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 James.Anderson at mecomnet.de Wed Jul 1 20:34:58 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) References: Message-ID: <359A81D6.C60C8DC8@mecomnet.de> Simon St.Laurent wrote: > ... > Great. So now I get to do the namespace declaration three times? (Once with > the PI, once with the XSC:Namespace just to document the ns, and once in the > document itself?) Talk about redundancy! it's actually only the start. each time one wishes to bind a prefix to a region of a namespace, well, one is going to have to include a namespace pi. yes, that's once per document. don't look at me. don't even look at the wd's authors. it's inherent in the encoding problem. and yes, since a namespace pi does not permit docmentation, an element makes sense to perform that task. that's one extra. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 1 20:44:15 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema: root element In-Reply-To: <199806301633.MAA29907@locke.ccil.org> (message from John Cowan on Tue, 30 Jun 1998 12:33:38 -0400 (EDT)) Message-ID: <199807011842.OAA00654@ruby.ora.com> [John Cowan] > I propose: Root (Useful | NotUseful) "NotUseful". I would prefer Root (Useful | NotUseful) #IMPLIED Most DTDs have a number of useful potential roots and a number of not-so-useful ones. By providing a default value one way or the other, you force me to override it on a substantial portion of my elements. Another option is to just say that this is a suggested root: Root (Suggested) #IMPLIED For DocBook, for instance, there are many elements useful as roots, but I might only put Root="Suggested" on 's declaration. -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 SimonStL at classic.msn.com Wed Jul 1 20:56:58 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) Message-ID: >it's actually only the start. each time one wishes to bind a prefix to a >region of a namespace, well, one is going to have to include a namespace pi. >yes, that's once per document. don't look at me. don't even look at the wd's >authors. it's inherent in the encoding problem. >and yes, since a namespace pi does not permit docmentation, an element makes >sense to perform that task. that's one extra. And again, since the XSchema processor is already going to have to handle the task of expanding namespace references in the name attributes of ElementDecl elements, the PI is redundant and doesn't accomplish anything. The XSchema processor is in charge of that task. We could choose to use the less-accomplished PI instead of the XSC:Namespace element, but I see no benefits to doing that. If XSchema can do a better job for itself than the PI, I have no qualms about letting XSchema handle a task, as I had no qualms about doing a better job than DTDs currently can do. I think we're going in circles here, and no one else is joining in. If you want to include the extra PI, I don't think it'll do any damage. If anyone would like to join the discussion, I'd very much like to hear other opinions that might lead us out of this circle. 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 Jul 1 21:25:57 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema: root element Message-ID: Chris Maden wrote: >I would prefer > >Root (Useful | NotUseful) #IMPLIED > >Most DTDs have a number of useful potential roots and a number of >not-so-useful ones. By providing a default value one way or the >other, you force me to override it on a substantial portion of my >elements. How about a three-way option? Root (Recommended | Possible | Forbidden) "Possible" 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 James.Anderson at mecomnet.de Wed Jul 1 21:48:39 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) References: Message-ID: <359A9310.A29CE2AF@mecomnet.de> Simon St.Laurent wrote: > > And again, since the XSchema processor is already going to have to handle the > task of expanding namespace references in the name attributes of ElementDecl if "processors" have to do this then the (base) architecture is wrong. binding qualified names to universal identifiers is an "encoding/decoding" problem. it is not a "processing" problem. sorry to be so unequivocal here, but it is evident that i've yet to make the point clearly enough to get across. > elements, the PI is redundant and doesn't accomplish anything. The XSchema > processor is in charge of that task. We could choose to use the > less-accomplished PI instead of the XSC:Namespace element, but I see no > benefits to doing that. the suggested encoding as a XSC:Namespace is forcing the merging of two problem aspects (the notation for symbols - and - the documentation for the namespace regions) which belong separable. as you've said, i'm repeating myself too much, and without effect. i'll shut up about this 'till i figure out how to make it clear. bye for now, xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jul 2 04:23:35 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) In-Reply-To: <359A9310.A29CE2AF@mecomnet.de> from "james anderson" at Jul 1, 98 09:50:50 pm Message-ID: <199807010211.WAA18875@locke.ccil.org> james anderson scripsit: > as you've said, i'm repeating myself too much, and without effect. > i'll shut up about this 'till i figure out how to make it clear. You *are* clear. However, you want the namespace-aware parser to do something that namespace-aware parsers aren't contracted to do: decide what is, and what is not, an "ultimate" reference to a universal-name, and translate all such. The authors of the namespace draft are a proper subject of this complaint. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jul 2 10:57:02 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:35 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) In-Reply-To: <199807010211.WAA18875@locke.ccil.org> References: <359A9310.A29CE2AF@mecomnet.de> Message-ID: <3.0.1.16.19980702094639.2c1f2488@pop3.demon.co.uk> At 22:11 30/06/98 -2800, John Cowan wrote: >james anderson scripsit: > >> as you've said, i'm repeating myself too much, and without effect. >> i'll shut up about this 'till i figure out how to make it clear. > >You *are* clear. However, you want the namespace-aware parser to >do something that namespace-aware parsers aren't contracted to do: >decide what is, and what is not, an "ultimate" reference to a >universal-name, and translate all such. The authors of the namespace >draft are a proper subject of this complaint. > I sympathise with those trying to define how namespaces are used under XSchema and elsewhere. Any XML-SIG discussions are confidential, and I don't have a timescale for the next draft release. However I think it can be reasonably said: - there are many different views on what namespaces are and how valuable they are. - the current approach is deliberately minimalist The WhiteKnight question is always with is: - what is a namespace? - what is a namespace called? - what is the name of the namespace? - what is the name of the namespace called? This calls for great precision and agreement which I suspect we do not yet have. (It also arises in the PubID vs SysID question). I suspect there are two strategies: - accept it as a very difficult problem and not attempt to solve it. The community (market) will then come up with approaches which may or may not find ecological niches - accept it as a very difficult problem and propose a solution. Some of the community will accept this and some won't. I would suggest that we only address the mechanism whereby prefix is linked to ns. And that in a minimalist manner (i.e. providing Names for these beasties). *What* ns should refer to is beyond XML-DEV at present (though it may be a very appropriate forum in the future). FWIW I will adopt a very simple strategy for JUMBO. I will not use ns to do other than to give me a unique string, thus: The ns value is unique within the galaxy. I then resolve it with a JUMBO-specific PI: This will *implicitly* link any CML element to a class: links to jumbo.cml.MOLNode (JUMBO will have the convention that links to FOONode). These classes will be stored under the classpath (using the tools that you have all helpfully told me about recently). I will also store the CML XSchema in the same area. Whether XSchema need to give me a handle for this I don't know (I shan't use 'src'). *** This brings up the question of what the XSchema file is called ***. Do we name it after the 'root' element? Thus: - what is the XSchema for CML called (a) if there is a (b) if there isn't? - what mechanism might there be for locating the XSchema file? P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Jul 2 12:09:38 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:35 2004 Subject: verbose XSchema Spec Section 2.4, Draft 2 In-Reply-To: "Simon St.Laurent"'s message of "Thu, 25 Jun 98 23:26:25 UT" References: Message-ID: Simon> Simon St.Laurent => In article , Simon => wrote: Simon> The concern I have is that processing XSchemas now requires a Simon> lot of extra checking on the 'correctness' of the XSchema. Simon> Using the elements, convoluted though it was, allowed the use Simon> of a simple validation (okay, it's ironic) to make sure that Simon> the XSchema wasn't attempting to provide an odd combination of Simon> functionality. Simon> Simon> Does this extra overhead for checking XSchemas bother anyone? Simon> The goals said that XSchema would have a DTD, not that an XSchema Simon> that can validate against the DTD would be functionally correct. Simon> (Or some such weirdness.) So far we've been using the DTD to Simon> constrain the XSchema's possible content. This would be a change Simon> of philosophy in that regard. I like using the DTD as much as possible to constrain the XSchema. There is a small benefit, as you mention, for validation of complete XSchemas if most of the work can be done by the parser, but I think the real benefit comes when editing: a decent XML editor[*] can improve my productivity by reducing the number of mistakes I can make. It's much easier and faster to spot errors as one is editing, rather than have to invoke an external validator to find them. (In a similar way, I prefer editors to understand the syntax of programming languages, as I don't like having to wait for compilation too often.) [*] I only use psgml on Emacs; I assume this applies to editors in general, 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 mika.kekkonen at vtt.fi Thu Jul 2 12:11:28 1998 From: mika.kekkonen at vtt.fi (mika.kekkonen@vtt.fi) Date: Mon Jun 7 17:02:35 2004 Subject: msxml parser and parameter entities Message-ID: <3.0.32.19980702130943.00935940@vttmail.vtt.fi> I have problems with parameter entities and msxml parser. I have following example.xml file: KÄT and file example.dtd is %ISOlat1; My ISOlat1.ent is following file (only one line) Files example.xml, example.dtd and ISOlat1 are in same directory. I tried to run msxml class, which I got with parser: java msxml -d \example.xml and I got following error message Missing entity 'Auml'. What is problem? I suppose msxml parser can read parameter entities? I have tried msxml parser with other xml files without any problems. If I put Auml entity definition to the example.dtd, everything works fine, but I have to use parameter entities. Thanks for any ideas Mika xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Thu Jul 2 14:53:59 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema: Sample naming ballot Message-ID: <199807021249.OAA21907@berlin.dvs1.tu-darmstadt.de> > > 1) I will mail a ballot to the list on Friday, July 3 (is this a US holiday?), > > Technically, no; 4 July (Saturday) is the U.S. national day. > However, many people will be away from work (and email) for the entire > Friday-Sunday period, as many companies allow 3 July as an > effective holiday. OK. I'll post the ballot on Monday, then. -- 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 Jul 2 14:56:51 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:36 2004 Subject: Namespace questions Message-ID: <199807021246.OAA21851@berlin.dvs1.tu-darmstadt.de> 1) Can I have multiple prefixes in the same file that point to the same namespace? The namespace spec doesn't appear to prohibit this. 2) How do namespaces and XLinks work together? For example, suppose I link to the element in another file. a) If the element is prefixed (that is, it is really ) does my pointer need to know this? b) When I get the element back as a result of resolving the link, do I get or ? And if I get , do I also get a namespace PI telling me about the Bar prefix? -- 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 Thu Jul 2 14:58:09 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema: root element Message-ID: <3.0.32.19980701213751.00a36ff0@pop.intergate.bc.ca> At 12:33 PM 6/30/98 -0400, John Cowan wrote: >As I posted earlier today, I favor this idea, but I dislike this >syntax. Because of the #*$# interoperability restriction, we >should avoid using "True" and "False" for any attribute values. Why? It seems like this the canonical applicatoin that doesn't have to worry about the installed base of pre-1998 SGML software. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Jul 2 17:14:24 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:36 2004 Subject: Namespace questions In-Reply-To: <199807021246.OAA21851@berlin.dvs1.tu-darmstadt.de> (rbourret@dvs1.informatik.tu-darmstadt.de) Message-ID: <199807021512.LAA27692@ruby.ora.com> [Ron Bourret] > 1) Can I have multiple prefixes in the same file that point to the > same namespace? The namespace spec doesn't appear to prohibit this. I believe so, but the ramifications of this aren't clear. I don't want to touch this question, really. > 2) How do namespaces and XLinks work together? For example, suppose > I link to the element in another file. > > a) If the element is prefixed (that is, it is really > ) does my pointer need to know this? Yes. Your pointer points to something in a document *instance*, not to a class; so whether it's or or <_>, you just use the GI as given in that document instance. > b) When I get the element back as a result of resolving the > link, do I get or ? And if I get , do I > also get a namespace PI telling me about the Bar prefix? Possibly the hardest thing about XLink is that it *doesn't return anything*; you *don't get anything back*. The pointer points; it doesn't fetch. When you point to , what you have is a pointer to . That's it. Now, if you're writing a program based on top of a parser and an XLink processor, you should probably be able to ask the parser for some information about the thing that the pointer is pointing to, such as its namespace. But that's something *on top of* XLink, not part of it. -Chris -- http://www.oreilly.com/people/staff/crism/ +1.617.499.7487 90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Jul 2 18:02:17 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:36 2004 Subject: Namespace questions References: <199807021246.OAA21851@berlin.dvs1.tu-darmstadt.de> Message-ID: <359BAF8B.C4CA5069@mecomnet.de> i'm afraid i'm going to repeat myself, but ... Ron Bourret wrote: > > 1) Can I have multiple prefixes in the same file that point to the same > namespace? The namespace spec doesn't appear to prohibit this. from an implementer's point of view, "yes". different prefixes within the same file should be able to denote the same region in the namespace. since all uses of a prefix are in single physical entity are "lexically apparent" this shouldn't lead to problems. since the namespace pi's can contain literals only, why would one need to do it? > > 2) How do namespaces and XLinks work together? For example, suppose I link to > the element in another file. > > a) If the element is prefixed (that is, it is really ) does my > pointer need to know this? the short answer is: "yes". all name tokens (even those which don't appear so in serialized form) are effectively qualified. their internal representation needs to be as well, since in use the dynamic context from the encoding is no longer present. this is necessary in order that the proper namespace binding can be communicated to whatever process resolves the reference. your pointer may, however not have appeared with "Bar:Foo" identifiers prior to decoding since the "Bar" implies a binding which will be in effect when the resolving process decodes, not when your application decoded. neither the namespace nor the xpointer wd makes any statement on these matters. wrt the namespace wd: attribute values (of which xpointers are one kind) don't fall among the specified productions. wrt to the xpointer draft: it appears to have been conceived n.s.a. (that's name-space-agnostic) despite that, all of the productions which involve "Name" would appear make sense to modify for "QName"'s. which implies that a pointer should permit qualification. which implies a standard means should be available to en/decode elements of an xpointer which comprise names. this service should be offered by the en/decoding layer. until (read "if") it is possible to place type constraints on attributes your application will have to determine on its own in which cases it is appropriate to request this service. whether the serialized form of the xpointer contained "Bar:Foo" id's would depend on where it came from. if it was in the same document as the link's target resource, then the prefixes will likely agree (modulo the answer to your first question). if it's from somewhere else, the prefixes may differ. the "universal name" remains the same. when an xpointer is decoded or serialized, the dynamic element scope could carry over to attribute content when it comes to interning and serializing symbols - including those from xpointers. which would cause (some) serialized names in an xpointer to appear unqualified. that does not, however address the general case, as the identifier in the refering element may (likely) reside in a different namespace region than the target resource and its attributes. for that reason, in order to generate robust locators, the serialized form may well contain qualified names. more specifically, 1. the encoding layer has to be aware of the dynamic prefix bindings in effect at the point where an element is serialized and prefix all name tokens as appropriate - including attribute content where necesssary 2. an http request containing such a request will either need to include prefix bindings in the header or comprise an xml document. > > b) When I get the element back as a result of resolving the link, do I get > or ? And if I get , do I also get a namespace PI > telling me about the Bar prefix? where the reference is inter-document, in general you cannot require that you get a . you should well expect that the encoding may have contained a , in which case your decoder should also have gotten a and should be presenting you with the same symbol as "Bar:Foo" named when it was interned. this is, in any event, just a discussion of "appearances". if your encoding layer is proper, your application shouldn't be concerned with the "Bar" or the "Baz". but then, i'm repeating myself 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 rbourret at dvs1.informatik.tu-darmstadt.de Thu Jul 2 18:31:27 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema-to-DTD converter Message-ID: <199807021624.SAA23096@berlin.dvs1.tu-darmstadt.de> An early (read "barely tested") version of my XSchema-To-DTD converter is now available. This is a SAX application that takes events from an XSchema document and writes DTD declarations to a Java Writer. It does not currently support namespaces, nor is it updated for Simon's latest changes. It is available from: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xschema/xschematodtd.ht ml If anybody else is interested in writing XSchema software (especially parser stuff), there are some suggestions at: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xschema/xschema.html Send your bugs and comments to me at rbourret@dvs1.informatik.tu-darmstadt.de. -- 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 Jul 2 18:56:23 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:36 2004 Subject: Namespace questions In-Reply-To: <359BAF8B.C4CA5069@mecomnet.de> References: <199807021246.OAA21851@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980702173918.327719a8@pop3.demon.co.uk> Firstly, I think that there are a lot of questions about namespaces to which the answers are assumed but not written down in the spec. For some, I suspect that most people will make the same assumptions, but for others there may be differences of opinions. It has been agreed that the XLink and other specs will have to be updated to be namespace-aware. I think that until that is published we should assume we are on thin ice. At 18:04 02/07/98 +0200, james anderson wrote: >i'm afraid i'm going to repeat myself, but ... > >Ron Bourret wrote: >> >> 1) Can I have multiple prefixes in the same file that point to the same >> namespace? The namespace spec doesn't appear to prohibit this. > >from an implementer's point of view, "yes". different prefixes within the same >file should be able to denote the same region in the namespace. >since all uses of a prefix are in single physical entity are "lexically >apparent" this shouldn't lead to problems. >since the namespace pi's can contain literals only, why would one need to do it? I agree that this is allowed. A possible use for it is that a document is composed of contributions by more than one author who use different prefixes. Example: &doc1; &doc2; doc2 might contain ElementTypes of the form > >> >> 2) How do namespaces and XLinks work together? For example, suppose I link to >> the element in another file. >> >> a) If the element is prefixed (that is, it is really ) does my >> pointer need to know this? > >the short answer is: "yes". a slightly longer answer is "yes, but". If the characters "" appear in a file they cannot at present 'really be ""' (i.e. there is no scoping mechanism). I imagine that this was not what was intended in the question, but wanted to make sure. [...] > > >> >> b) When I get the element back as a result of resolving the link, do I get >> or ? And if I get , do I also get a namespace PI >> telling me about the Bar prefix? > This is a difficult area as it is (as ChrisM says) dependent on implementation. You don't 'get anything back' other than a pointer or an address (or a set of them). The spec for attr() [which at present returns a String] is misleading [thanks to Steve De Rose, private mail] and will be rewritten. If it returns anything it is to the address in (say) a grove which includes attributes 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 Jul 2 20:25:35 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) Message-ID: <199807021824.UAA23918@berlin.dvs1.tu-darmstadt.de> OK. I finally sat down and read this discussion from start to finish. I can safely say that my head hurts. In reading the following, please remember that my parser skills are at the duct tape (that's gaffer tape to you Brits) and baling wire level, so please be gentle with my (mis)use of terminology. Summary of the Current Situation ================================ 1) When we talk about resolving and encoding/decoding, we're talking about the part of the software that says, "Ooo. Let's see. This prefix matches with that, and those prefixes matches with these, and...add a bit of newt's wing... ah-hah! This is the Foo element in the Bar namespace!" This results in a token/unique identifier, which tells the rest of the software what to do (if token==ORDERPIZZA... else if token==DRINKCOKE... else if...) 2) Namespaces appear in three places in XSchema documents: a) Identifying XSchema elements (ElementDecl, AttDef, etc.) b) Identifying elements under the More element c) Identifying elements being described by the XSchema (qualified names occur in attributes of ElementDecl, AttDef, and Ref) 3) Currently, cases (a) and (b) use namespace PIs; case (c) uses a Namespace element. XSchema processors pay attention to case (b) only if they know about those elements. 4) The discussion is about whether to use Namespace elements or not. As far as I can tell, the main arguments are as follows: PRO: The Namespace element makes it easier to distinguish case (c). It adds documentation to namespaces. It follows the XSchema-uses-elements philosophy. CON: The namespace PI is the standard way of declaring namespaces. What is important to me is that, with the possible exception of documentation, none of these arguments state that something is possible with one method that is not possible with the other. My Two Cents ============ Here are my thoughts on the subject. 1) I'm currently implementing this code and find the difference between the two methods to be negligible. I get a slight efficiency with the Namespace element because I can distinguish between (b) and (c). Note that I am building a SAX application and the parser doesn't do anything for me namespace/resolution-wise. The call to startElement returns a prefix-qualified name that I must resolve. 2) If we keep the Namespace element, it is possible for an XSchema document to use the same prefix for two different namespaces -- once in either (a) or (b), and once in (c). My resolver needs to be aware of this. 3) I am not convinced that Namespace elements are going to work when we XLink XSchemas together. From james' mail, I gather that generic software for traversing XLinks will probably issue namespace PIs to the calling (XSchema) application. This enables the calling application's resolver to resolve any prefixes it receives. Generic XLink software would certainly not return Namespace elements. For XSchema, this means that the user must create separate XLinks to the relevant Namespace element(s) (yech), or the programmer must write XSchema-aware software for traversing XLinks (double-yech). If (3) is true, it is a convincing case (in my mind) for using PIs. If it is not true, and generic XLink resolvers somehow really do hand me back a token that is meaningful to me, then I'm happy for Simon to flip a coin, put his foot down, or anything else that makes him happy. I need an aspirin. -- 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 Jul 2 20:46:41 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) Message-ID: <199807021840.UAA23942@berlin.dvs1.tu-darmstadt.de> Peter Murray-Rust wrote: > I will also store the CML XSchema in the same area. Whether XSchema need to > give me a handle for this I don't know (I shan't use 'src'). *** This > brings up the question of what the XSchema file is called ***. Do we name > it after the 'root' element? Thus: > - what is the XSchema for CML called (a) if there is a > (b) if there isn't? > - what mechanism might there be for locating the XSchema file? You should be able to name the XSchema file whatever you want. The root shouldn't have anything to do with it. I believe the current candidate for referring to the file is through a PI in the referring document. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 2 20:46:47 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema: root element Message-ID: <199807021842.UAA23948@berlin.dvs1.tu-darmstadt.de> John Cowan wrote: > What does "valid" mean here? If it has its technical XML sense, thenn no, > the document instance will be valid staring from any root as long as > you mention that element in the DOCTYPE declaration. > > If you mean that some later-stage application will barf unless it sees a > specific root, then you may be right. I meant the barfing semantics. Valid was clearly a poor choice of words. -- 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 Thu Jul 2 20:56:47 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema: root element Message-ID: <199807021854.UAA23962@berlin.dvs1.tu-darmstadt.de> Chris Maden wrote: > I would prefer > > Root (Useful | NotUseful) #IMPLIED > > Most DTDs have a number of useful potential roots and a number of > not-so-useful ones. By providing a default value one way or the > other, you force me to override it on a substantial portion of my > elements. > > Another option is to just say that this is a suggested root: > > Root (Suggested) #IMPLIED > > For DocBook, for instance, there are many elements useful as roots, > but I might only put Root="Suggested" on 's declaration. I am leery of IMPLIED in this case. Authoring software must decide whether to show an element as a possible root. If a document doesn't state its preference, the authoring software will make its own decision. Thus, two editors might behave differently when given the same XSchema -- something I don't like. I think that Simon's (Recommended | Possible | Forbidden) probably does the best job here. That is, there is no technical reason most elements can't be used as roots; it's just not always a particularly useful thing. -- 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 James.Anderson at mecomnet.de Thu Jul 2 21:01:50 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:36 2004 Subject: Namespace questions References: <199807021246.OAA21851@berlin.dvs1.tu-darmstadt.de> <199807021947.MAA25051@dynamicdiagrams.com> Message-ID: <359BD9A3.B10E7722@mecomnet.de> David G. Durand wrote: > > In brief answer to your continuing comments on this issue, the > namespace spec currently does _not_ make the restrictions i believe mr. durand may have misunderstood the context of my remark on "effective qualification". (was it that passage?) while the notion of "effective qualification" may not appear in the wd, it applies nonetheless to the application domain in which the question was posed. > nor > have the implications that you would like. we disagree. you may not see the implications. i do. i understood the question to have been posed with respect to an application which is to operate on data of which the encoded form may contain qualified names, and where the prefixes may vary from document to document. such an application is going to require mechanisms of the kinds i describe in order to produce predictable results. there will be many such applications. i leave the implications open. > It allows applications > that _wish_ to, to disbamiguate names based on a prefix. It does i trust that the context of the discussion leaves no doubt, that that is the kind of application with which my remarks have been concerned. > not make _all_ names qualified, for which applications, even names which conform to "NCName"'s in their encoded form will need be comparable with those which are qualified. if one does not identify the region of the namespace which is implied by the lack of a prefix when decoding, the results are unpredicatable. > nor does it affect DTD or link > processing, or any other process that already uses GIs. i don't understand this. since both of these processes depend on name identity it's hard to see how a standard which specifies how names are encoded does not - at least in terms of the appearance of the data upon which they operate - affect them. one can't very well send a server an uri which contains an xpointer in its fragment identifier and then say "hey, now you figure out what the prefixes were supposed to mean. good luck." > The kinds of things you are advocating may be useful (and they may > not), but they are currently not on the table, because they have so > many implications for the rest of XML. which is unfortunate; and exactly why i discuss them. and please take my remarks as "reporting" rather than "advocating". i'm just recounting what i've had to do to fill out the standards to get things to work. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 2 21:03:46 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:36 2004 Subject: Linking XSchemas to documents Message-ID: Ron Bourret wrote: >I believe the current candidate for >referring to the file is through a PI in the referring document. Though I've already expressed my fondness for PI's, they seem like the only appropriate tool for making this connection. How's description would be completely optional, of course; I've just come to enjoy being able to give things intelligible descriptive comments and it's addictive. And if href sounds too much like XLink, we can change it. I'm sure lots of other people have ideas about what this PI should look like. The other question, of course, is how to link multiple XSchemas to a document, something that's weird enough in DTDs. Do people want to follow the DTD rules (no element declared more than once, etc.) for compatibility, or open that up as well? At this point, I'd opt for compatibility. 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 Thu Jul 2 21:13:01 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema 1.0 proposals, preparing the ground Message-ID: <199807021908.VAA23980@berlin.dvs1.tu-darmstadt.de> Simon St. Laurent wrote: > This [adding an ID attribute to all XSchema elements] hasn't been implemented; > discussion on it never really took off. It's a > fairly trivial piece to add. I worry that having both an ID and a name may > seem confusing, and may be unnecessary since you can refer to pieces through > XPointer by element type/attribute value and not just ID. > > If you think it's worth it, by all means, we can do it. Opinions? At the risk of sounding totally ignorant (which is only half true), it occurred to me that XLinks might cause problems here. Specifically, if I transclude part of one XSchema document into another, am I still guaranteed unique IDs? This is such a basic thing, that I hope XLink covers it, but I haven't dug far enough into that spec to find out. -- 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 Thu Jul 2 22:11:32 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:36 2004 Subject: Missing MSXML demo Message-ID: Does anyone know where the XML demo for IE 4.0 that used the tree interface and the Java parser went? It used to live at http://www.microsoft.com/standards/xml/xmlparse.htm#demos, but appears to have vaporized in the new improved (crashed Netscape 4.0 and Windows 95 all the way to blue screen of death) Microsoft XML area. All I can find is the auction. 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 peter at ursus.demon.co.uk Thu Jul 2 22:32:28 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema 1.0 proposals, preparing the ground In-Reply-To: <199807021908.VAA23980@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980702212936.3f971e52@pop3.demon.co.uk> At 21:08 02/07/98 +0200, Ron Bourret wrote: [...] > >At the risk of sounding totally ignorant (which is only half true), it occurred >to me that XLinks might cause problems here. Specifically, if I transclude part >of one XSchema document into another, am I still guaranteed unique IDs? This is >such a basic thing, that I hope XLink covers it, but I haven't dug far enough >into that spec to find out. > AFAIUI XLink does not provide transclusion in the sense that two documents are seamlessly fused together. XLink (even with AUTO and EMBED) is simply the watertight embedding of one object in another. They have no syntactic, semantic or other relation with each other. [If you want to use XLink for this I suspect you need to invent a value for BEHAVIOR.] In general terms I would commend the XSchem-ers not to try to map out all the possibilities that (a) namespaces (b) XLink offer. This is not because it's not a worthy effort, but I think that both specs are still in draft. My personal opinion is that when we start implementing either (or both) of these we are going to throw up some tricky problems - I may be too pessimistic here. In any case I think XLink will need to be redrafted to accommodate Namespaces... P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Thu Jul 2 22:46:45 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:36 2004 Subject: XSchema Spec, Section 3, Draft 2 (Namespaces) Message-ID: Here's another go, trying to make everyone happy and cover my butt for the multiple interpretations I can derive from the current draft. I took James Anderson's suggestion that both the PI and the element could be included as a reasonable way to cover all possibilities. While I don't think the PI is necessary, I can read that into the namespaces spec if I try hard enough. (I can read many possibilities into the spec. This is fun!) The main changes are the additional requirement of the PI, much more uncertainty in the language, and the requirement that PIs appear before any XSC:ElementDecl elements. That means I'll have to change Section 2.0 as well, coming soon. As always, the pretty version will be at http://www.purl.org/NET/XSchema/. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 3.0 XSchema and Namespaces XSchema uses namespaces for its own operations and also supports schemas that take advantage of namespace facilities. XSchema processors are responsible only for elements that use the XSchema namespace appropriate to the version of XSchema they are processing. (This namespace is identified with the prefix XSC: throughout this document; see 3.3 below for information about alternative prefiexes.) Information in other namespaces may be passed to other applications as the processor deems appropriate. Please note: the information in this section is based on the 18 May 1998 "Namespaces in XML" Working Draft and is will change to maintain conformance with that specification. Some features in this section are redundant, and required at present to make certain the XSchemas will have a high likelihood of working in whatever namespace environment develops. 3.1 The XSchema Namespace XSchemas created using XSchema 1.0 should include the following namespace declaration after the XML prolog but before the appearance of DTD information and the XSC:XSchema element. This namespace declaration identifies elements prefixed with XSC: as elements that should be processed by an XSchema processor and also identifies the version number of the XSchema specification used. This declaration is required. XSchema processors must always check for this declaration to properly recognize the prefix that will identify XSchema elements. 3.2 Interaction with Other Namespaces XSchemas will often support document sets that have their own namespaces. Because prefixes may change from document to document, and to provide the simplest possible solution, XSchema provides a mechanism for declaring namespaces within XSchemas. This allows documents and the XSchemas used to verify them to track the same namespace using different prefixes if necessary. The XSC:Namespace element and its contents are very similar to the processing instruction. The attributes of the XSC:Namespace element correspond to the prefix, ns, and src productions in the Namespaces Working Draft. The ns attribute for the namespace element is the most important part, containing a unique identifier that will be used to link the elements declared in an XSchema to their counterparts in the document. The ns attribute will contain a URI, typically a URL. (Note that #-separated identifiers are prohibited in the namespaces draft.) The src attribute can supplement the ns attribute if the unique identifier provided is not a URL but needs (perhaps) to be retrieved. The prefix attribute provides an identifier prefix that will be used throughout the XSchema to identify elements belonging to this particular namespace. The ns attribute contains the key value that will be used to map XSchema element declarations to elements instance appearing in documents. So long as the ns attributes underlying the (possibly different) prefixes used in the XSchema and the document are the same, the mapping should work correctly. If namespaces are used which have different ns names, the mapping will be broken and the processor should report errors. All XSC:Namespace elements within an XSchema must appear before the first XSC:ElementDecl element. For interoperability with some interpretations of the Namespaces specification, XSchema documents must also be prefixed with namespace processing instructions that reflect the information contained in their XSC:Namespace elements. It is unclear at this point what processing model parsers will use to resolve namespaces, at what point in processing that resolution should take place, and what components of an XML document will have namespace prefixes resolved by the parser. *** - Should namespace declarations in a parent XSC:XSchema element hold in XSC:XSchema subelements, or should they start over? 3.3 Note Regarding Namespace Usage Namespaces are still in development at this time, and as such are subject to dramatic change. This specification was written making several assumptions, which may or may not prove to be true as the Namespaces draft evolves: 1. The only part of a namespace declaration that genuinely identifies the namespace is the ns production. The src is for additional information, and the prefix only serves as a proxy for the full ns production. This has several implications, the simplest of which allows developers to create XSchemas using prefixes other than XSC by specifying a different prefix in the XSchema namespace declaration described in Section 3.1. 2. The URLs in a namespace declaration will not need to be retrieved. The XSchema namespace declaration uses a PURL (permanent URL) provided by the OCLC. (For details on PURLs, visit http://purl.org.) PURLs use redirection to maintain a permanent address for sites that may change address. While XSchema specification information may be stored at the location to which the PURL server redirects visitors, XSchema applications should not rely on any of that information being there. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 2 23:37:13 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:37 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) In-Reply-To: <3.0.1.16.19980702094639.2c1f2488@pop3.demon.co.uk> from "Peter Murray-Rust" at Jul 2, 98 09:46:39 am Message-ID: <199807012124.RAA11687@locke.ccil.org> Peter Murray-Rust scripsit: > FWIW I will adopt a very simple strategy for JUMBO. I will not use ns to do > other than to give me a unique string, thus: > > I think that it would be in the spirit of the namespace draft to make sure that the ns value is an absolute URL before treating it as a unique string. If it is a relative URL, it should be understood as relative to the document in which the namespace PI appears. (I think this goes beyond the draft's requirements, but only in an "obvious" way.) > The ns value is unique within the galaxy. I then resolve it with a > JUMBO-specific PI: > > > > This will *implicitly* link any CML element to a class: > > links to jumbo.cml.MOLNode Just the thing, say I. > - what is the XSchema for CML called (a) if there is a > (b) if there isn't? > - what mechanism might there be for locating the XSchema file? > Proposal: if the root element of a document has an XSC:HREF element (capitalization to be settled later), then its value is the XSchema to which the document claims conformance. -- John Cowan cowan@ccil.org e'osai ko sarji la lojban. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jul 3 01:23:23 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:37 2004 Subject: XSchema Spec, Section 3, Draft 2 (Namespaces) In-Reply-To: Message-ID: <3.0.1.16.19980703002319.3cbf752e@pop3.demon.co.uk> At 20:45 02/07/98 UT, Simon St.Laurent wrote: >Here's another go, trying to make everyone happy and cover my butt for the >multiple interpretations I can derive from the current draft. I took James >Anderson's suggestion that both the PI and the element could be included as a >reasonable way to cover all possibilities. While I don't think the PI is >necessary, I can read that into the namespaces spec if I try hard enough. (I >can read many possibilities into the spec. This is fun!) [... XSC namespace proposal snipped...] I think you have done an excellent job given that none of us know where XML-names is going to end up. 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 murata at apsdc.ksp.fujixerox.co.jp Fri Jul 3 05:39:10 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:37 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <359A437A.AD3BDB30@mecomnet.de> Message-ID: <199807030342.AA01578@murata.apsdc.ksp.fujixerox.co.jp> james anderson wrote: > text the uri is correct. > if one wishes to resolve a name in the dynamic context of a document or of an > element, the prefix, in addition to the uri, would be correct. > > although this (the prefix qualification), in any case, is not something an > application should have to do (therefore the concern for an opaque object, > which question still stands), it is something which a specification which is > part of an encoded document would need to express. within the document itself > it would be wrong ( i won't say 'dead wrong', but it would be more cumbersome) > to specify relations among symbols and or namespace regions according to uri, > particularly given that there are already prefix bindings in effect in that > dynamic context. which is where the prefixes come in. > > in global context, one shouldn't be worrying about qualification any more, the > tokens which the parser generates whould be globally unique. (the opaque > objects again...) I strongly disagree. The whole point of the namespace extension is to allow applications to tell which namespace a name belongs to. A qualified name is not an opaque object. Application programs should and will care the attached URI. On the other hand, prefixes should (ideally) be completely hidden from applications. 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 M.H.Kay at eng.icl.co.uk Fri Jul 3 10:59:42 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:37 2004 Subject: XSchema: root element Message-ID: <002601bda661$3afdec00$1e09e391@mhklaptop.bra01.icl.co.uk> >Most DTDs have a number of useful potential roots and a number of >not-so-useful ones I would certainly like to be able to declare in a DTD that certain elements are valid roots and others are not. Assuming there is technology to validate a document against an XSchema, it moves one more validity check out of my application and into the schema. In the DTDs I have written, very few of the element types (often just one) are valid roots, so my own choice of default would be INVALID. 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 mrc at allette.com.au Fri Jul 3 11:29:12 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:02:37 2004 Subject: XSchema: root element References: <002601bda661$3afdec00$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <359CA43C.8C817B6B@allette.com.au> Michael Kay wrote: > I would certainly like to be able to declare in a DTD that > certain elements are valid roots and others are not. > Assuming there is technology to validate a document against > an XSchema, it moves one more validity check out of my > application and into the schema. > > In the DTDs I have written, very few of the element types > (often just one) are valid roots, so my own choice of > default would be INVALID. Not me - conversion work of legacy data routinely involves pulling documents to pieces, working on a fragment (such as a table) then putting it all back together. A language such as OmniMark will allow you to find fragments without parsing the data around it - under those circumstances, what is proposed is unduly restrictive. -- 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 rbourret at dvs1.informatik.tu-darmstadt.de Fri Jul 3 13:27:06 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:37 2004 Subject: Namespace questions Message-ID: <199807031123.NAA26817@berlin.dvs1.tu-darmstadt.de> > Possibly the hardest thing about XLink is that it *doesn't return > anything*; you *don't get anything back*. The pointer points; it > doesn't fetch. When you point to , what you have is a > pointer to . That's it. Now, if you're writing a program > based on top of a parser and an XLink processor, you should probably > be able to ask the parser for some information about the thing that > the pointer is pointing to, such as its namespace. But that's > something *on top of* XLink, not part of it. I understand that XPointer is the language for constructing pointers and XLink is the language for constructing links. Just to make sure, an XLink processor is software that knows how to follow XLinks and give you something back. Presumably, it works in conjunction with an XPointer processor, which actually follows the link. Right? -- 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 Jul 3 13:57:31 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:37 2004 Subject: XSchema: root element Message-ID: <199807031147.NAA26963@berlin.dvs1.tu-darmstadt.de> Marcus Carr wrote: > Not me - conversion work of legacy data routinely involves pulling documents to > pieces, working on a fragment (such as a table) then putting it all back > together. A language such as OmniMark will allow you to find fragments without > parsing the data around it - under those circumstances, what is proposed is > unduly restrictive. I'm not sure I understand. We want to give an authoring tool/XSchema explorer/etc. a way to determine the roots of useful/possible documents. That is, it is a way for the XSchema designer to say, "If you start with any of these elements, the resulting documents can be interpreted by the nifty software I wrote to go with this XSchema." Simon's proposal (Recommended | Possible | Forbidden) identifies those elements that, when used as roots, result in documents that work with the associated software (Recommended), those elements that that result in useful documents (Possible), and those elements that for some reason (I'm not sure what) should never be used as a root. (Note also that this attribute does not say anything about whether an element should be included in a different XSchema. Presumably, all elements can be included in other XSchemas.) I don't understand what this has to do with working on the individual fragments of a document. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 3 15:04:20 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:37 2004 Subject: XSchema validity (was: root element) Message-ID: <002501bda683$61391760$1e09e391@mhklaptop.bra01.icl.co.uk> >I meant the barfing semantics. Valid was clearly a poor choice of words. This is going to get worse. Perhaps we should use: well-formed: as defined in XML 1.0 (loosely, matching tags etc) valid: as defined in XML 1.0 (loosely, conforms to its own DTD) conforms to XYZ: conforms to the rules of standard XYZ (e.g. XML-Namespace). This may of course be an application-oriented (anti-barfing) standard obeys ABC: conforms to the constraints specified in XSchema ABC These are predicates that can be applied to any XML document including, of course, an XSchema. For an XSchema [document] to be conformant to the XSchema standard if must be well-formed, it must be valid under the XSchema DTD, and it must meet additional constraints described in the text of the XSchema standard. An interesting question: is it an objective to allow all [reasonable] "conformance" rules for an application to be expressed as XSchema constraints? 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 James.Anderson at mecomnet.de Fri Jul 3 15:50:38 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:37 2004 Subject: Attributes with Intent (and namespaces) References: <199807030342.AA01578@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <359CE237.66DF942C@mecomnet.de> please bear with me; maybe we're getting to something here... MURATA Makoto wrote: > I strongly disagree. The whole point of the namespace extension is to > allow applications to tell which namespace a name belongs to. A qualified > name is not an opaque object. Application programs should and will care > the attached URI. why? so far, as i've understood namespaces (wrt xml): 1. the NSDef will bind an URI literal. beyond that the value is of unspecified form and content. 2. the prefix has a bearing on encoding and decoding only. 3. the universal name arises through the uniqueness of values in the relation (NSDef.SystemLiteral X QName.LocalPart) i presume everyone agrees up to here. ... now, to the reasons the value of the uri does not matter to an application: 4. the purpose of the mechanism "articulating" the namespace is to control the scope of declarations made about a name. this is, among other things, the schema-reuse goal in the wd. 5. the application's concern is that, given a universal name, it can determine the declarations or effect the declared behaviour. 6. to accomplish this, the application will depend on functions of the form (UniversalName) -> (Declaration + Behaviour) 7. there are no occasions when the application will need a function of the form (URI) -> (Declaration + Behaviour) 8. functions of the forms (URI X LocalPart) -> UniversalName or UniversalName -> (URI X LocalPart) or even (URI X UniversalName ) -> UniversalName are necessary for dom construction operations only. (yes, this is not a w^3 conform dom, and yes i advocate that the application use a dom) 9. functions of a form such as (URI X LocalPart) -> (Declaration + Behaviour) are unnecessary, since, at the application level, given a dom operation of the form (URI X LocalPart) -> UniversalName simply makes no sense. they whould be well constructing names which have no declarations. in order words, "the uri does not matter to the application". 10. where the intent is to establish a relation between two universal names, (see the forgoing discussion in this thread) there may be a need for functions in domains such as (URI X URI) -> ? or (UniversalName X UniversalName) -> ? but the effects of these (and here i again cross the line to advocacy) should be declared at the decoding level, just as with operations using functions (Prefix X URI) -> NSRegion which declare namespace regions, . given the exposition above, where do we diverge? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 3 18:00:52 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:37 2004 Subject: XSchema: root element Message-ID: I think what I'm going to aim for is something a little less harsh than INVALID or forbidden, something like (Recommended | Possible | Unlikely) Does that keep everyone's ducks in a row? Authoring software would tend to ignore the Unlikelys and emphasize the Recommendeds, while those writing XSchema processors wouldn't have to check "Forbidden" and kick out someone's unfortunate legacy document for committing sins against the designer's intent. I think this keeps us more in line with current practice, while providing enhanced (recommendation) functionality. 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 Jul 3 18:02:18 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:37 2004 Subject: XSchema validity (was: root element) Message-ID: Michael Kay writes: >>I meant the barfing semantics. Valid was clearly a poor >>choice of words. > >This is going to get worse. Perhaps we should use: > >well-formed: as defined in XML 1.0 (loosely, matching tags >etc) > >valid: as defined in XML 1.0 (loosely, conforms to its own >DTD) > >conforms to XYZ: conforms to the rules of standard XYZ (e.g. >XML-Namespace). This may of course be an >application-oriented (anti-barfing) standard > >obeys ABC: conforms to the constraints specified in XSchema >ABC This is a great start; as I revise the XSchema sections I'll try to make sure these terms are used _consistently_. >These are predicates that can be applied to any XML document >including, of course, an XSchema. For an XSchema [document] >to be conformant to the XSchema standard if must be >well-formed, it must be valid under the XSchema DTD, and it >must meet additional constraints described in the text of >the XSchema standard. Here I disagree. I don't want to conflate validation against a DTD with checking (verification? still fishing for a good word) against an XSchema. The process is similar, but not identical. I also need terms to describe the piece of software that checks a document against an XSchema. So far I've been fumbling with XSchema processor; Verifier or something else might be better. >An interesting question: is it an objective to allow all >[reasonable] "conformance" rules for an application to be >expressed as XSchema constraints? I'd like to think so; at least in part that's why there's that crazy XSC:More element for application designers to experiment with. 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 rabin at shore.net Fri Jul 3 19:48:49 1998 From: rabin at shore.net (Paul Rabin) Date: Mon Jun 7 17:02:37 2004 Subject: document types with XSchema Message-ID: Simon, What's the current proposal for associating an instance document with an external XSchema document that is to be used by a parser to validate that instance document? Is there a proposed element or processing instruction that the instance document should include, or is it expected that the XSchema document will be given to the parser separately (or else included within the instance document)? Thanks! Paul xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 3 20:20:14 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:37 2004 Subject: document types with XSchema Message-ID: Paul Rabin asked: >Is there a proposed element or processing instruction >that the instance document should include, or is it expected that the >XSchema document will be given to the parser separately (or else included >within the instance document)? Here's the current proposal; no one has yet commented on it. XSchemas may also be converted to DTDs, and then validation may proceed that way, or an application could always do its own thing. ------------------ description would be completely optional, of course; I've just come to enjoy being able to give things intelligible descriptive comments and it's addictive. And if href sounds too much like XLink, we can change it. I'm sure lots of other people have ideas about what this PI should look like. ------------------ 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 Fri Jul 3 20:37:31 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:37 2004 Subject: XSchema: root element In-Reply-To: <002601bda661$3afdec00$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <3.0.1.16.19980703141746.2f57ae2c@pop3.demon.co.uk> At 10:01 03/07/98 +0100, Michael Kay wrote: [...] > >In the DTDs I have written, very few of the element types >(often just one) are valid roots, so my own choice of >default would be INVALID. > In the DTDs I have written, almost all of the element types (often all) are valid roots, so my own choice of default would be VALID. :-) P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Fri Jul 3 21:38:44 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:38 2004 Subject: XSchema: root element Message-ID: cMichael Kay wrote: >In the DTDs I have written, very few of the element types >(often just one) are valid roots, so my own choice of >default would be INVALID. Peter Murray-Rust wrote: >In the DTDs I have written, almost all of the element types >(often all) are valid roots, so my own choice of >default would be VALID. :-) This situation is exactly why I think we need three choices, where Possible is the default. Hopefully, that'll keep us out of trouble. 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 Fri Jul 3 21:57:05 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:38 2004 Subject: XSchema: root element In-Reply-To: <199807031147.NAA26963@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980703194659.2a77daee@pop3.demon.co.uk> At 13:47 03/07/98 +0200, Ron Bourret wrote: >Marcus Carr wrote: > >> Not me - conversion work of legacy data routinely involves pulling documents >to >> pieces, working on a fragment (such as a table) then putting it all back >> together. A language such as OmniMark will allow you to find fragments without >> parsing the data around it - under those circumstances, what is proposed is >> unduly restrictive. > >I'm not sure I understand. We want to give an authoring tool/XSchema >explorer/etc. a way to determine the roots of useful/possible documents. That >is, it is a way for the XSchema designer to say, "If you start with any of these >elements, the resulting documents can be interpreted by the nifty software I >wrote to go with this XSchema." > Many of us will be authoring documents where the 'root' is almost meaningless. It is highly probable that many 'CML' documents will have a root element of . Example: ... ... ... ... The fact that this document uses H:HTML as its 'root' is virtually irrelevant to its semantic message. 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 eriblair at mediom.qc.ca Fri Jul 3 22:55:46 1998 From: eriblair at mediom.qc.ca (Eric Riblair) Date: Mon Jun 7 17:02:38 2004 Subject: msxml Message-ID: <199807032055.QAA02534@netra.mediom.qc.ca> Hi everybody ... To Whom it concern, I work presently with the applet msxml and many script ( ... in Java) and I have some problems ... to load these files in the Mac version of Internet Explorer ... and in Netscape 4 (... in all versions !!!). In that way I'd try to download the the XML parser for the other environment (ex: Mac) and I had the File Not Found ... answer .... Thanks for any help ... ?ric Riblair, Agronome e-mail: eriblair@mediom.qc.ca xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From egonw at sci.kun.nl Sat Jul 4 14:51:25 1998 From: egonw at sci.kun.nl (Egon Willighagen) Date: Mon Jun 7 17:02:38 2004 Subject: No subject Message-ID: <199807041251.OAA04786@wn1.sci.kun.nl> -- Egon Willighagen (egonw@sci.kun.nl) Kath. Univ. of Nijmegen Member of VVCN Sigma (http://www.sci.kun.nl/sigma) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Jul 5 00:55:18 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:02:38 2004 Subject: XSchema: root element References: <199807031147.NAA26963@berlin.dvs1.tu-darmstadt.de> Message-ID: <359EB29C.C558DCBA@allette.com.au> Ron Bourret wrote: > Marcus Carr wrote: > > > Not me - conversion work of legacy data routinely involves pulling documents > to > > pieces, working on a fragment (such as a table) then putting it all back > > together. > > I'm not sure I understand. We want to give an authoring tool/XSchema > explorer/etc. a way to determine the roots of useful/possible documents. It's the "etc", that I wonder about - it seems that the focus of XSchema is being narrowed to a point where some "etc" will not be able to make use of XSchema without violating the intent. The problem is that the intent may not have accounted for a slightly different processing model - might the same application require multiple XSchema for different tasks, or would you design them more loosely to reduce redundancy? This would seem to be a subjective call and a natural for protracted discussion. > I don't understand what this has to do with working on the individual fragments > of a document. It's not so much about working on fragments as it is ensuring that current, common data handling processes aren't locked out of using XSchema because we aren't looking around enough. The narrower the range of uses XSchema is appropriate for, the less chance of it succeeding. -- 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 mrc at allette.com.au Sun Jul 5 01:16:53 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:02:38 2004 Subject: XSchema: root element References: Message-ID: <359EB7B4.D19A88D0@allette.com.au> Simon St.Laurent wrote: > I think what I'm going to aim for is something a little less harsh than > INVALID or forbidden, something like > > (Recommended | Possible | Unlikely) > > Does that keep everyone's ducks in a row? Mine are quacking in synch - the only other thing that occurred to me was that specific uses of the data may require a different set of possible doctypes, though the management of an XSchema with some form of task-qualified attributes would be a nightmare to maintain. -- 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 donpark at quake.net Sun Jul 5 11:19:40 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:38 2004 Subject: Extensible Log Format (XLF) Initiative Message-ID: <000301bda7f4$dfe57e60$2ee044c6@arcot-main> Hello, I would like to put together a small and focused team of developers to work on the Extensible Log Format (XLF) specification. Once the spec is completed, we will encourage server companies as well as log analyzer companies to support the specification so that we will have a truely universal log format. I believe that the software industry in general will benefit greatly and immediately from this effort. The problem of log format based on XML is fairly interesting in its own right since it requires XML parsers with the ability to parse incrementally (logs are typically huge and practically never ending). Please contact me or reply to this e-mail if you are interested. Best wishes, Don Park CTO Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jul 6 00:49:37 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:38 2004 Subject: document types with XSchema In-Reply-To: from "Simon St.Laurent" at Jul 3, 98 06:19:56 pm Message-ID: <199807042238.SAA14167@locke.ccil.org> Simon St.Laurent scripsit: > Here's the current proposal; no one has yet commented on it. XSchemas may > also be converted to DTDs, and then validation may proceed that way, or an > application could always do its own thing. > ------------------ > > > description would be completely optional, of course; I've just come to enjoy > being able to give things intelligible descriptive comments and it's > addictive. And if href sounds too much like XLink, we can change it. I'm sure > > lots of other people have ideas about what this PI should look like. I think that while the PI obviously works, the attribute that I proposed should also be considered (XSC:href on the root element). -- 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 murata at apsdc.ksp.fujixerox.co.jp Mon Jul 6 04:41:14 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:38 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <359CE237.66DF942C@mecomnet.de> Message-ID: <199807060243.AA01594@murata.apsdc.ksp.fujixerox.co.jp> James, Thanks for providing details. I now have better understanding of your argument. james anderson wrote: > 6. to accomplish this, the application will depend on functions of the form > (UniversalName) -> (Declaration + Behaviour) I think we diverge here. To implement this *function*, application programs have to know URI's specified in the namespace declaration. In other words, developers of namespace-aware programs write: (XML Browser) "If I encounter an element of the MathML URI, I invoke techexplorer". (Search Engine) "I search for the first element of the DublinCore URI, and then examine the author and title described in its subordinate elements." Just in case you think that namespace declaration describes behavior: A namespace declaration does not describe behavior. (DTD's do not either, and probably schemas won't.) It only provides a URI. The rest is the task of application programmers. 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 dolphin at comeng.chungnam.ac.kr Mon Jul 6 04:42:35 1998 From: dolphin at comeng.chungnam.ac.kr (KangChan Lee) Date: Mon Jun 7 17:02:38 2004 Subject: [Announce] XML Editor - Clip Alpha version 1.0 Message-ID: <3.0.5.32.19980706114031.00a5fa20@flower.comeng.chungnam.ac.kr> Hi, I'm Kangchan Lee, a XML WG chair of WWW-KR in Korea. I am very happy to announce CLIP(XML Editor alphaversion 1.0) which is developed Techno 2000 Project, Inc. (T2000 is most active company on fields of XML in Korea and already announced XML validation server and Korean version of XML Spec and XML FAQ) The future of CLIP is here; - multiple platform : Win95 and Solaris - pure java programmed - enhanced user interface and preference - multile edit mode : Structure, Document, sub-Document, DTD - Power Search : Element, Structure, String, etc - validation check - etc You can freely download CLIP and URL is here - XML's Box : http://xml.t2000.co.kr/ - Product : http://xml.t2000.co.kr/product/ - CLIP : http://xml.t2000.co.kr/product/clip.html Give it a try. T2000 also have a plan to announce XML repository and management system (named XDMS) and seamless integrateion with CLIP and XDMS. Techno 2000 Project, Inc is the venture company and major field is XML, digital library, online-game, etc. T2000 is waiting for your comments, suggestions, and corrections. Sincerely yours, --- ------------------------------------------------------------------- KangChan Lee Database Lab, Dept. of Computer Engineering, ChungNam Nat'l Univ. 220 Goong-dong,Yusong-Gu, Taejeon, 305-764, South Korea Voice : +82-42-822-0523 FAX : +82-42-822-4997 E-mail : dolphin@comeng.chungnam.ac.kr, dolphin@www-kr.org URL : http://www.comeng.chungnam.ac.kr/~dolphin/ ------------------------------------------------------------------- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 6 04:56:55 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:38 2004 Subject: Status: Extensible Log Format (XLF) Initiative Message-ID: <00b501bda888$913d3c50$2ee044c6@arcot-main> At this point, there are 10 participants and I am expecting more to join the initiative on Monday and tapering off after that. Assuming everything goes well, we should have about 30 developers participating in various capacity on the spec by end of this week. We should have a mailing list setup by then as well. I would like everyone to understand that this effort will be a short and intense effort to establish the core XLF spec and then divided efforts to address DTD for individual log types starting with HTTP. In parallel, we will actively solicit support from server companies and log analyzer companies so that the new format will gain quick acceptance. I will post another status report by Tuesday so that everyone can be informed. Best wishes, Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Mon Jul 6 11:26:11 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:38 2004 Subject: XSchema: Naming ballot Message-ID: <199807060849.KAA07623@berlin.dvs1.tu-darmstadt.de> Following is the ballot for naming conventions in XSchema. Please fill it out and return it directly to me at: rbourret@dvs1.informatik.tu-darmstadt.de Voting closes when I arrive at work on Thursday morning, July 9 (around 9:00 am Central European Time). I will post results later that day. *****XSCHEMA BALLOT************XSCHEMA BALLOT************XSCHEMA BALLOT******* XSchema Naming Conventions ========================== XSchema will use the following naming conventions. Capitalization -------------- Check one: [ ] ALL CAPS [ ] Mixed Caps [ ] no caps Underscores: ------------ Check one: [ ] Use underscores to separate words (e.g. element_name) [ ] Do not use underscores to separate words (e.g. elementname) Element and Attribute Names: ---------------------------- Check one: [ ] XML 1.0 specification names (see attachment A) [ ] Simple names (see attachment B) Please mail this ballot to Ron Bourret rbourret@dvs1.informatik.tu-darmstadt.de NOTE: If more than one box is checked in a section, that section will be ignored; the votes in the remaining sections will still be counted. If anybody submits more than one ballot, only the last ballot entered will be counted. Attachment A: XML 1.0 Specification Names ----------------------------------------- The following element names match names of productions in the XML 1.0 specification whenever possible. These are the names currently used. Attribute names are shown in parentheses and attribute values are shown in quotes. Mixed case is shown. XSchema (Version ("1.0"), MimeType ("application/xml"), FileExtension ("xml")) ElementDecl (Name) Choice (Frequency ("Required", "Optional", "ZeroOrMore", "OneOrMore")) Seq (Frequency ("Required", "Optional", "ZeroOrMore", "OneOrMore")) Ref (Element, Frequency ("Required", "Optional", "ZeroOrMore", "OneOrMore")) Empty Any PCData Mixed (Frequency ("ZeroOrMore")) AttDef (Name) CData ID IDRef IDRefs Entity Entities Nmtoken Nmtokens NotationType NotationValue (Notation) EnumerationType EnumerationValue (Value) Required Implied Fixed (Value) AttValue (Value) Notation (Name) PubidLiteral (Pubid) SystemLiteral (href) Namespace (prefix, ns, src) Doc Attachment B: Simple Names -------------------------- The following element names are designed for simplicity. Attribute names are shown in parentheses and attribute values are shown in quotes. Mixed case is shown. XSchema (Version ("1.0"), MimeType ("application/xml"), FileExtension ("xml")) Element (Name) Choice (Frequency ("Required", "Optional", "ZeroOrMore", "OneOrMore")) Sequence (Frequency ("Required", "Optional", "ZeroOrMore", "OneOrMore")) Reference (Element, Frequency ("Required", "Optional", "ZeroOrMore", "OneOrMore")) Empty Any PCData Mixed (Frequency ("Required", "Optional", "ZeroOrMore", "OneOrMore")) Attribute (Name) CData ID IDReference IDReferences Entity Entities NameToken NameTokens NotationType NotationValue (Notation) EnumerationType EnumerationValue (Value) Required Optional Fixed (Default) Default (Default) Notation (Name) PublicID (PublicID) SystemID (SystemID) Namespace (Prefix, Name, Schema) 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 James.Anderson at mecomnet.de Mon Jul 6 12:30:06 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:38 2004 Subject: Attributes with Intent (and namespaces) References: <199807060243.AA01594@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <35A0A7B5.A2156D5E@mecomnet.de> let's take this a step further: MURATA Makoto wrote: > ... > i wrote: > > 6. to accomplish this, the application will depend on functions of the form > > (UniversalName) -> (Declaration + Behaviour) > > I think we diverge here. To implement this *function*, application programs > have to know URI's specified in the namespace declaration. In other words, > developers of namespace-aware programs write: > oops. i neglected an operator. please exclude the oversight. i was preoccupied with 'behaviour' in the sense of validation - which is declared via schema and thus adequately supported with the one operator. please allow me to extend '6' as follows 6. to accomplish this, the application will depend on functions of the form (UniversalName x Behaviour) -> (UniversalName) and (UniversalName) -> (Declaration + Behaviour) the application should not implement this mechanism. this is important. it is an operation which is so basic as to be integral with the dom. it's on the level with dereferencing a variable in c, or symbol-value and get in lisp. the application should not have to write a single line of code to make these functions work. (in order to do anything useful, the functions will be 'feature-qualified' - more like get than symbol-value, but that's a side point.) the distinction you note below is a distinction in behaviour. read 'behaviour' as 'function' or 'continuation'. the browser or search engine 'behaviour' is a computation which is named implicitly by the respective symbol or (symbol X property) > (XML Browser) > > "If I encounter an element of the MathML URI, I invoke techexplorer". > > (Search Engine) > > "I search for the first element of the DublinCore URI, and then examine > the author and title described in its subordinate elements." > i'll take the second example. please excuse my uncertainty wrt dublin core encoding, but i find only examples which do not propose an element hierarchy within the d-c space. in any case, i believe you will understand the point. if i paraphrase an example from the rdf m&s wd (WD-rdf-syntax-19980216) as follows, John Smith A Book Which John Wrote my application would do something like: (defNamespaceRegion "-//purl.org/metadata/dublin_core//Schema Dublin Core//en" :nicknames (list "dc")) (defNamespaceRegion "-//www.w3.org/TR/WD-rdf-syntax//Schema RDF//en" :nicknames (list "rdf")) and then either (defElementProcessor rdf:Description (element) (let-element-content (dc:Creator dc:Title) element (examine dc:Creator) (examine dc:Title))) or (dolist (element (xptr.find-elements (make-xpointer "root().descendant(all,rdf:Description)") *document*)) (let-element-content (dc:Creator dc:Title) element (examine dc:Creator) (examine dc:Title)) none of which requires that the symbols be examined. it is not even required that the application proper "know URI's specified in the namespace declaration" for a region with which it is concerned. in a case in which the application did not even know the exact name of the namespace region until the document was decoded, but wanted to do something for identifiers from all regions for which the URI matched a given pattern would be better handled by one of the suggested dom constructions functions than by munging namespace names within the application. for example 8. ... (URI X UniversalName ) -> UniversalName would enable the application to map symbols from a region of its choosing to any region necessary. for example, (defNamespaceRegion "rdf") (defParameter *dc-pointer* (make-xpointer "root().descendant(all,rdf:Description)")) (defParameter *my-rdf-names* '(rdf:Description)) (defMethod bind-namespace-region :after ((prefix string) (region namespace-region) &aux (ns (namespace-region.uri region))) (when (search "Schema RDF" ns :test #'char-equal) (import-universal-names *my-rdf-names* region))) > Just in case you think that namespace declaration describes behavior: > A namespace declaration does not describe behavior. (DTD's do not either, > and probably schemas won't.) It only provides a URI. The rest is the task > of application programmers. please note the remark on behaviour above. while namespace regions do not 'describe' behaviour, they do avail the application of unique names to which it can ascribe behaviour. inif the en/decoding layer constructs universal names as 'first class objects' and the dom provides means to manipulate them, the application writers are much better off. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From MWoody at mobilnet.gte.com Mon Jul 6 17:28:23 1998 From: MWoody at mobilnet.gte.com (Woody, Matt) Date: Mon Jun 7 17:02:38 2004 Subject: compliance with XML advancements Message-ID: <61492A178498D111897A00805F6F618768823B@sql-natlaccts.mobilnet.gte.com> Hello all. I musk ask that you excuse my concern if previously addressed. Much anticipated is the surge of DTDs that have been popping up based on the XML technology. The latest that I've been looking at are VML, SMIL. The current process of waiting for Netscape or IE to support the defined DTD with a new version after accepted by W3C has to be the largest stumbling block for XML. I think it to be important that any accepted DTDs should be available to users immediately. Has this raised a brow with Microsoft or with the Netscape development community at all? Are there any technologies that have taken this initiative? And if so, I should hope that the answer would not be another useless client concept. I feel that the community would benefit best if the browser were ignorant to the definition that it displays. Any thoughts? Matt Woody matt.woody@gte.com GTE Intranet Services xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 6 17:49:10 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:02:38 2004 Subject: compliance with XML advancements References: <61492A178498D111897A00805F6F618768823B@sql-natlaccts.mobilnet.gte.com> Message-ID: <35A0F991.680DB81A@finetuning.com> At the risk of giving the false impression that this is the proper forum for general questions of this nature (which I don't believe it is), I will answer your question, only because due to the last couple of stories I've written, and the number of people's opinions whom I have asked this exact question that have confirmed its answer, that i feel uniquely qualified to do so... :-) i am a proxy, if you will What it will be very important for BOTH Netscape and MS to do with their browsers is make sure that an architecture exists where the necessary mechanism to "plug in" (for lack of a better word) such components for the interpretation of such DTDs, whatever they may be. Let me say the same thing another way. In addition to the "built-in" xml parser (expat for mozilla) (the different flavors of msxml for ie -- two at this point i believe -- that will be "built-in" to ie5) -- in addition to it and/or them, there will have to be an extensible capacity "built-in" to each client so that these emerging xml-based languages can do their thing in the browser. Yes, to my knowledge, both MS and Netscape are aware of this. (or at least they are now :-) lisa rein Woody, Matt wrote: > > Hello all. > > I musk ask that you excuse my concern if previously addressed. > > Much anticipated is the surge of DTDs that have been popping up based on the > XML technology. The latest that I've been looking at are VML, SMIL. The > current process of waiting for Netscape or IE to support the defined DTD > with a new version after accepted by W3C has to be the largest stumbling > block for XML. I think it to be important that any accepted DTDs should be > available to users immediately. > > Has this raised a brow with Microsoft or with the Netscape development > community at all? > Are there any technologies that have taken this initiative? > > And if so, I should hope that the answer would not be another useless client > concept. I feel that the community would benefit best if the browser were > ignorant to the definition that it displays. > > Any thoughts? > > Matt Woody > matt.woody@gte.com > GTE Intranet Services > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe 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 crism at oreilly.com Mon Jul 6 19:05:07 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:38 2004 Subject: Namespace questions In-Reply-To: <199807031123.NAA26817@berlin.dvs1.tu-darmstadt.de> (rbourret@dvs1.informatik.tu-darmstadt.de) Message-ID: <199807061703.NAA27970@ruby.ora.com> [Ron Bourret] > I understand that XPointer is the language for constructing pointers > and XLink is the language for constructing links. Just to make > sure, an XLink processor is software that knows how to follow XLinks > and give you something back. Presumably, it works in conjunction > with an XPointer processor, which actually follows the link. Right? According to the XLink specification, a link merely asserts a relationship between two objects. Ideally, the behavior of the link should be left to the stylesheet. But since XLink will be done before XSL, it includes some basic behavioral attributes as suggestions to the application. HTH, 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 gkholman at CanadaMail.com Mon Jul 6 20:33:06 1998 From: gkholman at CanadaMail.com (G. Ken Holman) Date: Mon Jun 7 17:02:39 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <199807030342.AA01578@murata.apsdc.ksp.fujixerox.co.jp> References: <359A437A.AD3BDB30@mecomnet.de> Message-ID: At 98/07/03 12:42 +0900, MURATA Makoto wrote: >The whole point of the namespace extension is to >allow applications to tell which namespace a name belongs to. A qualified >name is not an opaque object. Application programs should and will care >the attached URI. On the other hand, prefixes should (ideally) be completely >hidden from applications. When I write my stylesheets, then, will I have to write the following? (a) namespace aware for element: In comparison to the following: (b) non-namespace aware for element: (c) architecture aware for element (either explicit or through DTD): ......... Ken -- G. Ken Holman mailto:gkholman@CanadaMail.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com Box 266, V: +1(613)489-0999 Kars, Ontario CANADA K0A-2E0 F: +1(613)489-0995 Training: http://www.CraneSoftwrights.com/schedule.htm Resources: http://www.CraneSoftwrights.com/resources/ Shareware: http://www.CraneSoftwrights.com/shareware/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From neilc at stanford.edu Mon Jul 6 21:14:04 1998 From: neilc at stanford.edu (Neil Crellin) Date: Mon Jun 7 17:02:39 2004 Subject: 2nd CFV: comp.text.xml Message-ID: <899752423.29823@isc.org> LAST CALL FOR VOTES (of 2) unmoderated group comp.text.xml This CFV is to be distributed only by the votetaker. It is not to be posted to newsgroups, or mailed to mailing lists or individuals, except by the votetaker. Ballots or CFVs provided by anyone else will be invalid. Newsgroups line: comp.text.xml The Extensible Markup Language (XML). Votes must be received by 23:59:59 UTC, 14 Jul 1998. This vote is being conducted by a neutral third party. Questions about the proposed group should be directed to the proponent. Proponent: James Tauber Votetaker: Neil Crellin RATIONALE: comp.text.xml XML is a new language, and it appears that it will be extremely popular. Over the past few months, traffic on the XML-DEV and XML-L mailing lists has grown rapidly. With the release of the W3C Recommendation for XML 1.0, developer interest is growing rapidly and an increasing amount of software is being released. A newsgroup would make it much easier for a wider audience to participate in and benefit from these discussions. While it may appear at first that comp.text.sgml is appropriate, there will be those interested in XML who do not care about the arcana of SGML, and there will be those interested in SGML who do not care to see many basic questions about XML. CHARTER: comp.text.xml Comp.text.xml shall be an unmoderated newsgroup for the general discussion of the Extensible Markup Language (XML) and its application. This includes, but is not limited to the specifications and syntax, document creation and editing, interchange, software, processing and database integration. This applies not only to XML itself but also the Extensible Linking Language (XLL), the Extensible Style Language (XSL), Cascading Style Sheets (CSS) as applied to XML documents, and to document types and applications of XML. Policy on Advertising We encourage discussion of the merits and shortcomings of commercial products. A certain amount of advertising (both objective and advocative) is to be expected and this is to be encouraged as long as the products and services relate directly to XML and the announcements are brief. Company representatives are expected to participate in discussions of their product that they themselves did not initiate. Please refer to the widely available Internet literature on the subject of common net abuses (indiscriminate newsgroup spamming, multiple advertisement posting, and chain letters being among the most frequent). END CHARTER. IMPORTANT VOTING PROCEDURE NOTES: READ THIS BEFORE VOTING The purpose of a Usenet vote is to determine the genuine interest in reading the proposed newsgroup, and soliciting votes from uninterested parties defeats this purpose. Do *not* distribute this CFV; intead, direct people to the official CFV as posted to news.announce.newgroups. Distributing specific voting instructions or pre-marked copies of this CFV is considered vote fraud. This is a public vote: All email addresses, names and votes will be listed in the final RESULT post. The name used may be either a real name or an established Usenet handle. At most one vote is allowed per person or per account. Duplicate votes will be resolved in favor of the most recent valid vote. Voters must mail their ballots directly to the votetaker. Anonymous, forwarded, or proxy votes are not valid, nor are votes mailed from WWW/HTML/CGI forms (which should not exist). Votes from nonexistent accounts are also invalid, and the votetaker will reject any "munged" address he cannot decipher immediately. Please direct any questions to the votetaker at . HOW TO VOTE: Extract the ballot from the CFV by deleting everything before and after the "BEGINNING OF BALLOT" and "END OF BALLOT" lines. Don't worry about the spacing of the columns or any quote characters (">") that your reply inserts. Please, DO NOT send the entire CFV back to me! Fill in the ballot as shown below. Please provide your REAL NAME and indicate your desired vote in the appropriate locations inside the ballot. Examples of how to properly indicate your vote: [ YES ] example.yes.vote [ NO ] example.no.vote [ ABSTAIN ] example.abstention [ CANCEL ] example.cancellation DO NOT modify, alter or delete any information in this ballot! If you do, the voting software will probably reject your ballot. When finished, MAIL the ballot to: < voting@uvv.stanford.edu > Just "replying" to this message should work, but check the "To:" line. If you do not receive an acknowledgment of your vote within three days contact the votetaker about the problem. You are responsible for reading your ack and making sure your vote is registered correctly. If these instructions are unclear, please consult the Introduction to Usenet Voting or the Usenet Voting FAQ at http://www.stanford.edu/~neilc/uvv. ======== BEGINNING OF BALLOT: Delete everything before this line ======= .----------------------------------------------------------------------- | 2ND CALL FOR VOTES: comp.text.xml | Official Usenet Voting Ballot (Do not remove this line!) |----------------------------------------------------------------------- | Please provide your real name, or your vote may be rejected. Place | ONLY your name (ie. do NOT include your e-mail address or any other | information; ONLY your name) after the colon on the following line: Voter name: | Insert YES, NO, ABSTAIN, or CANCEL inside the brackets for each | newsgroup listed below (do not delete the newsgroup name): Your Vote Newsgroup --------- ----------------------------------------------------------- [ ] comp.text.xml ======== END OF BALLOT: Delete everything after this line ============== DISTRIBUTION: In addition to the groups named in the Newsgroups: header, the CFV and the eventual RESULT posts will be mailed to these mailing lists: Mailing list name: xml-dev Submission address: xml-dev@ic.ac.uk Request address: majordomo@ic.ac.uk (body: subscribe xml-dev email) Mailing list name: XML-L Submission address: XML-L@LISTSERV.HEANET.IE Request address: LISTSERV@LISTSERV.HEA.IE (body: SUBSCRIBE XML-L First Last) Mailing list name: xsl-list Submission address: xsl-list@mulberrytech.com Request address: Majordomo@mulberrytech.com (body: subscribe xsl-list) comp.text.xml Bounce List - Please contact me about your vote ------------------------------------------------------------------------------- DuCharmR@moodys.com Bob DuCharme ginigma@REMOVE_ultracom.net c gold John.Lamp@diespam.deakin.edu.au John Lamp richard@lineone.net Richard O'BEIRNE This CFV was created with uvpq 1.0 (Aug 14 1997). PQ datestamp: 980322 -- Voting address: voting@uvv.stanford.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 6 22:53:11 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:39 2004 Subject: XSchema Spec, Section 2.2 (Element Declarations), Draft 3 Message-ID: Following is the latest draft of the Element Declarations section. It has been updates to include id attributes (coming soon to _all_ XSchema elements) and the root attribute, which provides suggestions to authoring tools about the reasonable use of elements as roots. It also adds the XSC:More element to Element declarations, providing an area for extensibility beyond the scope of XSchema. Please remember to vote on Ron Bourret's ballot regarding naming! All suggestions are extremely welcome. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.2 Element Declarations Element declarations in XSchemas are made using the XSC:ElementDecl element and its contents: The XSC:name attribute identifies the name of the element, and is required. An element declaration would look like: ...additionalElementInformation... This declaration would declare an element named "Species", which would appear in an instance as: ...content... The XSC:name attribute must be unique within the set of elements, as it provides the name of the element as declared here, and is also used by other elements to refer to this element in their content model declarations. The XSC:id attribute must be unique within the document. This attribute may be used to uniquely identify this XSC:ElementDecl element for reference by XPointers and other tools. The XSC:root attribute provides authoring tools with a guide for which elements are likely root elements for documents. This is intended to simplify the choices presented to authors during document composition. Note that an element must declare a content model, even if that content model is empty. Documentation (in the XSC:Doc element), non-XSchema extensions (in the XSC:More element) and attribute declarations (using XSC:AttDef elements) are optional. Documentation about the element, additional extensions, 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. Additional extensions are covered in 2.6.2, Further 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 gt9919a at prism.gatech.edu Mon Jul 6 23:06:11 1998 From: gt9919a at prism.gatech.edu (Per Roger Johannessen) Date: Mon Jun 7 17:02:39 2004 Subject: Tags vs PCDATA In-Reply-To: <3.0.5.32.19980706114031.00a5fa20@flower.comeng.chungnam.ac.kr> Message-ID: Hi, Which way is the best way to query a database, with tags or PCDATA? See below for examples. Is any of the two alternatives below considered "bad style"? Does it really matter? PCDATA-type: Name with the response: Foo Tag-type: with the same response as above. As I see it, the tag type has the advantage that it is the same tag (eg. ) in the query as in the answer. You can limit the queries to the same tags allowed for the answers in a DTD. On the other hand it takes a bit more effort to find what you query for. Best regards, Per Johannessen Per Roger Johannessen Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gt9919a@prism.gatech.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 eriblair at mediom.qc.ca Tue Jul 7 00:39:47 1998 From: eriblair at mediom.qc.ca (Eric Riblair) Date: Mon Jun 7 17:02:39 2004 Subject: MSXML Message-ID: <199807062239.SAA05213@netra.mediom.qc.ca> Hi everybody ... To Whom it concern, I work presently with the applet msxml and many script ( ... in Java) and I have some problems ... to load these files in the Mac version of Internet Explorer ... and in Netscape 4 (... in all versions !!!). In that way I'd try to download the the XML parser for the other environment (ex: Mac) and I had the File Not Found ... answer .... Thanks for any help ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Tue Jul 7 00:57:47 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:02:39 2004 Subject: Tags vs PCDATA Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA545@red-msg-08.dns.microsoft.com> You might be interested in checking out what Web-DAV has to offer in this area. I'm not very familiar with Web-DAV, but I think it addresses this sort of thing. -----Original Message----- From: Per Roger Johannessen [mailto:gt9919a@prism.gatech.edu] Sent: Monday, July 06, 1998 2:06 PM To: xml-dev@ic.ac.uk Subject: Tags vs PCDATA Hi, Which way is the best way to query a database, with tags or PCDATA? See below for examples. Is any of the two alternatives below considered "bad style"? Does it really matter? PCDATA-type: Name with the response: Foo Tag-type: with the same response as above. As I see it, the tag type has the advantage that it is the same tag (eg. ) in the query as in the answer. You can limit the queries to the same tags allowed for the answers in a DTD. On the other hand it takes a bit more effort to find what you query for. Best regards, Per Johannessen Per Roger Johannessen Georgia Institute of Technology, Atlanta Georgia, 30332 Email: gt9919a@prism.gatech.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) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Tue Jul 7 01:25:17 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:02:39 2004 Subject: Tags vs PCDATA Message-ID: <01bda935$00832f00$85acdccf@bckman.ix.netcom.com> Hi, a full review of this question can be found at http://www.sil.org/sgml/elementsAndAttrs.html It appears that there is no correct answer, except if you use an attribute, then the data will not be visible to the reader when the tags are stripped off. Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com -----Original Message----- From: Per Roger Johannessen To: xml-dev@ic.ac.uk Date: Monday, July 06, 1998 5:07 PM Subject: Tags vs PCDATA >Hi, >Which way is the best way to query a database, with tags or PCDATA? See >below for examples. >Is any of the two alternatives below considered "bad style"? >Does it really matter? > >PCDATA-type: > > Name > > >with the response: > > > Foo > > > > >Tag-type: > > > > > > >with the same response as above. > >As I see it, the tag type has the advantage that it is the same tag >(eg. ) in the query as in the answer. You can limit the queries to >the same tags allowed for the answers in a DTD. On the other hand it takes >a bit more effort to find what you query for. > >Best regards, > Per Johannessen > >Per Roger Johannessen >Georgia Institute of Technology, Atlanta Georgia, 30332 >Email: gt9919a@prism.gatech.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) > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jul 7 03:35:56 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:39 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <62395212@toto.iv> Message-ID: <199807070134.VAA00298@unready.megginson.com> G. Ken Holman writes: > When I write my stylesheets, then, will I have to write the following? > > (a) namespace aware for element: > > > > space-before='10pt'> > > > No -- or at least, I imagine not. There are two more interesting solutions: 1. Use something similar to DSSSL modes, one for each namespace: [...] [...] 2. Associate a separate stylesheet with each namespace, through some mechanism yet to be determined. 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 adam at cyber-guru.com Tue Jul 7 03:42:50 1998 From: adam at cyber-guru.com (Adam M. Donahue) Date: Mon Jun 7 17:02:39 2004 Subject: Action Sheets Message-ID: <199807070142.VAA04791@wwwultra.sce.nyu.edu> Did anyone else notice the note on Action Sheets at W3.org? I haven't yet read it through, but it's a Netscape proposal, so I guess it's likely to be implemented in the company's products. Take a look: Action Sheets: A Modular Way of Defining Behavior for XML and HTML http://www.w3.org/TR/NOTE-AS 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 stevew at access.com.au Tue Jul 7 03:55:31 1998 From: stevew at access.com.au (Steve Withall) Date: Mon Jun 7 17:02:39 2004 Subject: Tags vs PCDATA Message-ID: <3.0.32.19980707115624.00f49290@pop.access.com.au> ... and, if you use attributes, you can't get at them in XSL without resorting to a script. Having decided I wanted to use attributes to hold values retrieved from a database, I had to resort to writing a utility to convert attributes into child elements in order to make them accessible via XSL. I guess this is a practical argument in favour of using elements for database values, but I'd also like to make a plea to the formulators of the XSL standard to provide a convenient way to access attributes. Cheers, Steve. At 19:22 6/7/98 -0400, Frank Boumphrey wrote: >Hi, >a full review of this question can be found at > >http://www.sil.org/sgml/elementsAndAttrs.html > >It appears that there is no correct answer, except if you use an attribute, >then the data will not be visible to the reader when the tags are stripped >off. > >Frank > >Frank Boumphrey >XML and style sheet info at Http://www.hypermedic.com/style/index.htm >Author: - Professional Style Sheets for HTML and XML http://www.wrox.com >-----Original Message----- >From: Per Roger Johannessen >To: xml-dev@ic.ac.uk >Date: Monday, July 06, 1998 5:07 PM >Subject: Tags vs PCDATA > > >>Hi, >>Which way is the best way to query a database, with tags or PCDATA? See >>below for examples. >>Is any of the two alternatives below considered "bad style"? >>Does it really matter? >> >>PCDATA-type: >> >> Name >> >> >>with the response: >> >> >> Foo >> >> >> >> >>Tag-type: >> >> >> >> >> >> >>with the same response as above. >> >>As I see it, the tag type has the advantage that it is the same tag >>(eg. ) in the query as in the answer. You can limit the queries to >>the same tags allowed for the answers in a DTD. On the other hand it takes >>a bit more effort to find what you query for. >> >>Best regards, >> Per Johannessen >> >>Per Roger Johannessen >>Georgia Institute of Technology, Atlanta Georgia, 30332 >>Email: gt9919a@prism.gatech.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) >> >> > > > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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 murata at apsdc.ksp.fujixerox.co.jp Tue Jul 7 04:08:34 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:39 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: Message-ID: <199807070211.AA01610@murata.apsdc.ksp.fujixerox.co.jp> G. Ken Holman wrote: > When I write my stylesheets, then, will I have to write the following? > > (a) namespace aware for element: > > > > space-before='10pt'> > > > Since I am not a member of the XSL working group, I have not seen the working draft of DSSSL. But I believe that this is basically the right way to go. We probably need some syntax sugar. I would like to introduce some constructs such as this: I might even want to reference to an external stylesheet. For example: By doing so, many stylesheets can reuse a set of rules designed for a single namespace. I think that this is in the spirit of the namespace extension. (I have to admit that tables are harder if columns and text elements belong to different namespaces.) Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Jul 7 09:53:06 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:39 2004 Subject: XSchema Spec, Section 2.2 (Element Declarations), Draft 3 Message-ID: <199807070736.JAA17434@berlin.dvs1.tu-darmstadt.de> > | XSC:Empty | XSC:Any | XSC:PCData | XSC:Mixed), XSC:AttDef*)> > > name NMTOKEN #REQUIRED > id ID #IMPLIED > root (Recommended | Possible | Unlikely) "Possible"> Two nits: 1) The More element should be optional (needs a "?"). 2) Why is id optional? Is this to allow people to decide for themselves if they want to be reused? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 7 15:14:10 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:39 2004 Subject: XSchema Spec, Section 2.2 (Element Declarations), Draft 3 Message-ID: >Two nits: > >1) The More element should be optional (needs a "?"). Totally correct. Will be fixed quickly. >2) Why is id optional? Is this to allow people to decide for themselves >if they want to be reused? I have a few problems with requiring id. First, I'm still one of those terrible hand-coders. Being required to come up with an ID for every piece is a hassle, especially for bits I'll never reuse. This is not, of course, an issue for the authoring tools that will someday (hopefully) take over the landscape. Second, I know I can grab the same info with an XPointer without needing to go to an ID. It may not be as quick, and the final syntax may be a little murky, but I'm sure the functionality will be there. I think id should be there - it makes life much easier for authoring and management programs. I don't see a compelling reason to require it, given the improvements in linking that XPointer makes possible. There may, of course, be such a need that I haven't found yet. 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 paul at arbortext.com Tue Jul 7 16:03:31 1998 From: paul at arbortext.com (Paul Grosso) Date: Mon Jun 7 17:02:39 2004 Subject: Tags vs PCDATA Message-ID: <98Jul7.095953edt.26883@thicket.arbortext.com> At 21:56 1998 07 06 -0400, Steve Withall wrote: >... and, if you use attributes, you can't get at them in XSL without >resorting to a script. Having decided I wanted to use attributes to hold >values retrieved from a database, I had to resort to writing a utility to >convert attributes into child elements in order to make them accessible via XSL. >I guess this is a practical argument in favour of using elements for >database values, but I'd also like to make a plea to the formulators of the >XSL standard to provide a convenient way to access attributes. XSL will have a non-script way to access attribute values. We are working toward having a first draft ready within several weeks. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jim.blackwell at gsfc.nasa.gov Tue Jul 7 16:52:00 1998 From: jim.blackwell at gsfc.nasa.gov (James H. Blackwell Jr.) Date: Mon Jun 7 17:02:40 2004 Subject: Simple explanation of difference between XLink and XPointer ? Message-ID: <35A23605.E9EAACDE@gsfc.nasa.gov> Hi all, Can anyone out there give me a simple explanation of the differences between XLink and XPointer ? Also, how do they relate to XML-LINK ? The only difference I've seen so far between the two (XLink and XPointer) is that XPointer seems to deal with intra-document links (like in HTML) whereas XLink deals with inter-document (like HTML concept of hyperlinks). Also, what exactly is meant by a multidirectional link. Examples of these would be helpful. I've read all the W3C docs and several other XML publications and still cannot come up with some concrete examples/scenarios to describe these terms adequately. Jim Blackwell xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 7 18:49:05 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:40 2004 Subject: Simple explanation of difference between XLink and XPointer ? In-Reply-To: <35A23605.E9EAACDE@gsfc.nasa.gov> Message-ID: <3.0.1.16.19980707171836.402f48dc@pop3.demon.co.uk> At 10:51 07/07/98 -0400, James H. Blackwell Jr. wrote: >Hi all, > >Can anyone out there give me a simple explanation of the differences >between XLink and XPointer ? Also, how do they relate to XML-LINK ? XML-LINK (aka XLL) was a first draft which incorporated BOTH the XPointer and XLink drafts. The terminology is still in flux (I believe, for example, that 'xml:link' may not yet be stable). I suggest you use terms with care and allow for other people's use of obsolescent terms. > >The only difference I've seen so far between the two (XLink and >XPointer) is that XPointer seems to deal with intra-document links (like > in HTML) whereas XLink deals with inter-document (like >HTML concept of hyperlinks). No. XPointer is the addressing mechanism for *any* links using XLink. XLink describes the abstract structure of the links. Thus an Extended link could have locators which use any of the forms allowed by XPointer. > >Also, what exactly is meant by a multidirectional link. Eliot Kimber wrote a very good article on XML-DEV about a year ago. You'll find it under 'Kimber' or look in XML-Jewels (apologies for lack of recent maintenance). > >Examples of these would be helpful. I've read all the W3C docs and >several other XML publications and still cannot come up with some >concrete examples/scenarios to describe these terms adequately. I think XML-DEV has a real opportunity to help here. At the moment I think we are all waiting till the paint is dry. I'm tentatively hacking XPointer and some of XLink into JUMBO2 and I expect others are doing the same with their tools. Note that XLink is potentially far more powerful than simple HTML-like links. We can describe many abstract data structures using it. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Jon.Bosak at eng.Sun.COM Tue Jul 7 19:04:40 1998 From: Jon.Bosak at eng.Sun.COM (Jon Bosak) Date: Mon Jun 7 17:02:40 2004 Subject: Call for presentations: XML Developers' Conference 1998.08.20-21 Message-ID: <199807071701.KAA10439@boethius.eng.sun.com> CALL FOR PRESENTATIONS: XML DEVELOPERS' CONFERENCE 1998.08.20-21 A two-day technical conference for XML, XSL, and XLL developers will be held Thursday and Friday, August 20 and 21, in Montreal, Canada. Cosponsored by the Graphic Communications Association (GCA) and the Organization for the Advancement of Structured Information Standards (OASIS), the Developers' Conference will immediately follow the GCA Metastructures 1998 Conference in the same location, Le Centre Sheraton in Montreal. See http://www.gca.org/conf/meta98/ for registration and other conference details. The XML Developers' Conference extends the highly successful series of "XML Developers' Days" that began in Montreal last year in conjunction with the GCA HyTime Conference and was repeated in Seattle this March in conjunction with the GCA XML Conference. In response to the overwhelming number of submissions at the March event and the requests of previous attendees, the conference has been expanded from one day to two to allow for more presentations, and the time allotted for each speaker has been extended from 30 minutes to 45 minutes to allow for more questions. Like the previous events, however, this UnConference(tm) resists the bigger-is-better trend of recent years and maintains the concept of a single-track event featuring just the very best presentations from the cream of XML geekdom. In other words, this is a conference by developers, for developers. Expect really interesting presentations on fairly deep subjects in a locale noted for its French-Canadian culture, great food, and low prices. If you come wearing a suit we won't actually turn you away, but we don't need your business so badly that we're willing to lower the level of discourse. CALL FOR PRESENTATIONS If you are engaged in the construction of any software that works with XML -- converters, parsers, servers, browsers, editors, or XML-based vertical applications -- here is your chance to share your work with an audience that can understand and appreciate it. Since hypertext linking and stylesheet-based rendering are part of the larger XML picture, developers of tools that support XLL, XSL, or DSSSL are invited to show their latest offerings as well. While not primarily oriented toward industry-specific XML-based markup languages (CML, OFX, etc.), the conference is open to a certain number of presentations on specific languages and applications whose features are of special interest to developers and on related efforts such as RDF and XML-Data that may have a significant impact on the future of XML. Vendors of commercial tools can participate, but the presentations must be confined to the technical aspects of X*L products currently in development. Table space will be made available for the distribution of product announcements and commercial literature. Note that presenters get into the conference free. RULES FOR SUBMISSIONS No formal papers in advance at the UnConference(tm)! As in the previous two events, we want the very latest reports on work in progress. So instead of asking months ahead of time for stale papers submitted in someone's word processing format, we're asking right now -- a mere six weeks before the conference -- for just a few long paragraphs (300-500 words) submitted electronically in primitive HTML (version 2.0 or earlier). You have a little less than a fortnight to get your submission in; all proposals for presentations MUST be received by midnight on Sunday, July 19, 1998. It's OK if some details of your project are still not firm, but you must be careful to indicate those areas in your submission along with their current status and your expectations for their status at the time of the conference. Remember, this is for software developers; just observe the same general rules that you would follow in annotating code in progress. The important thing is that you give enough information for us to decide which presentations to include and to tell other attendees what to expect. The requirement that you submit the description of your presentation in HTML is so that it can go directly on the conference web page as soon as the schedule has been determined. The requirement for primitive HTML is so that your submission can be read without mechanical intervention and also so that it can be read from the conference web site by blind people. Submissions in some godawful generated HTML format with gratuitous tables, one-pixel GIFs, or embedded nbsp's will either be summarily thrown out or thought very badly of, depending on the mood of the reviewer. Since the conference program will be formed simply by concatenating the accepted proposals and putting the file up on the web, please write your submission in a way that will work in that context. Veiled threats, offers of cash, and other language attempting to influence the selection process should be put in a separate cover note rather than in the description of your proposed presentation. RULES FOR PRESENTATIONS Bowing to vociferous demands from previous audiences, we are adding an additional requirement this time that the presentations themselves be given in some kind of format less ephemeral than handwritten notes clutched in one's sweaty palm. While appropriately geeky, this medium is less than satisfactory in answering requests for copies. Please be prepared in the event that your submission is accepted to come to the conference with something that can be displayed on a screen and distributed electronically afterward. Any reasonably common format from ASCII on up to XML with an XSL stylesheet (or sideways to PowerPoint or PDF) is acceptable as long as it can be made available right after the conference in a form that can be downloaded from the conference web site. Note that the presentation itself is not due until the moment that you deliver it. SUBMITTING PROPOSALS Send all submissions by July 19 at midnight California time to Jon Bosak (bosak@eng.sun.com). Please allow a couple of days for acknowledgement of your submission before asking what happened to it. Sending your submission in much before the deadline won't really help your chances, so take the time to write the clearest description that you can. The conference schedule will be announced Monday, July 27. ====================================================================== Jon Bosak, Online Information Technology Architect, Sun Microsystems 901 San Antonio Road, MPK17-101, Palo Alto, California 94043 If a man look sharply and attentively, he shall see Fortune; for though she be blind, yet she is not invisible. -- Francis Bacon ====================================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From daniela at cnet.com Tue Jul 7 19:31:15 1998 From: daniela at cnet.com (Daniel B. Austin) Date: Mon Jun 7 17:02:40 2004 Subject: Simple explanation of difference between XLink and XPointer ? Message-ID: <004e01bda9cb$f1b57c20$7f53a2cc@cnet.com> James, My attempt to provide answers to your questions. Hopefully others will correct my mistakes. -----Original Message----- From: James H. Blackwell Jr. To: XML Dev Date: Tuesday, July 07, 1998 7:53 AM Subject: Simple explanation of difference between XLink and XPointer ? >Hi all, > >Can anyone out there give me a simple explanation of the differences >between XLink and XPointer ? Also, how do they relate to XML-LINK ? XML-LINK and XLINK refer to the same XML dialect. The name is still being finalized by the WG. XLINK and XPOINTER are different however. While your distinction below is correct in that XPOINTER refers to specific locations in documents, XLINK is not confined to documents but can be used to point to any resource whatsoever. XPOINTER can be conceived as a logical extension to the familiar 'named anchor' syntax used in HTML documents. Instead of the author being required to manually place anchors within the document at the desired reference point, the structure of the document, which must be known to some extent beforehand, is used to locate the reference. Thus we can locate the third subheading of the second section of the first chapter of the XML specification easily, merely by knowing that the document's structure follows rules which require that chapters have sections and sections must contain subheadings. (The XML spec contains no chapters - this is only intended as an example.) We add the reference to this document element to the end of the URI for the document in much the same way that named anchors are currently done. XLINK is more complex and difficult to imagine in execution because it does not resemble closely the current hypertext linking model with which we are all familiar. The common hypertext link is the simplest case of an XLINK. More complex link structures can be developed that serve purposes beyond one-way resource links with XLINK. A multiple ended link is a link that points to more than one resource - perhaps a reference in a paper that points to several documents that are used as reference material. This might appear as a drop down menu that is displayed when the user moves the mouse over the linked text in the document, offering several destination choices. Links can also be made bidirectional (or multidirectional) in the sense that the link can be traversed in both directions, from document A to documents B,C, & D, and also from B, C, & D back to A. Reciprocal links of this nature provide a contextual net for the information that provides greater control over the document's use and better linking for the user. Also with a bidirectional link, the well known and despised error 404 will cease to occur, since the link cannot exist unless the correct resource is available at both ends. It's difficult to provide examples of either of these at this time; the concrete syntax and use are still being determined by the WG. Regards, D- **************************************************************************** **** Daniel Austin, Director of Development, Creative Services, CNET daniela@cnet.com 415-395-7800 x1438 "To change the old into the new, and the shapes of things to come..." -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3065 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980707/94d905ae/smime.bin From cowan at locke.ccil.org Tue Jul 7 20:21:33 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:40 2004 Subject: XSchema 1.0 proposals, preparing the ground References: Message-ID: <35A264BE.7B08BF2C@locke.ccil.org> Simon St.Laurent wrote: > This hasn't been implemented; discussion on it never really took off. It's a > fairly trivial piece to add. I worry that having both an ID and a name may > seem confusing, and may be unnecessary since you can refer to pieces through > XPointer by element type/attribute value and not just ID. ID/IDREF is more lightweight than full XPointers even though it is (nearly) subsumed by them (the difference being that an HREF must begin with "#" or "|" whereas an IDREF may not). I think it's worth making it easy to use the simpler system. -- 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 Jul 7 20:36:36 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:40 2004 Subject: PCDATA vs CDATA References: <005e01bda460$c1216990$160410ac@nebula.everyware.com> Message-ID: <35A2669B.F8F66002@locke.ccil.org> Tom Otvos wrote: > Hmm, is that the only case where an XML parser might do the "wrong thing" if > it came across a document without a supporting DTD? By definition, of course, an XML parser can't do the "wrong thing", since XML is already defined. I assume, though, that you want to know what a hypothetical "simplified-SGML" parser might do incorrectly without a DTD. > It seems to me that if > a document comes through without a DTD, and an element contained data not > explicitly escaped, then it would not be unreasonable to assume PCDATA and > try to parse it. However, if a DTD is there to provide more info, then use > it. I am not sure I see how it is significantly different than validating > that an element may, or may not, be a child of another element. Because in (SGML) CDATA there may be text strings that look like tags, but don't meet the rules for tags. That would produce documents which are valid but not well-formed, which is generally agreed to be a Bad Thing. Since XML has no tag omission or minimization, elements can be parsed correctly even without content models available. XML actually goes further: except within "" brackets, every "<" character is guaranteed to be markup, including ones within attribute values (which are errors, of course). -- 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 Jul 7 20:41:00 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:40 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) References: <199806301545.LAA28056@locke.ccil.org> <359A7CD1.74F90437@mecomnet.de> Message-ID: <35A26A79.452088FC@locke.ccil.org> james anderson scripsit: > as noted above, syntax would not be sufficient. in any case, a name encoded as > a string must, at some point, become a universal identifier. Agreed. > it makes no sense > to delay this operation, It makes every sense to delay this operation until we know just which attribute values represent names. Blindly interning every attribute value just in case it's a name, and worse yet, assuming that every attribute value of the form foo:bar *is* a name, is inefficient and perhaps incorrect. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Tue Jul 7 21:43:58 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:40 2004 Subject: XSchema: Namespace PIs in XSchemas considered harmful Message-ID: <35A27A5C.DFB6F9F1@locke.ccil.org> I believe that the emerging consensus for using namespace PIs, with or without XSC:Namespace elements, to identify the prefixes of element/attribute names being described by the XSchema is a Bad Thing. Namespace PIs, on the other hand, are necessary for defining the XSchema prefix (nominally "XSC:") and for identifying prefixes in metadata elements physically within the XSchema. The trouble comes when the same namespace is referred to in both places but with a different prefix. For instance, suppose we have an XSchema defining SomeML. The prefix used in SomeML documents is "SML:", and a namespace PI (with or without an XSC:Namespace element) is used to define this. However, the XSchema may also wish to have metadata elements drawn from other sources. If the XSchema draws from SimpleML and uses the same prefix "SML:" for it, there is a conflict between using the "SML:" prefix and mentioning it. I propose, therefore, that namespace PIs be reserved for the use of prefixes (in element names and attributes) in XSchemas, and XSC:Namespace elements be used as the sole indicators of mentioned prefixes (in declarations of element names and attributes). -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Wed Jul 8 02:38:47 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:40 2004 Subject: compliance with XML advancements In-Reply-To: <61492A178498D111897A00805F6F618768823B@sql-natlaccts.mobilnet.gte.com> (MWoody@mobilnet.gte.com) Message-ID: <199807080036.UAA13672@ruby.ora.com> [Matt Woody] > I musk ask that you excuse my concern if previously addressed. I think it is; I excuse you. > Much anticipated is the surge of DTDs that have been popping up > based on the XML technology. The latest that I've been looking at > are VML, SMIL. The current process of waiting for Netscape or IE to > support the defined DTD with a new version after accepted by W3C has > to be the largest stumbling block for XML. The problem you perceive doesn't (or shouldn't) exist. The reason users have to wait for browsers now is that there is only one DTD, with built-in handling by browsers. When the DTD changes, that built- in handling needs to be changed. XML explicitly provides for multiple DTDs, and even implicit ones, with behavior specified by a stylesheet instead of software's built-in behavior. The browser may have built-in defaults for certain DTDs (like HTML or RDF), but the user community will not have to wait for the browsers to explicitly support any particular DTD. That's precisely the point of XML. -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 Jul 8 02:46:03 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:40 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <199807070134.VAA00298@unready.megginson.com> (message from David Megginson on Mon, 6 Jul 1998 21:34:09 -0400) Message-ID: <199807080044.UAA13700@ruby.ora.com> [David Megginson] > No -- or at least, I imagine not. There are two more interesting > solutions: > > 1. Use something similar to DSSSL modes, one for each namespace: > > [...] > 2. Associate a separate stylesheet with each namespace, through some > mechanism yet to be determined. I don't see a need for either of these. XSL stylesheets shouldn't need to be appreciably different from other XML documents. In other words, my stylesheet might have ... and my document might have This is an HTML paragraph. The XSL processor should be able to identify that "h:p" in the document is the same as "html:p" in the stylesheet, and act accordingly. -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 donpark at quake.net Wed Jul 8 10:04:25 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:40 2004 Subject: XLF: Status Message-ID: <005c01bdaa45$baa45880$2ee044c6@arcot-main> This message is for those interested in participating in the XLF (Extensible Log Format) Initiative. If you are not, please disregard this message. MOMENTUM I have received messages from 20 developers/companies from around the world expressing interests in the XLF Initiative. Most surprising was the readiness of the companies to adopt XML-based log format. We could very well see XLF being deployed in products as soon as we spec is finished. Perhaps even in operating systems . COMMUNICATION JXML, Inc. has offered to host the XLF mailing list but it could take a while to activate it so please have patience. We should use the XML-DEV mailing list until then. I would like to suggest that all XLF related messages should contain "XLF:" string in the subject line so that e-mail filters can intercept reliably. INGREDIENTS About half of the participants are XML developers and the other half server vendors. I believe we need to invite some of the web statistic analyzer vendors to round out the group since I can not imagine them being very happy with Common Log Format. I am planning to invite them as soon as our mailing list is up and running but I would appreciate any help in reaching them since not many of them are on the XML wagon apparently. HELP WANTED We need two volunteers with good writing skills to serve as Co-Editors for XLF. [Gavin, I am not expecting you to volunteer because I know you are already five feet under the DOM spec.] SCHEDULE With simplicity and practicality as our guiding light, I would like us to have something we can submit to W3C within two months from now. Does this sound too ambitious? FINALLY I will post XLF status once a week from this point onward. Best wishes, Don Park CTO/Docuverse P.S. A second message which opens the first thread of discussion will be posted along with this message. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 8 10:13:03 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:41 2004 Subject: XLF: Status Message-ID: <008e01bdaa47$07f29420$2ee044c6@arcot-main> This message is for those interested in participating in the XLF (Extensible Log Format) Initiative. If you are not, please disregard this message. MOMENTUM I have received messages from 20 developers/companies from around the world expressing interests in the XLF Initiative. Most surprising was the readiness of the companies to adopt XML-based log format. We could very well see XLF being deployed in products as soon as we spec is finished. Perhaps even in operating systems . COMMUNICATION JXML, Inc. has offered to host the XLF mailing list but it could take a while to activate it so please have patience. We should use the XML-DEV mailing list until then. I would like to suggest that all XLF related messages should contain "XLF:" string in the subject line so that e-mail filters can intercept reliably. INGREDIENTS About half of the participants are XML developers and the other half server vendors. I believe we need to invite some of the web statistic analyzer vendors to round out the group since I can not imagine them being very happy with Common Log Format. I am planning to invite them as soon as our mailing list is up and running but I would appreciate any help in reaching them since not many of them are on the XML wagon apparently. HELP WANTED We need two volunteers with good writing skills to serve as Co-Editors for XLF. [Gavin, I am not expecting you to volunteer because I know you are already five feet under the DOM spec.] SCHEDULE With simplicity and practicality as our guiding light, I would like us to have something we can submit to W3C within two months from now. Does this sound too ambitious? FINALLY I will post XLF status once a week from this point onward. Best wishes, Don Park CTO/Docuverse P.S. A second message which opens the first thread of discussion will be posted along with this message. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jul 8 10:54:27 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:41 2004 Subject: XSchema: Namespace PIs in XSchemas considered harmful References: <35A27A5C.DFB6F9F1@locke.ccil.org> Message-ID: <35A33450.90A13F05@mecomnet.de> John Cowan wrote: > > The trouble comes when the same namespace is referred to in both > places but with a different prefix. For instance, suppose we > have an XSchema defining SomeML. The prefix used in SomeML documents > is "SML:", how does the prefix ("SML") bound in a 'SomeML' document affect a binding - even one with the same prefix value - in an 'XSchema' document? > and a namespace PI (with or without an XSC:Namespace > element) is used to define this. > > However, the XSchema may also wish to have metadata elements drawn > from other sources. If the XSchema draws from SimpleML and uses > the same prefix "SML:" for it, there is a conflict between using > the "SML:" prefix and mentioning it. why not just use "SoML" as the prefix for the SomeML region and "SiML" for the SimpleML region? aren't both the "use" and the "mention" in the same document? if they are in the same document, why do the prefixes matter, so long as they're different? if they're not in the same document, how does one affect the other? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jul 8 13:13:14 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:41 2004 Subject: Attributes with Intent (and namespaces) In-Reply-To: <199807080044.UAA13700@ruby.ora.com> References: <199807070134.VAA00298@unready.megginson.com> <199807080044.UAA13700@ruby.ora.com> Message-ID: <199807081111.HAA00347@unready.megginson.com> Chris Maden writes: > I don't see a need for either of these. XSL stylesheets shouldn't > need to be appreciably different from other XML documents. In other > words, my stylesheet might have > > > > > > > > > > This is neither explicitly forbidden nor explicitly supported in the current namespaces draft -- the meaning of colons in attribute values is undefined. More generally, however, it might make sense to partition rules by namespace, either in separate XSL specs or at least in separate sections; the reason is that well-known namespaces will often come with their own XSL specifications, and the author of a top-level XSL spec should not have to duplicate that work. 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 ricker at xmls.com Wed Jul 8 16:45:55 1998 From: ricker at xmls.com (Jeffrey Ricker) Date: Mon Jun 7 17:02:41 2004 Subject: Dates in XML Message-ID: <199807081445.KAA25802@mclean2.his.com> What is the general consensus out there for specifying a DATE element? Has this group come agree on a "conventional" method? Using this element would look like: July 8, 1998 Okay, guys and gals, pound away. Jeffrey Ricker ricker@xmls.com XMLSolutions, LLC 601 Pennsylvania Ave. Suite 900, South Bldg. Washington, DC 20004 202.434.8379 http://www.xmls.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Wed Jul 8 17:43:51 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:02:41 2004 Subject: Message-ID: <01bdaa87$d11eb780$0eaddccf@bckman.ix.netcom.com> With the XML DOM coming along, will there be any way to include a scripting language in an XML document using a reserved tag such as:- Not that XSCRIPT exists yet! Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lisarein at finetuning.com Wed Jul 8 17:54:15 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:02:41 2004 Subject: References: <01bdaa87$d11eb780$0eaddccf@bckman.ix.netcom.com> Message-ID: <35A39DCD.FE17956@finetuning.com> This is a very interesting question to me, right now, because I am currently writing about the Action Sheets modularized scripting for HTML and XML proposal (paraphrase on purpose) from Netscape, and I'm having trouble swallowing this (from the spec) can anyone help me to understand if this is true or maybe how it was meant to be taken (and yes I've tried the Netscape guys first....) > While HTML contains a SCRIPT element and HTML > elements may contain attributes that specify event handlers (onClick, onMouseOver, etc.), XML > contains no way of including an external scripting language. thanks lisa Frank Boumphrey wrote: > > With the XML DOM coming along, will there be any way to include a scripting > language in an XML document using a reserved tag such as:- > > > > Not that XSCRIPT exists yet! > > Frank > > Frank Boumphrey > > XML and style sheet info at Http://www.hypermedic.com/style/index.htm > Author: - Professional Style Sheets for HTML and XML http://www.wrox.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 8 19:10:36 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:02:41 2004 Subject: Dates in XML Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA580@red-msg-08.dns.microsoft.com> There is a proposal for dates (and data typing in general) in the XML-Data proposal at the W3C site (sorry that I don't have a link handy). This is a proposal, not an approved recommendation from the W3C. One thing I notice in the example shown below is that the element contains the date twice, once in an easily-parsed form, once in what appears to be a display form. I would hope that the parsable form is all that is needed, with an application able to produce the appropriate display when needed. -----Original Message----- From: Jeffrey Ricker [mailto:ricker@xmls.com] Sent: Wednesday, July 08, 1998 7:44 AM To: xml-dev@ic.ac.uk Subject: Dates in XML What is the general consensus out there for specifying a DATE element? Has this group come agree on a "conventional" method? Using this element would look like: July 8, 1998 Okay, guys and gals, pound away. Jeffrey Ricker ricker@xmls.com XMLSolutions, LLC 601 Pennsylvania Ave. Suite 900, South Bldg. Washington, DC 20004 202.434.8379 http://www.xmls.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe 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 tomo at everyware.com Wed Jul 8 19:42:55 1998 From: tomo at everyware.com (Tom Otvos) Date: Mon Jun 7 17:02:41 2004 Subject: Message-ID: <017a01bdaa97$ae236220$160410ac@nebula.everyware.com> I hope I am not being dumb, but what is preventing anyone from doing that now? I have a When this document is processed, a processor can see that there is a notation attribute (that is an, attribute whose data type is "NOTATION"; by convention we normally use the attribute name "notation" as well, but that's not required). It knows by the rules of XML/SGML that the named notation governs the interpretation of the element. It looks up the notation information and sees the external ID for JavaScript (it must key off the external ID because the notation name JavaScript is a local name and could be anything--you can't depend on authors using the string "JavaScript", even though most will). It sees that there is a dll function or plug in or module or COM object or JavaBean associated with that name and passes the element to it (presumably a pointer to the in-memory representation of the element, or possibly the string representation of the element, depending on the nature of the processor). The notation processor then does whatever it does and comes back, returning whatever the interface between the main processor and the notation processor requires or allows. This is essentially what you do to process objects with different MIME types. The only difference is that notation types are not pre-defined or necessarily registered anywhere because notations are a more general facility than MIME types. You can associate notations with individual elements or with individual attributes (the HyTime standard uses this technique to associate governing notations with attributes that specify addresses in notations not defined by HyTime, see the "reference location type" facility, ). Any browser vendor could define a fixed set of notations that it recognizes, defining what external identifiers it will recognize and what the rules are for use of that notation. But it would be better to provide a more general integration facility of which built-in things are an instance, rather than the only choice. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Wed Jul 8 21:59:45 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:02:42 2004 Subject: Dates in XML Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA586@red-msg-08.dns.microsoft.com> Regarding the difficulty of writing a parser for arbitrary date formats, we propose using only one date format, specifically a profile of ISO 8601. This greatly aids interoperability. I've worked with Misha Wolf of your company on this a while back, and I think we both approve of this course. -----Original Message----- From: Peter_Masters@motorcity2.lotus.com [mailto:Peter_Masters@motorcity2.lotus.com] Sent: Wednesday, July 08, 1998 11:13 AM To: Andrew Layman Cc: xml-dev@ic.ac.uk Subject: RE: Dates in XML Andrew Layman wrote (in part): One thing I notice in the example shown below is that the element contains the date twice, once in an easily-parsed form, once in what appears to be a display form. I would hope that the parsable form is all that is needed, with an application able to produce the appropriate display when needed. July 8, 1998 While it is easy for an application (written in a Turing-complete language) to go from a canonical date representation to some (presumably localized) pretty-printed version, it is not clear to me how you would do this with the standard *ML style sheet mechanisms (either CSS or XSL). The benefit of the sample syntax is that the element content would be apparent, for example, to any HTML browser that latched on to it and which followed the rule that unknown tags are ignored, but their contents are processed. I am aware that I am conflating HTML and XML here, and not everyone will be happy about it, but that is the subject for another, and much longer, message This is the same general approach we've taken with Lotus eSuite's spreadsheet formulas, which typically look something like this: 6 There are certainly proposals on the table to add arbitrary processing capabilities to the rendering pipeline: Netscape's Action Sheets, for example (http://www.w3c.org/TR/NOTE-AS). While these in principal might support the generation of arbitrary displayable content from other information (such as the attribute values in an associated tag), I don't think this really represents a solution to the problem, for at least a couple of reasons: - it breaks the contract (implicit, I think, in both HTML and XML) that the text of the document is represented by the content of its elements - the amount of code needed to implement the desired transforms is essentially unbounded, as is the amount of computation required. While it might be practical to reformat dates with a script attached to an action sheet, I don't think anyone would suggest that a spreadsheet recalc engine is a good candidate for script implementation. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Wed Jul 8 22:24:18 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:42 2004 Subject: XSchema Spec, Section 3, Draft 1 (Namespaces) References: <199806301545.LAA28056@locke.ccil.org> <359A7CD1.74F90437@mecomnet.de> <35A26A79.452088FC@locke.ccil.org> Message-ID: <35A3D5F8.255ECE1E@mecomnet.de> as the comma in the statement below well indicates, the phrase was taken out of a larger context. one in which the objections were addressed, if not resolved. John Cowan wrote: > > [that i] scripsit: > > > as noted above, syntax would not be sufficient. in any case, a name encoded as > > a string must, at some point, become a universal identifier. > > Agreed. > > > it makes no sense > > to delay this operation, > > It makes every sense to delay this operation until we know just which > attribute values represent names. Blindly interning every attribute > value just in case it's a name, and worse yet, assuming that every > attribute value of the form foo:bar *is* a name, is inefficient > and perhaps incorrect. i attempt to pursue substantive discussions in the venue. a counter argument should at least be a response to the points actually made in my note (http://www.lists.ic.ac.uk/hypermail/xml-dev/9807/0031.html). i would welcome a considered response, but find little value in counter claims lodged against fictitious attributions. ... to recount the issues: 1. as i illustrated in my notes on the "attributes with intent" thread (http://www.lists.ic.ac.uk/hypermail/xml-dev/9807/0085.html), an application process need know neither the value of a prefix nor, in fact, even the literal value of an uri in order to carry out its tasks. 2. given that this information has no value to the application, the application should not be burdened with it. this goal is achieved by interning the attributes known to be names as a part of the decoding process. 3. as the goal of qualifying names is to distinguish "similar" names, i've been presuming that they will be used as lookup keys. as soon as i've done one definition lookup based on the string values of the uri and the 'local part', i could well have interned the name. 4. the question which remains is whether there is sufficient information at the point when the document is decoded to determine which attribute values are intended to be interned as names. it is my impression that any standard-based application will know which attributes denote names at the point where the document is decoded. while in general an application may not have a standard, the encoding application will know which attributes contain names when it generates the document, and could well declare them coincident with the namespace declarations. the former case applies in domains such as enabling architectures, xlink, or xschema itself. in the first instance - enabling architectures, for example, taking the "architecture support variables" from mr megginson's note on architectural forms as the starting point, the values of (ArcFormA, ArcNamrA ArcSuprA ArcIgnDA ArcDocF, ArcBridF, and ArcOptSA) would be interned. where the attribute is a mapping attribute, the target attributes would also be interned. in the last instance - xschema, many of the nmtoken attributes should always be interned. for example AttDef.name. for others, the decision can be made only during the decoding process. for example, EnumerationValue.value depends on the presence of sibling elements (ID, IDRef, IDRefs, etc). other attributes, such as Notation.name could be interned as well, even though they are never qualified. ... this discussion (namespaces in general) gives me the willies. it's like i'm sitting in the passenger seat of a spanking new 500c screaming down the freeway. in the middle of rush-hour. nice stereo, leather, a/c. sounds more or less ok. but for the fact that the driver has the pedal to the floor and refuses to change lanes - 'cause there's nothing in the owners' manual that says that that's what one uses a steering wheel for... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 9 01:45:01 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:02:42 2004 Subject: Dates in XML Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA598@red-msg-08.dns.microsoft.com> I mistakenly cited Misha Wolf as being at Lotus. I believe Misha is at Reuters. I goofed. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 9 01:52:07 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:42 2004 Subject: XLF: Status In-Reply-To: <005c01bdaa45$baa45880$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980708213624.bbc70ff4@pop3.demon.co.uk> At 00:52 08/07/98 -0700, Don Park wrote: > >COMMUNICATION > >JXML, Inc. has offered to host the XLF mailing list but it could take a >while to activate it so please have patience. We should use the XML-DEV >mailing list until then. I would like to suggest that all XLF related >messages should contain "XLF:" string in the subject line so that e-mail >filters can intercept reliably. > Fine by me - I am delighted to see XML-DEV acting as the catalyst/midwife for this sort of thing. 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 Jul 9 01:52:13 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:42 2004 Subject: Dates in XML In-Reply-To: <5BF896CAFE8DD111812400805F1991F7038CA580@red-msg-08.dns.mi crosoft.com> Message-ID: <3.0.1.16.19980708214118.bbc7ef44@pop3.demon.co.uk> Thanks Andrew, At 10:09 08/07/98 -0700, Andrew Layman wrote: >There is a proposal for dates (and data typing in general) in the XML-Data >proposal at the W3C site (sorry that I don't have a link handy). This is a >proposal, not an approved recommendation from the W3C. One thing I notice I was looking at the XML-Data proposal just today and thinking 'why don't we use the primitives it defines, just as they are, without the rest of XML-data?'. This encourages me to offer the question to a wider audience. I am seriously missing a specification for primitives - what do other people think about borrowing those from XML-data? 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 Jul 9 01:52:15 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:42 2004 Subject: In-Reply-To: <3.0.32.19980708141534.00aa4984@postoffice.swbell.net> Message-ID: <3.0.1.16.19980708215906.bbc7f7a4@pop3.demon.co.uk> Eliot, There seems to be either some magic or some implied semantics in your processing. The following questions are asked from (my) ignorance: At 14:16 08/07/98 -0500, W. Eliot Kimber wrote: [...] > > > Script//EN" > >... >]> >... > >This serves to connect the local name "JavaScript" to the formal >specification that can presumably be found at the other end of the public >identifier for the notation. By definition, the external ID for a notation >is supposed to get you the human-readable definition of the notation. You What automatic mechanism is available for finding a document at the end of: "+//IDN netscape.com//NOTATION JavaScript//EN" Is there a set of maintained FPI servers like DNS? Because if not, an FPI isn't very useful to me. [...] >When this document is processed, a processor can see that there is a >notation attribute (that is an, attribute whose data type is "NOTATION"; by >convention we normally use the attribute name "notation" as well, but >that's not required). It knows by the rules of XML/SGML that the named >notation governs the interpretation of the element. It looks up the >notation information and sees the external ID for JavaScript (it must key >off the external ID because the notation name JavaScript is a local name >and could be anything--you can't depend on authors using the string >"JavaScript", even though most will). Agreed. Is there a generally agreed way of writing portable code to do this? > >It sees that there is a dll function or plug in or module or COM object or >JavaBean associated with that name and passes the element to it (presumably How does it do this (algorithmically)? This is the key question to which I have been trying to get an answer - (although I want Java classes rather than *.COM or *.dll which are platform-dependent). >a pointer to the in-memory representation of the element, or possibly the >string representation of the element, depending on the nature of the >processor). The notation processor then does whatever it does and comes >back, returning whatever the interface between the main processor and the >notation processor requires or allows. > >This is essentially what you do to process objects with different MIME >types. The only difference is that notation types are not pre-defined or >necessarily registered anywhere because notations are a more general >facility than MIME types. You can associate notations with individual The advantage of MIME types is that there is a well-defined mechanism in current software for associating MIME types with software. AFAIK there is no generally agreed and implemented mechanism for associating FPIs with software. If there is, I'd love to know. It must, of course, be: - free - documented - easily available - platform independent. Perhaps a related question is "which of the current crop of XML tools associates NOTATION and FPI with software?" P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Thu Jul 9 04:03:44 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:42 2004 Subject: XLF: Legacy Log Problems Message-ID: <00ed01bdaadc$a043b200$2ee044c6@arcot-main> [ I appologize for not posting this message last night but I literally fell off my chair and into sleep after posting the Status message. If you are a workaholic who works til you drop, learn Judo or avoid hardwood floors. ] Let us kick off the first round of discussion by enumerating the problems of legacy log formats. Please share with the rest of us what you like and/or hate about log formats you worked with. WHAT I LIKE: Logs in ASCII because they are viewable without special tools and because they can be written out fast. WHAT I HATE: Single level of details. I open a web server log and you see zillions of similar looking entries all with same kind of information. If something wrong happens to a web server, I would like to see more detailed error information when and where it happens in the access log. Custom parsers. Most log formats are simple in structure yet wild in variety so that custom parsers have to be written for each type of logs your server generate. Non-integrated views. When a server generates multiple log types (i.e. access, error, etc.), each log types are written out into separate files. This makes it difficult to analyze problems whose symtoms are spread out over multiple files. When there are more than one process involved (i.e. web server, application server, and database server), the task becomes practically impossible. It would be nice to 'merge' log information from multiple sources to get a view of the all the components working together. Let me just stop here so that rest of you have something to write about . Regards, Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Thu Jul 9 05:01:23 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:02:42 2004 Subject: Message-ID: <3.0.32.19980708215736.00aa4af0@postoffice.swbell.net> At 09:59 PM 7/8/98, Peter Murray-Rust wrote: >What automatic mechanism is available for finding a document at the end of: > "+//IDN netscape.com//NOTATION JavaScript//EN" >Is there a set of maintained FPI servers like DNS? Because if not, an FPI >isn't very useful to me. You would use the same mechanism you use for SGML normally: some sort of catalog file, such as the SGML Open catalog, which is supported by all the SGML tools I use. E.g.: -- Catalog file -- PUBLIC "+//IDN netscape.com//NOTATION JavaScript//EN" "http://www.netscape.com/docs/javascript.html" XML doesn't specify such a mechanism any more than SGML does, because the facility is too general. It would be entirely appropriate and useful for the Web community to define such a mechanism (perhaps by accepting SGML Open catalogs for this purpose generally--it's certainly a well-established, widely-implemented convention). This is identical in function to the MIME mapping file discussed not too long ago. You always have to have some sort of local mapping between data types and the software you want to use to manage them. Alternatively, you could just use a URL (I use FPIs because I'm an SGML wonk and because I live in a world that includes more than the Web :-): ]> As Dan C. and TimBL have pointed out, a URL can be just as persistent as a URN (or FPI) if the maintainer of the resource causes it to be, so there's no reason not to use it as an identifier if you have confidence in its persistence. >>When this document is processed, a processor can see that there is a >>notation attribute (that is an, attribute whose data type is "NOTATION"; by >>convention we normally use the attribute name "notation" as well, but >>that's not required). It knows by the rules of XML/SGML that the named >>notation governs the interpretation of the element. It looks up the >>notation information and sees the external ID for JavaScript (it must key >>off the external ID because the notation name JavaScript is a local name >>and could be anything--you can't depend on authors using the string >>"JavaScript", even though most will). > >Agreed. Is there a generally agreed way of writing portable code to do this? It's just a lookup table where the left hand side is whatever part of the external ID for the notation you have or prefer (if you have both a public and system identifier). I'm not sure what you mean by "portable". >>It sees that there is a dll function or plug in or module or COM object or >>JavaBean associated with that name and passes the element to it (presumably > >How does it do this (algorithmically)? This is the key question to which I >have been trying to get an answer - (although I want Java classes rather >than *.COM or *.dll which are platform-dependent). Again it's a lookup table. In PHyLIS (www.phylis.com), I have code that registers ActiveX controls by the public ID or notation name (as a backup) for the notations they can operate on. The registration function just builds a lookup table that can resolve a string to a pointer to an ActiveX object. To call the right processor, I use the notation information to look up the processor and call the appropriate method of the object at the end of the pointer. Should work the same way in a Java context. >The advantage of MIME types is that there is a well-defined mechanism in >current software for associating MIME types with software. I think you need to qualify this statement--I use a lot of software that does not have any MIME awareness. It may be the case that Web-specific or Web-aware tools do, but that's not all tools. AFAIK there is >no generally agreed and implemented mechanism for associating FPIs with >software. I don't think it's an issue of associating FPIs with software, it's an issue of associating notations with software. You could probably use the existing MIME mechanism by treating the notation external ID as a MIME type (assuming the software doesn't enforce some sort of syntactic constraints on MIME types, which I can't see any point in, as they're just identifiers). In any case, I'm not sure it's a fair question because the only generalized XML tools I'm aware of are either parsers, which wouldn't do this anyway (it's not their job) or SGML applications that already have such a mechanism. I don't know of any general-purpose XML-only applications in which this would be relevant (either because it's something they just wouldn't do by the nature of their purpose or because they're not sufficiently general). Certainly PHyLIS stands as a minimal example of how it might done. Because I wrote it in VB, it fails your platform independent requirement, but if I rewrote it in Java, it would meet all your requirements. If somebody wanted to write the two-page spec for the mechanism, I'd be happy to learn Java sufficient to write a reference implementation. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jul 9 08:23:52 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:42 2004 Subject: In-Reply-To: <3.0.32.19980708215736.00aa4af0@postoffice.swbell.net> Message-ID: <3.0.1.16.19980709071434.8ec72b82@pop3.demon.co.uk> At 21:57 08/07/98 -0500, W. Eliot Kimber wrote: [...] >If somebody wanted to write the two-page spec for the mechanism, I'd be >happy to learn Java sufficient to write a reference implementation. Agreed. My impression is that the nitty-gritty of associating FPIs/URLs, etc with code is: - not terrifyingly difficult (like many others I have built SGML catalog software) - unlikely to come directly out of W3C efforts in which case it could be an excellent thing for XML-DEV to run with. The important thing is to agree communally on how to do it. I would see this as a logica next step after XSchema. I hope my mail didn't seem negative - I'm delighted to use NOTATION IFF: - other people are keen on using it - we agree on a software spec - there is a communal implementation 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 Jul 9 08:23:54 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:42 2004 Subject: XLF: Legacy Log Problems In-Reply-To: <00ed01bdaadc$a043b200$2ee044c6@arcot-main> Message-ID: <3.0.1.16.19980709072229.c017525c@pop3.demon.co.uk> At 18:55 08/07/98 -0700, Don Park wrote: [...] > >Non-integrated views. When a server generates multiple log types (i.e. >access, error, etc.), each log types are written out into separate files. >This makes it difficult to analyze problems whose symtoms are spread out >over multiple files. When there are more than one process involved (i.e. >web server, application server, and database server), the task becomes >practically impossible. It would be nice to 'merge' log information from >multiple sources to get a view of the all the components working together. It could be useful to indicate the variety of log file types. I assume that HTPP logs will be the favorite. [Example: I spend my time grepping the VSMS server logs to see what percentage of JUMBO2 downloads break - by using the byte count. ] Are you anticipating the elementTypes will be as detailed as or more general like ? [I assume the latter, with additional means of qualification through attributes.] P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Thu Jul 9 11:37:04 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:42 2004 Subject: Dates in XML In-Reply-To: Andrew Layman's message of "Wed, 8 Jul 1998 12:58:33 -0700" References: <5BF896CAFE8DD111812400805F1991F7038CA586@red-msg-08.dns.microsoft.com> Message-ID: Andrew> Andrew Layman => In article => <5BF896CAFE8DD111812400805F1991F7038CA586@red-msg-08.dns.microsoft.com>, => Andrew wrote: Andrew> Regarding the difficulty of writing a parser for arbitrary date formats, we Andrew> propose using only one date format, specifically a profile of ISO 8601. Andrew> This greatly aids interoperability. In one document type of my own, I use IS-8601 for dates, using the "yyyy-mm-dd" profile; dd and possibly also mm may be omitted for reduced precision. Andrew> Andrew Layman wrote (in part): Andrew> Andrew> One thing I notice in the example shown below is that the Andrew> element contains the date twice, once in an easily-parsed Andrew> form, once in what appears to be a display form. I would Andrew> hope that the parsable form is all that is needed, with an Andrew> application able to produce the appropriate display when Andrew> needed. Andrew> Andrew> July Andrew> 8, 1998 Andrew> Andrew> While it is easy for an application (written in a Andrew> Turing-complete language) to go from a canonical date Andrew> representation to some (presumably localized) pretty-printed Andrew> version, it is not clear to me how you would do this with the Andrew> standard *ML style sheet mechanisms (either CSS or XSL). Perhaps you could port the DSSSL code from the stylesheet I use with the XML I mentioned earlier (CSS isn't expressive enough; I don't know enough about XSL): ;; given a date string of the form "yyyy[-mm[-dd]]", return an ;; English-local string "[[dd ]Month ]yyyy" (define (PRETTY-DATE x) (if (not (string? x)) (node-list-error (string-append "Bad or missing date attribute") (current-node)) (let ((year (cond ((< (string-length x) 4) (node-list-error (string-append "Bad date (YYYY): \"" x "\"") (current-node))) (#t (substring x 0 4)))) (month (cond ((< (string-length x) 5) "--") ((not (char=? #\- (string-ref x 4))) (node-list-error (string-append "Bad date (YYYY-): \"" x "\"") (current-node))) ((< (string-length x) 7) (node-list-error (string-append "Bad date (YYYY-MM): \"" x "\"") (current-node))) (#t (substring x 5 7)))) (day (cond ((< (string-length x) 8) "--") ((not (char=? #\- (string-ref x 7))) (node-list-error (string-append "Bad date (YYYY-MM-): \"" x "\"") (current-node))) ((< (string-length x) 10) (node-list-error (string-append "Bad date (YYYY-MM-DD): \"" x "\"") (current-node))) (#t (substring x 8 10))))) (string-append (case day (("--") "") (else (string-append (number->string (string->number day)) " "))) (case month (("--") "") (("01") "January ") (("02") "February ") (("03") "March " ) (("04") "April ") (("05") "May ") (("06") "June ") (("07") "July ") (("08") "August ") (("09") "September ") (("10") "October ") (("11") "November ") (("12") "December ") (else (node-list-error (string-append "Bad month: \"" month "\"") (current-node)))) year)))) Andrew> The benefit of the sample syntax is that the element content Andrew> would be apparent, for example, to any HTML browser that Andrew> latched on to it and which followed the rule that unknown Andrew> tags are ignored, but their contents are processed. Another advantage is that one may specify the date/time using completely arbitrary natural language, eg Good Friday OTOH, there's the disadvantage that there's nothing to stop people using ambiguous formats such as 2/4/99 in the free text (though you might be able to catch some of these automatically). -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Thu Jul 9 11:51:43 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:42 2004 Subject: Dates in XML References: <3.0.1.16.19980708214118.bbc7ef44@pop3.demon.co.uk> Message-ID: <35A49339.457E1A29@mecomnet.de> Peter Murray-Rust wrote: > ... > I was looking at the XML-Data proposal just today and thinking 'why don't > we use the primitives it defines, just as they are, without the rest of > XML-data?'. This encourages me to offer the question to a wider audience. I > am seriously missing a specification for primitives - what do other people > think about borrowing those from XML-data? in general, yes. i have some questions. (i have the note from 19980105 at the moment) 1. is the namespace region "urn:uuid:C2F41010-65B3-11d1-A29F-00AA00C14882/" still the one to use? 2. is the dt:dt the attribute to use? 3. are the types in the "specific datatypes" sections the ones to use? if so, i would prefer not to use types like "fixed.14.4", and would find a primary type "fixed" with parameters "magnitude" and "precision" (or whatever they might be) more useful. 4. the expansion conventions suggested in the namespace section a. go beyond the namespace wd: the region of the type attribute name has an implicit dynamic scope over the which covers the attribute value. up until now, i've been fixing the default region for attribute values and attribute regions independantly as the region of the element gi. this alternative convention from the data-types note makes just as much sense, but would need agreement. b. propose expansion rules for universal names which differ from the namespace wd. this problem merely one of exposition, as there need be no literal expansion, but it might lead to confusion. in addition c. use "name" rather than "ns" and leave the impression that the uri would contribute to the process of locating additional information on the type xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 9 11:53:00 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:42 2004 Subject: XSchema: Naming vote count Message-ID: <199807090940.LAA03822@berlin.dvs1.tu-darmstadt.de> The votes are in. We are using: Mixed Caps No underscores XML 1.0 specification names The vote tallies were: Capitalization: --------------- ALL CAPS: 2 Mixed Caps: 17 no caps: 5 Underscores: ------------ Use: 6 Do not use: 18 Element and Attribute Names: ---------------------------- XML 1.0 spec: 13 Simple: 11 Thanks to everyone who voted. -- 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 Jul 9 11:58:17 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:43 2004 Subject: NOTATION FPIs (was: ) In-Reply-To: Peter Murray-Rust's message of "Wed, 08 Jul 1998 21:59:06" References: <3.0.1.16.19980708215906.bbc7f7a4@pop3.demon.co.uk> Message-ID: Peter> Peter Murray-Rust => In article <3.0.1.16.19980708215906.bbc7f7a4@pop3.demon.co.uk>, => Peter wrote: >> >> > > Script//EN" > >> ... >> ]> >> ... >> >> This serves to connect the local name "JavaScript" to the formal >> specification that can presumably be found at the other end of the >> public identifier for the notation. By definition, the external ID >> for a notation is supposed to get you the human-readable definition >> of the notation. You Peter> What automatic mechanism is available for finding a document at Peter> the end of: Peter> "+//IDN netscape.com//NOTATION JavaScript//EN" Peter> Is there a set of maintained FPI servers like DNS? Because if Peter> not, an FPI isn't very useful to me. It *is* useful: it's an opaque string, which can be used to look up components (programs, beans, shared libraries...), just as MIME types can. You never asked for a set of maintained MIME-type servers like DNS. In fact, it's not difficult to write an FPI for a MIME type: -//Internet Assigned Numbers Authority//NOTATION MIME image/gif// perhaps (I'm not sure of the correct owner identifier, but you get the picture). You could even use your existing .mailcaps file (or equivalent) to set up some initial mappings for these FPIs. Peter> The advantage of MIME types is that there is a well-defined Peter> mechanism in current software for associating MIME types with Peter> software. That's true, but it's not without its limits (I assume you're referring to mailcap files). They don't have established conventions for components other than entire programs; it's hard to define different programs for different situations (hi-res screen, terminal screen, print, etc.) Any new convention for associating FPIs with handlers ought to be more general than mailcap files. [It's possible that the current IETF work on URN resolution services may help with retrieving resources from arbitrary, unknown FPIs] -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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.T.Jones at cdc.com Thu Jul 9 12:00:08 1998 From: David.T.Jones at cdc.com (Dave Jones) Date: Mon Jun 7 17:02:43 2004 Subject: XML keyword definitions Message-ID: <3.0.1.32.19980709105407.00a934b0@euroms.europe.cdc.com> All, My colleagues and I at Control Data are implementing a parser in perl to take a piece of xml and break it down to its individual components, ready to store in a tree. For this to work though, they need to understand the definition of the keywords in xml. Am I right in assuming the document type declarations and markup declarations which begin with an >It could be useful to indicate the variety of log file types. I assume that >HTPP logs will be the favorite. [Example: I spend my time grepping the VSMS >server logs to see what percentage of JUMBO2 downloads break - by using the >byte count. ] Are you anticipating the elementTypes will be as detailed as > or more general like ? [I assume the latter, with >additional means of qualification through attributes.] I think many of legacy log format problems originated with over-anticipation. Each log producers should determine their own level of details which could change depending on situations. FTP server could avoid writing out the element until it encounters failure situations. For example, normal FTP entry could look like this: ... 19989 [ Above example actually points to one of the problems of using XML. Elements can not be nested too deep when there is more than one log producer because start and end tags could get mixed up unless the log server prevents the element from being written out until the end tag is received. ] Regards, Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Thu Jul 9 13:13:25 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:43 2004 Subject: Dates in XML Message-ID: <002201bdab2a$eaefc480$1e09e391@mhklaptop.bra01.icl.co.uk> > - it breaks the contract (implicit, I think, in both HTML and XML) that > the text of the document is represented by the content of its elements In a strict sense yes. (XML actually says "All text that is not markup constitutes the character data of the document"). But I don't read that as saying information should be held in its final presentation form: quite the contrary. The whole aim is to move as far as possible towards representing the abstract information content rather than the visible image of the document. Therefore, dates should be held in a canonical form. And of course it matters not one whit whether they are held as attributes or element content, any self-respecting XML processor should be able to handle either. (Though I have discovered one great advantage of using attributes is that a SAX parser can't split them up for you - I've written lots of buggy applications by forgetting that element content can be split, however short it is). 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 lisarein at finetuning.com Thu Jul 9 15:27:46 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:02:43 2004 Subject: References: <199807090906.CAA16480@glinda.oz.net> Message-ID: <35A4CBAC.203A164F@finetuning.com> the quote was straight out of the Action Sheets spec lisa Kirkpatrick, Alfie wrote: > > Lisa, > > Whoever wrote the quote you give doesn't understand the XML concept very > well. XML is for capturing data/information. I can easily write: > > This is my tag > > and it will be well-formed XML. Whether the processing application (read > browser) > understands this is another matter but not a matter which the XML > standard > needs to concern itself with. Any agreed DTD which defines the semantics > of certain attributes like the one above is just that, an agreed DTD > like HTML4. > > Sorry if this sounds a bit harsh, it's just that the quote you give > misses the > point so completely! Perhaps it is taken out of context? > > Alfie. > > > ---------- > > From: Lisa Rein > > Sent: 08 July 1998 17:26 > > To: Frank Boumphrey > > Cc: Dom mailing list; xml mailing list > > Subject: Re: > > > > This is a very interesting question to me, right now, because I am > > currently writing about the Action Sheets modularized scripting for > > HTML > > and XML proposal (paraphrase on purpose) from Netscape, and I'm having > > trouble swallowing this (from the spec) can anyone help me to > > understand if this is true or maybe how it was meant to be taken (and > > yes I've tried the Netscape guys first....) > > > > > While HTML contains a SCRIPT element and HTML > > > elements may contain attributes that specify event handlers > > (onClick, onMouseOver, etc.), XML > > > contains no way of including an external scripting language. > > > > > > thanks > > > > 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 amitr at abinfosys.com Thu Jul 9 15:28:58 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:02:43 2004 Subject: Returning XML data streams from server Message-ID: <001201bdab3e$bc0ef1e0$0201a8c0@amit.abinfosystems.com> Hello, How do I pass an XML stream to an XSL processor DIRECTLY? Currently, I am using the MSXSL (ActiveX control embedded in a web page) as my XSL processor. . . . . . . I am using the MS shipped XMLDSO applet as a validating XML parser using :- From M.H.Kay at eng.icl.co.uk Thu Jul 9 15:57:32 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:43 2004 Subject: NOTATION FPIs (was: ) Message-ID: <005201bdab2f$cf7f9720$1e09e391@mhklaptop.bra01.icl.co.uk> >It *is* useful: it's an opaque string, which can be used to look up >components (programs, beans, shared libraries...), just as MIME types >can. You never asked for a set of maintained MIME-type servers like >DNS. In fact, it's not difficult to write an FPI for a MIME type: > > -//Internet Assigned Numbers Authority//NOTATION MIME image/gif// > Perhaps I'm being pedantic, but I think it's worth pointing out that there's no such thing as an FPI in XML. The closest there is is a "Public Identifier", and the only things that the spec says about it are (a) that certain spaces within it are insignificant, and (b) that the processor can try and convert it to a URI (but it doesn't say how). For the perceptive reader, the choice of name for the metasymbol suggests that the authors were thinking of some kind of global namespace, and the examples of Public Identifiers suggest they were thinking of some kind of analogy with a similar namespace used in SGML. But this is reading between the lines of the standard. It's actually even easier to write a Public Identifier for a MIME type, if I can choose I can call it "image/gif", or even "fred". 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 eriblair at mediom.qc.ca Thu Jul 9 17:18:11 1998 From: eriblair at mediom.qc.ca (Eric Riblair) Date: Mon Jun 7 17:02:44 2004 Subject: CAN SOMEBODY TELL ME IF YOU SEE THIS MESSAGE ... Message-ID: <199807091517.LAA18511@netra.mediom.qc.ca> I bless somebody to give me an answer !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!! Hi everybody ... To Whom it concern, I work presently with the applet msxml and many script ( ... in Java) and I have some problems ... to load these files in the Mac version of Internet Explorer ... and in Netscape 4 (... in all versions !!!). In that way I'd try to download the the XML parser for the other environment (ex: Mac) and I had the File Not Found ... answer .... Thanks for any help ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Jul 9 17:54:06 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:44 2004 Subject: NOTATION FPIs (was: ) In-Reply-To: (message from Toby Speight on 09 Jul 1998 10:59:22 +0100) Message-ID: <199807091552.LAA00623@ruby.ora.com> [Toby Speight] > In fact, it's not difficult to write an FPI for a MIME type: > > -//Internet Assigned Numbers Authority//NOTATION MIME image/gif// > > perhaps (I'm not sure of the correct owner identifier, but you get > the picture). I just wanted to speak up on this, since you and Eliot have both done this now: Only IANA can use "-//IANA//". Only Netscape can use "+//IDN netscape.com//". The "owner" in the "owner identifier" is *the owner of the FPI*, not the owner of the resource. You can create -//Toby Speight//NOTATION MIME image/gif//, but you may not create -//IANA//NOTATION MIME image/gif//. If IANA creates the public identifier for their resource, you may use it, but you may not infringe on their namespace. DeRose and Durand, in _Making Hypermedia Work_, used their ISBN to create FPIs for a variety of notations, and donated those FPIs to the public domain. I recommend using these if the creator of the resource hasn't designated an FPI of their own. -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 Thu Jul 9 18:11:11 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:44 2004 Subject: XML keyword definitions In-Reply-To: <3.0.1.32.19980709105407.00a934b0@euroms.europe.cdc.com> (message from Dave Jones on Thu, 09 Jul 1998 10:54:07 +0100) Message-ID: <199807091609.MAA01137@ruby.ora.com> [Dave Jones] > For this to work though, they need to understand the definition of > the keywords in xml. Am I right in assuming the document type > declarations and markup declarations which begin with an self-contained internal keywords which have no other dependencies. Unless you care about getting external entities to work. If you do, you'll need to check for entity declarations. I've written a simple Perl script that loops through a file and handles external entities. A better thing to do would be to use Larry Wall's XML::Parser package, which is a wrapper on James Clark's xmltok, but I'm having shared library problems... I'm willing to share the Perl script with anyone who wants it; you can see its current frivolous application as a Diplomacy board game report generator at . -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 schampeo at hesketh.com Thu Jul 9 18:14:25 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:02:44 2004 Subject: XLF: Legacy Log Problems In-Reply-To: <3.0.1.16.19980709072229.c017525c@pop3.demon.co.uk> Message-ID: On Thu, 9 Jul 1998, Peter Murray-Rust wrote: > At 18:55 08/07/98 -0700, Don Park wrote: > [...] > > > >Non-integrated views. When a server generates multiple log types (i.e. > >access, error, etc.), each log types are written out into separate files. > >This makes it difficult to analyze problems whose symtoms are spread out > >over multiple files. When there are more than one process involved (i.e. > >web server, application server, and database server), the task becomes > >practically impossible. It would be nice to 'merge' log information from > >multiple sources to get a view of the all the components working together. I think this is a great idea. Say goodbye to the days of running 'tail -f' in two different xterms :) > It could be useful to indicate the variety of log file types. I assume that > HTPP logs will be the favorite. [Example: I spend my time grepping the VSMS > server logs to see what percentage of JUMBO2 downloads break - by using the > byte count. ] Are you anticipating the elementTypes will be as detailed as > or more general like ? [I assume the latter, with > additional means of qualification through attributes.] Apache uses a sprintf-like format specification language, where the log format may be arbitrarily specified. The server is then responsible for parsing the format string and spitting out the appropriate logstuff. I think that the stuff one finds in logfiles is common across many different types of logfiles, so I would prefer specific over generic element names. Besides, these things can take up a lot of space. Do we really want to do When we could (and probably should) do: Thu Jul 9 12:13:13 EDT 1998 or its equivalent? I can see the desire to genericize logfile entries getting ugly quick :) -- "All the good geek things, | schampeo@hesketh.com only without all the | http://a.jaundicedeye.com bad geek things." | http://hesketh.com/schampeo/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 9 18:30:46 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:44 2004 Subject: NOTATION FPIs (was: ) In-Reply-To: <005201bdab2f$cf7f9720$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <000a01bdab57$346dd6c0$e2bc38cb@NT.JELLIFFE.COM.AU> > From: Michael Kay > > Perhaps I'm being pedantic, but I think it's worth pointing > out that there's no such thing as an FPI in XML. The closest > there is is a "Public Identifier", and the only things that > the spec says about it are (a) that certain spaces within it > are insignificant, and (b) that the processor can try and > convert it to a URI (but it doesn't say how). There are various kinds of public identifiers. The thing that makes an identifier public is generally that it relies on registration with a body, which is why there is an owner part. (If the document is private or limited circulation, this registration can be in-house or by arrangement between the parties involved rather than some external convention. SGML FPIs and MIME media-types have the simplification by having "registered" and "unregisted" owners, where registered ownership guarantees unique naming.) The kinds of public identifiers around are: * ISO 9070: uses "::" to delimit a hierachy of names * URNs: starts with urn: * URIs: you know * SGML FPIs: formal public identifiers start with "-//" (unregistered=private), "+//" (registered: ISBN, or IDN for internet, or a name registered with the designated registration authority") or "ISO" (or "IEC" or "ISO/IEC") * MIME media types. There are moves to extend urn syntax to encompass MIME types--I dont know the status, perhaps they already do. It may be surprising that MIME media types are actually public identifiers currently. But the RFCs define a mechanism for allowing other "registration trees" apart from IETF. One thing this may allow is for an ISO registration tree: e.g. text/iso-8601 (the "-" is a significant delimiter). Anyway there is a general expectation in XML that system identifiers should be URIs and that public identifiers should be SGML FPIs. However, until this is defined, there is no choice but to use MIME media types for SYSTEM identifiers. Even though MIME media types are, strictly speaking, public identifiers, they belong in the "WWW" slot not the "ISO" slot (i.e. the SYSTEM identifier not the PUBLIC identifier). I guess there might be differing views on this as a policy, but there should be an agreed approach. But for future proofing, can I suggest that it might be best if software which interprets the system identifier would also accept whatever the likely future urn syntax for MIME media types might be: e.g. "(urn:.*:)?.*/(.*-)?.*" such as "urn:mime:text/x-iso8601" If you write your software so that it accepts the following notation declaration then you would have to make sure it accepted all syntaxes for dates which that standard defines. If your software only accepted a subset, you would have let it accept some other public identifier I am not sure if ISO8601 has made it into the current version of ISO/IEC TR 9573-9:1997 "Standardized Data Notation". In ISO 10744 (HyTime) there are also FPIs for time and distance. (If you are interested in notations, I give several chapters on them, with lots of listings for useful and common notations, in my book. I certainly think that XML-DEV should get behind (Tim Bray's) collection of database notations which is in XML-data.) 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 SimonStL at classic.msn.com Thu Jul 9 20:18:14 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:44 2004 Subject: XSchema: Naming vote count Message-ID: >The votes are in. We are using: > >Mixed Caps >No underscores >XML 1.0 specification names Sounds good - a resounding vote for the status quo. Well, almost resounding - the spec vote was close I lost on two out of three, but I can take it. New versions of all sections of 2.0 of the spec will appear in the next two days, including the mysterious and long-awaited use of attributes instead of empty elements for attribute and declaration notations. 4 and 5 will follow shortly thereafter; I suspect they'll need some chewing. Many thanks to our 24 voters, whoever they were. 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 Jul 9 20:35:50 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:44 2004 Subject: References: <3.0.32.19980708141534.00aa4984@postoffice.swbell.net> Message-ID: <35A50CFF.F146B5B0@locke.ccil.org> W. Eliot Kimber wrote: > This is what notations are for (unfortunately, by choosing not to include > data attributes, XML has severely limited the utility of the notation > feature, but I'm sure that will be corrected). What are data attributes? -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Thu Jul 9 21:55:28 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:44 2004 Subject: Notations and MIME types Message-ID: <35A51FE1.70EB0235@locke.ccil.org> I will try to explain the issues in a way that both sides will find intelligible. There seem to be the following conceptual differences between notations and MIME types: 1. Notation names are normally declared locally, whereas MIME type names have a global registry with a provision for local-use extensions. This is resolved by noting that the NOTATION declaration provides for a public ID and an URL (system id). The system id of a notation corresponding to a MIME type can refer to the URL where the definition (in English) of the MIME type is stored. A group of public IDs could also be manufactured of the type "-//IETF//NOTATION MIME text/plain//EN", which would be understood to be equivalent to the MIME type "text/plain". 2. Syntactically, MIME-types employ characters that aren't allowed in public IDs or in XML Names. This could be resolved by a mapping convention. The most important character in this respect is "/", which is allowed in public ids but not in Names, since every MIME type name has exactly one "/". 3. There is a difference in expectation between the SGML style and the Internet/MIME style about who declares what. SGML systems expect that referring documents will know the notation used by objects that they refer to. Internet documents such as mail messages or Web pages, OTOH, usually simply refer to external documents by URL, and expect either that the MIME type can be guessed from the URL, or else that the remote system will return the MIME type along with the content. I don't know just what should be done to smooth over this difference. I hope this helps to clarify the issues. -- 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 Jul 9 21:57:28 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:45 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 4 Message-ID: This is the latest version of the XSchema element. Namespaces now must appear before element and notation declarations. I've attempted to clear up some of the language surrounding the XSchema specification version and XSchemas created using that specification. Major Question: Do we want Attribute declarations allowed outside of element declarations? If yes, we need to do that here. This will be fairly minor surgery; the AttDef element will also need a new attribute for its parent element. The XML 1.0 spec doesn't have any such production - it just uses Name. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.0 XSchema Syntax This section describes the XSchema document syntax. The XSchema document is an XML document containing a single XSchema element in which information describing the schema is nested. The XSchema element must be preceded by an XML declaration and may be preceded by other declarations, comments, and processing instructions. 2.1 The XSchema Element The XSchema element is the root element for all XSchema documents. The declaration for the XSchema element is: The 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 the XSchema specification used as well as information about the type of documents described by the XSchema. Information about the XSchema specification version used to create this XSchema, 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 the XSchema specification should identify themselves differently. No provision is made at this time for nesting XSchemas using different versions of the specification under a parent XSchema element. The 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. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 9 22:08:22 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:45 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 4 Message-ID: Oops. Left out the id ID #IMPLIED in the DTD for XSC:XSchema. I love making changes in two programs at once. Any objections to giving the root element a possible ID? 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 SimonStL at classic.msn.com Thu Jul 9 22:19:46 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:45 2004 Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 4 Message-ID: Following is the latest draft of Section 2.2 on Element declarations. XSC:More has been corrected to be optional, and a bit more explanation of some components has been added to address questions sent me privately. I would have changed the names, but the vote was for the status quo. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.2 Element Declarations Element declarations in XSchemas are made using the XSC:ElementDecl element and its contents: The XSC:name attribute identifies the name of the element, and is required. An element declaration would look like: ...additionalElementInformation... This declaration would declare an element named "Species", which would appear in an instance as: ...content... The XSC:name attribute must be unique within the set of elements, as it provides the name of the element as declared here, and is also used by other elements to refer to this element in their content model declarations. The XSC:id attribute, if it appears, must be unique within the document. This attribute may be used to uniquely identify this XSC:ElementDecl element for reference using XPointers and other tools. The XSC:root attribute provides authoring tools with a guide for which elements are likely root elements for documents. This is intended to simplify the choices presented to authors during document composition. Composition tools could use this to build a menu of likely starting points for a document. Note that an element must declare a content model of some type, even if that content model is empty. Documentation (in the XSC:Doc element), non-XSchema extensions (in the XSC:More element) and attribute declarations (using XSC:AttDef elements) are optional. Documentation about the element, additional extensions, 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. Additional extensions are covered in 2.6.2, Further 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 Bryan_Gilbert at pml.com Thu Jul 9 22:21:32 1998 From: Bryan_Gilbert at pml.com (Bryan Gilbert) Date: Mon Jun 7 17:02:45 2004 Subject: Data Types (was: RE: Dates in XML) Message-ID: I posted a note about data types a couple of months ago. Since then a W3C submission was made so... see http://www.w3.org/TR/1998/NOTE-webbroker-19980511/ because it includes DTDs for data types that are ready to go. Bryan > -----Original Message----- > From: Peter Murray-Rust [SMTP:peter@ursus.demon.co.uk] > Sent: Wednesday, July 08, 1998 2:41 PM > To: xml-dev@ic.ac.uk > Subject: RE: Dates in XML > [BG] .... > I was looking at the XML-Data proposal just today and thinking 'why > don't > we use the primitives it defines, just as they are, without the rest > of > XML-data?'. This encourages me to offer the question to a wider > audience. I > am seriously missing a specification for primitives - what do other > people > think about borrowing those from XML-data? > > 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 SimonStL at classic.msn.com Thu Jul 9 22:42:47 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:45 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4 Message-ID: This is mostly minor cleanup. The examples still referred to the id attribute of the element, not its name, which could be disastrous now that we're giving elements id attributes separately. Big question: Do we give these elements id attributes as well? It seems like overkill to me, but I can imagine cases where it might be worth it. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.3 Content Model Declarations Content model declarations are made within 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 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 PCData, CommonName elements, LatinName elements, and PreferredFood elements in any order, the declaration would look like: The XSchema processor should ignore any frequency attributes in the Ref element. 2.3.7 Choice Content Model The Choice content model allows for either-or inclusions of elements and groups of elements. The Choice content model represents groups of element content possibilities and must contain at least two sub-elements. Situations where only one element is needed should use the Ref content model instead of Choice. 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 sub-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 jtigue at DataChannel.com Thu Jul 9 22:49:12 1998 From: jtigue at DataChannel.com (John Tigue) Date: Mon Jun 7 17:02:45 2004 Subject: Data Types (was: RE: Dates in XML) Message-ID: <4435AEE04AAED111A41F00A0C99B60230FCE6E@ZEUS> WebBroker uses the datatypes defined in XML-Data. The dt attribute from XML-Data namespace is used for datatype recognition by XML-Data aware processors. Otherwise a NOTATION attribute is used for xml 1.0 processors. This is very limited but did what I needed. Limitations of this trick include: Attributes cannot be datatyped. Extensibility is not addressed. Encoding (NOTATION) and data-typing should be explicitly seperate attributes which they are not in WebBroker. I would not use the WebBroker tricks as is to solve general purpose problems besides the "RPC" stuff it was designed for. I was able to get a lot done using only primitive data typing without the higher powered features of schemas. > -----Original Message----- > From: Bryan Gilbert [mailto:Bryan_Gilbert@pml.com] > Sent: Thursday, July 09, 1998 1:19 PM > To: 'xml-dev@ic.ac.uk' > Subject: Data Types (was: RE: Dates in XML) > > > I posted a note about data types a couple of months ago. Since > then a W3C submission was made so... see > http://www.w3.org/TR/1998/NOTE-webbroker-19980511/ > because it includes DTDs for data types that are ready to go. > Bryan > > > -----Original Message----- > > From: Peter Murray-Rust [SMTP:peter@ursus.demon.co.uk] > > Sent: Wednesday, July 08, 1998 2:41 PM > > To: xml-dev@ic.ac.uk > > Subject: RE: Dates in XML > > > [BG] .... > > I was looking at the XML-Data proposal just today and thinking 'why > > don't > > we use the primitives it defines, just as they are, without the rest > > of > > XML-data?'. This encourages me to offer the question to a wider > > audience. I > > am seriously missing a specification for primitives - what do other > > people > > think about borrowing those from XML-data? > > > > 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) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 9 23:48:28 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:45 2004 Subject: XSchema: Naming vote count In-Reply-To: <199807090940.LAA03822@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980709220803.bd0f830c@pop3.demon.co.uk> At 11:40 09/07/98 +0200, Ron Bourret wrote: >The votes are in. We are using: > >Mixed Caps >No underscores >XML 1.0 specification names Thanks very much for doing this, Ron. (Takes the mind off football). P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jul 10 00:05:44 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:45 2004 Subject: Action Sheets, stylesheets, and MVC Message-ID: <35A53E52.F0D91ACA@locke.ccil.org> It occurred to me the other day that an XML document, a stylesheet for rendering it, and an Action Sheet for responding to events associated with it, represent an instance of the well-known Model-View-Controller paradigm. There's a paper here somewhere. -- 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 Jul 10 00:20:16 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:45 2004 Subject: XLF: Legacy Log Problems References: Message-ID: <35A5416D.8B0173E5@locke.ccil.org> Steven Champeon wrote: > > > When we could (and probably should) do: > > Thu Jul 9 12:13:13 EDT 1998 > > or its equivalent? I can see the desire to genericize logfile entries > getting ugly quick :) I actually prefer the former to the latter, since it means I don't have to have a date parser behind the XML parser. Using attributes makes it easy to pick out all 1998 entries, or all Thursdays, or all July 1998 entries, or whatever. In no case should we standardize on that ancient format. If we must represent dates as strings rather than as attribute-bags, we should use a profile of ISO 8601. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Fri Jul 10 00:43:24 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:02:45 2004 Subject: XLF: Legacy Log Problems In-Reply-To: <35A5416D.8B0173E5@locke.ccil.org> Message-ID: On Thu, 9 Jul 1998, John Cowan wrote: > I actually prefer the former to the latter, since it means I don't > have to have a date parser behind the XML parser. Using attributes > makes it easy to pick out all 1998 entries, or all Thursdays, or > all July 1998 entries, or whatever. Are you assuming that the XML parser should be able to analyze the logfiles and produce reports on them as well? Seems like a lot to ask of a parser... I was viewing this more as a data storage and transfer format. The compromises would necessarily have to come when deciding between storage (compact is better) and transfer (more explicit is better). I'm just concerned that any effort to standardize on an XML-based logfile format will be rejected if it means the admins of larger servers have to run out and buy Clariion disk arrays just to hold their new 10x logfiles. > In no case should we standardize on that ancient format. If we > must represent dates as strings rather than as attribute-bags, > we should use a profile of ISO 8601. Sorry to have raised hackles. Shouldn't have cut-and-pasted the output from `date` into the message. I agree that we should stick to current, standard formats for dates and whatnot. I just don't see the utility of making every digit into an attribute. -- "All the good geek things, | schampeo@hesketh.com only without all the | http://a.jaundicedeye.com bad geek things." | http://hesketh.com/schampeo/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 10 00:45:30 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:45 2004 Subject: NOTATION FPIs (was: ) References: <000a01bdab57$346dd6c0$e2bc38cb@NT.JELLIFFE.COM.AU> Message-ID: <35A54727.425AF735@locke.ccil.org> Rick Jelliffe wrote: > There are moves to extend urn syntax to encompass MIME types--I don't know > the status, perhaps they already do. Assuming they don't, then... > Anyway there is a general expectation in XML that system identifiers should > be URIs and that public identifiers should be SGML FPIs. However, until > this is defined, there is no choice but to use MIME media types for SYSTEM > identifiers. Even though MIME media types are, strictly speaking, public > identifiers, they belong in the "WWW" slot not the "ISO" slot (i.e. the > SYSTEM identifier not the PUBLIC identifier). Not so. In XML, system identifiers are URIs, period, and URIs are URNs and URLs, period. MIME types are not yet URNs and definitely aren't URLs. -- 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 Jul 10 00:50:29 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:46 2004 Subject: XLF: Legacy Log Problems References: Message-ID: <35A548E1.6CD75FF8@locke.ccil.org> Steven Champeon wrote: > Are you assuming that the XML parser should be able to analyze the > logfiles and produce reports on them as well? Seems like a lot to > ask of a parser... No, I simply meant that such an application shouldn't have to parse PCDATA content to make very ordinary and reasonable discriminations. PCDATA should be reserved for text strings meaningful only to human beings. We already have to have an XML parser in every XLF analyzer, that's a given. But there shouldn't have to be any other kind of parser too. IMHO. > I'm just concerned that any effort to standardize > on an XML-based logfile format will be rejected if it means the > admins of larger servers have to run out and buy Clariion disk > arrays just to hold their new 10x logfiles. Let 'em use on-the-fly gzipping and gunzipping, then. Layering that over a generator or a parser is very easy. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Fri Jul 10 01:30:54 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:02:46 2004 Subject: XLF: Legacy Log Problems In-Reply-To: <35A548E1.6CD75FF8@locke.ccil.org> Message-ID: On Thu, 9 Jul 1998, John Cowan wrote: > > Are you assuming that the XML parser should be able to analyze the > > logfiles and produce reports on them as well? Seems like a lot to > > ask of a parser... > > No, I simply meant that such an application shouldn't have to > parse PCDATA content to make very ordinary and reasonable > discriminations. PCDATA should be reserved for text strings > meaningful only to human beings. We already have to have an > XML parser in every XLF analyzer, that's a given. But there > shouldn't have to be any other kind of parser too. > > IMHO. OK, that makes sense. We share HOs. > Let 'em use on-the-fly gzipping and gunzipping, then. Layering > that over a generator or a parser is very easy. Fair enough, provided it doesn't place undue load on an already stressed environment. -- "All the good geek things, | schampeo@hesketh.com only without all the | http://a.jaundicedeye.com bad geek things." | http://hesketh.com/schampeo/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From daniela at cnet.com Fri Jul 10 01:49:11 1998 From: daniela at cnet.com (Daniel B. Austin) Date: Mon Jun 7 17:02:46 2004 Subject: Action Sheets, stylesheets, and MVC Message-ID: <001b01bdab92$f588cc80$7f53a2cc@cnet.com> John, It is already being written. I pointed this out to the XSL WG during the first f2f meeting. It is actually a very powerful concept that can be widely applied to several classes of information architectures. Regards, D- **************************************************************************** **** Daniel Austin, Director of Development, Creative Services, CNET daniela@cnet.com 415-395-7800 x1438 "To change the old into the new, and the shapes of things to come..." -----Original Message----- From: John Cowan To: XML Dev Date: Thursday, July 09, 1998 3:09 PM Subject: Action Sheets, stylesheets, and MVC >It occurred to me the other day that an XML document, a stylesheet >for rendering it, and an Action Sheet for responding to events >associated with it, represent an instance of the well-known >Model-View-Controller paradigm. > >There's a paper here somewhere. > >-- >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) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3065 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980710/9b040f98/smime.bin From karki at po.cisnet.or.jp Fri Jul 10 01:51:28 1998 From: karki at po.cisnet.or.jp (Parameshwor Karki) Date: Mon Jun 7 17:02:46 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4 References: Message-ID: <35A554B9.B09@po.cisnet.or.jp> Simon St.Laurent wrote: # 2.3.5 Reference Content Model [...] # OneOrMore is the equivalent of the * occurrence # indicator in XML 1.0 DTDs. I think it should be _ZeroOrMore_ is the equivalent of the * occurrence indicator in XML 1.0 DTDs. -- Parameshwor Karki Daitec Co., Ltd. Hiroshima, JAPAN xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gleeson at unimelb.edu.au Fri Jul 10 02:13:57 1998 From: gleeson at unimelb.edu.au (Martin Gleeson) Date: Mon Jun 7 17:02:46 2004 Subject: XLF: Legacy Log Problems In-Reply-To: <35A548E1.6CD75FF8@locke.ccil.org> References: Message-ID: Hi Folks, On 9/7/98, John Cowan wrote: >Steven Champeon wrote: >> I'm just concerned that any effort to standardize >> on an XML-based logfile format will be rejected if it means the >> admins of larger servers have to run out and buy Clariion disk >> arrays just to hold their new 10x logfiles. >Let 'em use on-the-fly gzipping and gunzipping, then. Layering >that over a generator or a parser is very easy. This is the one concern I have with XLF. I already do the above with my web log analysis tool, pwebstats. And that's the problem - for example, the logs from our proxy server are 600Mb per week, gzipped, -9, and increasing. Whilst one of my next tasks is to have pwebstats handle incremental updates, it still shows the scope of the problem, especially for those who may need to keep a permanent copy of their logs for whatever reason. An order of magnitude increase in size creates difficulties when a feature of many logfile formats is representing the necessary information in the smallest reasonable space. Cheers, Marty. -- Martin Gleeson Webmaster, The University of Melbourne, Australia. Imagine, if you will, a world without hypothetical 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 amitr at abinfosys.com Fri Jul 10 05:04:16 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:02:46 2004 Subject: Handling an XML data stream using XML and XSL processors Message-ID: <004b01bdabb0$86970580$0201a8c0@amit.abinfosystems.com> Hello, How do I pass a parsed tree output of an XML DATA stream to an XSL processor DIRECTLY? Currently, I am using the MSXSL (ActiveX control embedded in a web page) as my XSL processor. . . . . . . I am using the MS shipped XMLDSO applet as a validating XML parser using :- From tbray at textuality.com Fri Jul 10 06:22:50 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:02:46 2004 Subject: Dates in XML Message-ID: <3.0.32.19980709211744.00a7fda4@pop.intergate.bc.ca> At 09:41 PM 7/8/98, Peter Murray-Rust wrote: >>what do other people >think about borrowing those [primitives] from XML-data? I think there's too many; but with any luck this is one of the issues we can put to bed quickly. That's assuming we're ever allowed to start thinking about it. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 10 08:33:18 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:46 2004 Subject: No subject Message-ID: <013a01bdabcb$71b46340$2ee044c6@arcot-main> Hello everyone, The XLF mailing list is now up and running! Detailed information on how to join the list is below. XLF discussion will now move to the XLF mailing list. [ A big thanks to XML-DEV folks especially Peter ] I will keep XML-DEV members up to date by posting a copy of weekly status to XML-DEV. The mailing list address is: xlf@cybercom.net To be added to the list, send a message of the form subscribe xlf by email to majordomo@cybercom.net To be removed from the list, send a message of the form unsubscribe xlf by email to the same address. Note that 'xlf' is lowercased XLF and the commands should be in the body of the message and not in the subject line. Subject can be empty. See you there, Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Fri Jul 10 08:36:22 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:46 2004 Subject: XLF: Mailing List Info Message-ID: <014801bdabcb$d4dcc1b0$2ee044c6@arcot-main> [Sorry for the repost but the last message had empty subject line. Two beers Peter!] Hello everyone, The XLF mailing list is now up and running! Detailed information on how to join the list is below. XLF discussion will now move to the XLF mailing list. [ A big thanks to XML-DEV folks especially Peter ] I will keep XML-DEV members up to date by posting a copy of weekly status to XML-DEV. The mailing list address is: xlf@cybercom.net To be added to the list, send a message of the form subscribe xlf by email to majordomo@cybercom.net To be removed from the list, send a message of the form unsubscribe xlf by email to the same address. Note that 'xlf' is lowercased XLF and the commands should be in the body of the message and not in the subject line. Subject can be empty. See you there, Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jul 10 09:32:57 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:46 2004 Subject: Action Sheets, stylesheets, and MVC In-Reply-To: <35A53E52.F0D91ACA@locke.ccil.org> Message-ID: <3.0.1.16.19980710074852.b0af4cba@pop3.demon.co.uk> At 18:04 09/07/98 -0400, John Cowan wrote: >It occurred to me the other day that an XML document, a stylesheet >for rendering it, and an Action Sheet for responding to events >associated with it, represent an instance of the well-known >Model-View-Controller paradigm. This sounds like a brilliant idea. As is also well-known the JFC (SwingSet) is based on MVC. I have used Swing to build JUMBO2. (I can't say I find it easy, because there are a zillion classes, but I accept it's 'right' :-) > >There's a paper here somewhere. There might also be an XML-DEV virtual activity where we remove part of the algorithm and part of the data from the conventional program and externalise them. I am very keen to represent behaviour ('actions') in XML files rather than hardcoded. But it needs someone cleverer than me :-) P. > >-- >John Cowan http://www.ccil.org/~cowan cowan@ccil.org > You tollerday donsk? N. You tolkatiff scowegian? Nn. > You spigotty anglease? Nnn. You phonio saxo? Nnnn. > Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jul 10 09:33:01 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:46 2004 Subject: Dates in XML In-Reply-To: <3.0.32.19980709211744.00a7fda4@pop.intergate.bc.ca> Message-ID: <3.0.1.16.19980710075157.b15fa6ec@pop3.demon.co.uk> At 21:23 09/07/98 -0700, Tim Bray wrote: >At 09:41 PM 7/8/98, Peter Murray-Rust wrote: >>>what do other people >>think about borrowing those [primitives] from XML-data? > >I think there's too many; but with any luck this is one of the issues >we can put to bed quickly. That's assuming we're ever allowed to start >thinking about it. -Tim On XML-DEV we think the unthinkable. Just let us know when the gun has been fired... 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 amitr at abinfosys.com Fri Jul 10 15:31:24 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:02:46 2004 Subject: Merging Object Oriented Design and SGML Architectures Message-ID: <001701bdac08$d940a450$0201a8c0@amit.abinfosystems.com> Hello, Could anyone please guide to articles/technical notes regarding OOD and SGML Architectures. Any help will be greatly appreciated Thanx, AMIT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980710/7ee9adb5/attachment.htm From alberto.reggiori at jrc.it Fri Jul 10 15:37:00 1998 From: alberto.reggiori at jrc.it (Alberto Reggiori) Date: Mon Jun 7 17:02:46 2004 Subject: Action Sheets, stylesheets, and MVC References: <35A53E52.F0D91ACA@locke.ccil.org> Message-ID: <35A618E5.97EFDBA3@jrc.it> If you mean "Design Patterns" (Gang of 4 book) or SmallTalk paradigms, You can imagine that the XML infrastructure plus the XMI (XML Metadata Interchange) from IBM will allow to express well-thought and reusable object models on the Web. The Composite design pattern it is the core of XML. The Observer pattern is the MVC. The iterator, the builder, the abstract factory are already used into the DOM. ....the Object paradigm it is kicking behind the scene Alberto Reggiori xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 10 15:43:30 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:46 2004 Subject: XLF: Legacy Log Problems References: Message-ID: <35A61547.6879CF19@locke.ccil.org> Martin Gleeson wrote: > This is the one concern I have with XLF. I already do the above with my > web log analysis tool, pwebstats. And that's the problem - for example, > the logs from our proxy server are 600Mb per week, gzipped, -9, and > increasing. Whilst one of my next tasks is to have pwebstats handle > incremental updates, it still shows the scope of the problem, especially > for those who may need to keep a permanent copy of their logs for whatever > reason. An order of magnitude increase in size creates difficulties when > a feature of many logfile formats is representing the necessary information > in the smallest reasonable space. I understand your problem. However, even a 10-fold increase in uncompressed size will *not* translate into a 10-fold increase in compressed size, because most of the added material will be intensely repetitive: tags, attribute names, markup characters. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Fri Jul 10 16:29:28 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:46 2004 Subject: NOTATION FPIs (was: ) Message-ID: <001d01bdac0f$789d3ee0$1811e391@mhklaptop.bra01.icl.co.uk> ->Anyway there is a general expectation in XML that system identifiers should >be URIs and that public identifiers should be SGML FPIs. I will be pedantic again. There may be a general expectation among the XML congnoscenti, but there is no general expectation "in XML", or in the wider community who assume that XML is what the published standard says it is, nothing more and nothing less. Because the XML standard says so little about what a "Public Identifier" is (and in particular, doesn't constrain it to be either public or an identifier), we can expect to find different sub-communities using them in all kinds of different ways. Certainly XML doesn't contain any rule to stop me using the characters "IANA" in my Public Identifier, and if the rule is written somewhere else, then I'm afraid I haven't read it and don't feel bound by it. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Fri Jul 10 16:37:42 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:47 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4 Message-ID: <199807101436.QAA14289@berlin.dvs1.tu-darmstadt.de> > Big question: Do we give these elements [content model elements] id attributes > as well? It seems like > overkill to me, but I can imagine cases where it might be worth it. I say yes -- it's the equivalent of using a parameter entity to define a content model. One can imagine an XSchema where the top-level element declarations themselves are relatively useless but exist so that an XLink can refer to their content models. This is a bit hacky, but it's the only way I can see to duplicate the horiz.model and vert.model entities in John Cowan's Itsy B Bitsy Teeny Weeny Simple Hypertext DTD. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Fri Jul 10 16:49:44 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:47 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 4 Message-ID: <199807101443.QAA14418@berlin.dvs1.tu-darmstadt.de> > Major Question: Do we want Attribute declarations allowed outside of element > declarations? If yes, we need to do that here. This will be fairly minor > surgery; the AttDef element will also need a new attribute for its parent > element. The XML 1.0 spec doesn't have any such production - it just uses > Name. I vote yes. There are two reasons, both for user convenience. First, it allows multiple attribute declarations for the same element; in this case, the Element attribute of the AttList element points to the relevant ElementDecl. Second, it is a convenient shorthand for an attribute applying to all elements; in this case, the Element attribute of the AttList element is omitted. > 2.1 The XSchema Element > > [snip] > > 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. I think it would be useful to explain further why an XSchema might be nested under another XSchema. In my mind, the major reason is reusability -- this structure means that the contents of two XSchemas can simply be placed inside the contents of a third XSchema. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jul 10 17:31:43 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:47 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 4 References: <199807101443.QAA14418@berlin.dvs1.tu-darmstadt.de> Message-ID: <35A63337.8301E88C@locke.ccil.org> Ron Bourret wrote: > > Major Question: Do we want Attribute declarations allowed outside of element > > declarations? If yes, we need to do that here. This will be fairly minor > > surgery; the AttDef element will also need a new attribute for its parent > > element. The XML 1.0 spec doesn't have any such production - it just uses > > Name. > > I vote yes. There are two reasons, both for user convenience. First, it allows > multiple attribute declarations for the same element; in this case, the Element > attribute of the AttList element points to the relevant ElementDecl. Second, it > is a convenient shorthand for an attribute applying to all elements; in this > case, the Element attribute of the AttList element is omitted. I agree. > I think it would be useful to explain further why an XSchema might be nested > under another XSchema. In my mind, the major reason is reusability -- this > structure means that the contents of two XSchemas can simply be placed inside > the contents of a third XSchema. Nested XSchemas also allow you to precisely specify the scope of Doc elements. -- 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 Fri Jul 10 17:39:33 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:47 2004 Subject: Dates in XML Message-ID: <199807101538.RAA15381@berlin.dvs1.tu-darmstadt.de> Peter Murray-Rust wrote: > ... > I was looking at the XML-Data proposal just today and thinking 'why don't > we use the primitives it defines, just as they are, without the rest of > XML-data?'. This encourages me to offer the question to a wider audience. I > am seriously missing a specification for primitives - what do other people > think about borrowing those from XML-data? Absolutely. For XSchema 1.1, I vote for a dt:dt attribute on the PCData element. The XML-Data spec shows the following ways to specify data types: Attribute: 8 Subelement: 8 Schema: I believe we should only adopt the first of these for now. While there are no technical problems with the second, it seems counter to the spirit of XML: We are now most closely labeling the value 8 as an int, rather than as a size, which is what it really is. The third is just plain confusing because the datatype subelement is not part of the content model. For example, what does the following XML-Data declaration mean? The sequence is an integer? I can imagine datatype elements as a substitute for content models, but not in addition to them. Anything I'm missing here? -- 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 Fri Jul 10 17:47:37 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:47 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4 References: <199807101436.QAA14289@berlin.dvs1.tu-darmstadt.de> Message-ID: <35A6372D.64AF38CD@locke.ccil.org> Ron Bourret wrote: > One can imagine an XSchema where the top-level element declarations themselves > are relatively useless but exist so that an XLink can refer to their content > models. This is a bit hacky, but it's the only way I can see to duplicate the > horiz.model and vert.model entities in John Cowan's Itsy B > Bitsy Teeny Weeny Simple Hypertext DTD. Very kludgy indeed. I have one new proposal and one old one. I'm thinking that several more elements should be allowed at top level, namely AttDef, Choice, Sequence, Mixed, NotationType, and EnumerationType. These would then exist as free-floating resources which could be referred to by idrefs elsewhere. The old proposal is for an AttGroup element, with a content model of (Doc?, AttDef+), and available at top level and also within an Element model. This would allow multiple attributes to be treated as a single thing for either documentation or reference. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Fri Jul 10 18:21:14 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:47 2004 Subject: XCatalog proposal draft 0.1 Message-ID: <35A63F3B.7EDA9DBC@locke.ccil.org> This is a proposal for XCatalogs, a system based on SGML/Open catalogs (Socats) for translating public identifiers to system identifiers in XML. 1. Introduction XCatalogs are Web resources (anything from local files on up) which contain mappings from public identifiers to system identifiers, plus references to other XCatalogs. They come in two syntaxes: one which is a subset of Socat syntax, and one which is an XML document instance. 2. Example Here's an example XCatalog in both syntaxes, for those who learn best from examples: -- catalog for "-//John Cowan" public IDs -- BASE "http://www.ccil.org/~cowan/" PUBLIC "-//John Cowan//ConScript Unicode Registry//EN" "csur/" PUBLIC "-//John Cowan//Essentialist Explanations//(EN,X-BRITHENIG)" "essential.html" PUBLIC "-//John Cowan//Lojban" "http://xiron.pc.helsinki.fi/lojban/" DELEGATE "-//John Cowan//LOC Diacritics" "elsie/xcatalog.soc" CATALOG "http://www.w3.org/xcatalog/mastercat.soc" catalog for "-//John Cowan" public IDs 3. Socat syntax The BNF for the Socat syntax is: Document ::= Comment? WS? (Entry (WS Entry)*)? WS? Comment? Entry ::= Map | Delegate | Extend | Base | Other Map ::= "PUBLIC" WS PubidLiteral WS SystemLiteral Delegate ::= "DELEGATE" WS PubidLiteral WS SystemLiteral Extend ::= "CATALOG" WS SystemLiteral Base ::= "BASE" WS SystemLiteral Other ::= Name (WS Name)? (WS SystemLiteral)* WS ::= S (Comment S)* Comment ::= "--" ([^--])* "--" where Name, PubidLiteral, SystemLiteral, and S are as in XML 1.0. 4. DTD The DTD for the XML instance syntax is (where an XCatalog element is the root): In the XML instance syntax, any #PCDATA content is considered comment, and any other elements that may be present are beyond the scope of this specification. For uniformity below, the Map, Delegate, Extend, and Base elements are referred to as "entries". 5. Entry semantics Map entries (which use the keyword "PUBLIC" in the Socat syntax for backward compatibility) mean that a public identifier which exactly matches the public-identifier attribute should be translated into the entry's system-identifier attribute. Delegate entries are used to delegate groups of public identifiers to other catalogs. Public identifiers for which the public-identifier attribute is an exact prefix are listed in the XCatalog specified by the system-identifier attribute Extend entries (which use the keyword "CATALOG" in the Socat syntax for backward compatibility) allow additional catalogs to be specified as extensions to this catalog. The system-identifier attribute specifies an XCatalog. Base entries are used in the same way as BASE elements in HTML: to specify the base URL for any relative URLs in system-identifier attributes. 7. Search algorithm The process of searching catalogs in order to translate a public identifier into an URI is as follows. A queue of XCatalog URIs is maintained, which is initialized with a system-dependent list of URIs. A current base URL is also maintained, initially null. A catalog URI is dequeued and the specified XCatalog is fetched. The current base URL is set to the base of the catalog by removing the least significant part of the URI. The XCatalog is then searched from beginning to end looking for a matching Map or Delegate entry. A matching Map entry (exact match) causes the process to terminate, returning the system-identifier attribute (modified if necessary by the current base URL). A matching Delegate entry (prefix match) causes the current queue to be cleared and the system-identifier attribute (modified if necessary by the current base URL) entered as the only entry; the rest of the current XCatalog is ignored. As Catalog entries are seen, their system-identifier attributes are appended to the catalog URI queue. As Base entries are seen, the current base URL is reset to the system-identifier attribute. Comments and Others are ignored. When an XCatalog has been completely scanned, the next XCatalog URI is dequeued and fetched and the current base URL reset, and the process repeated. When no further XCatalog URIs remain in the queue, the process fails: the public identifier cannot be translated. 8. Open questions Should compliance require support for both syntaxes? I think the Socat syntax is essential for backward compatibility with existing tools, and it is more compact (important for huge catalogs full of Delegate entries), but the XML instance syntax is more in the spirit of XML (and XSchema, etc.). If both syntaxes are supported, should Delegate and Extend entries be allowed to refer from one syntax to another, or should Socat catalogs refer only to other Socat catalogs and ditto for XML instance catalogs? -- 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_Goerwitz at Brown.EDU Sun Jul 12 11:35:14 1998 From: Richard_Goerwitz at Brown.EDU (Richard Goerwitz) Date: Mon Jun 7 17:02:47 2004 Subject: XCatalog proposal draft 0.1 References: <35A63F3B.7EDA9DBC@locke.ccil.org> Message-ID: <35A690BC.DB2A9654@Brown.EDU> John Cowan wrote: > XCatalogs...come in two syntaxes: one which is a subset of Socat > syntax, and one which is an XML document instance. Seeing as they are typically metadata used to bootstrap DTD-based XML processing, I don't believe that catalogs should require a DTD - or, worse yet, have a hard-coded format or tag and attribute set. Insofar as catalogs have any rigidly defined format, I'd think that this format should consist at most of comments, a few keywords, and quoted strings. It would be nice if XML could kind of take over the world. But one of the reasons it has become popular is that it is (was?) fairly straightforward and simple. Actually, the popularity issue may be moot. We have to keep in mind that it's still hard just to find valid XML 1.0 instances on the net. -- Richard Goerwitz PGP key fingerprint: C1 3E F4 23 7C 33 51 8D 3B 88 53 57 56 0D 38 A0 For more info (mail, phone, fax no.): finger richard@goon.stg.brown.edu xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Sun Jul 12 12:23:13 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:47 2004 Subject: XCatalog proposal draft 0.1 Message-ID: <002301bdac2e$5ec6c580$1211e391@mhklaptop.bra01.icl.co.uk> >This is a proposal for XCatalogs, a system based on SGML/Open >catalogs (Socats) for translating public identifiers to >system identifiers in XML. Excellent. If my petulant pedantry in any way provoked this positive proposal, I am proud to give John by profound praise. Mike xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Sun Jul 12 12:42:15 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:02:47 2004 Subject: Message-ID: <3.0.32.19980711092053.009d3c04@postoffice.swbell.net> At 07:14 AM 7/9/98, Peter Murray-Rust wrote: >At 21:57 08/07/98 -0500, W. Eliot Kimber wrote: >[...] >>If somebody wanted to write the two-page spec for the mechanism, I'd be >>happy to learn Java sufficient to write a reference implementation. > >Agreed. My impression is that the nitty-gritty of associating FPIs/URLs, >etc with code is: > - not terrifyingly difficult (like many others I have built SGML catalog >software) > - unlikely to come directly out of W3C efforts >in which case it could be an excellent thing for XML-DEV to run with. The >important thing is to agree communally on how to do it. I would see this as >a logica next step after XSchema. > I hope my mail didn't seem negative - I'm delighted to use NOTATION IFF: > - other people are keen on using it > - we agree on a software spec > - there is a communal implementation Cool--I didn't mean to be testy in my initial responses--just in a bad mood generally last week. The think about notations as opposed to MIME types is that notations are a more general mechanism, not tied to any particular use domain, while MIME types are designed specifically to make things work smoothly on the Internet. Nothing wrong with that, but I just prefer the more general solution as a rule (but I'm like that). Because MIME types can be associated with notations (say by using the MIME type as the public or system identifier for the notation), the two mechanisms can be complimentary. Ideally, XML and SGML would have a mechanism for declaring specialized forms of notations, which would better reflect the way we use notations in the HyTime standard, for example. In HyTime, we defined several distinct types of notations: queries, storage managers, etc. It would be nice to be able to do something like: The " W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Sun Jul 12 12:42:18 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:02:47 2004 Subject: What are data attributes (was Re: ) Message-ID: <3.0.32.19980711100020.00cf2d50@postoffice.swbell.net> At 02:33 PM 7/9/98 -0400, John Cowan wrote: >W. Eliot Kimber wrote: > >> This is what notations are for (unfortunately, by choosing not to include >> data attributes, XML has severely limited the utility of the notation >> feature, but I'm sure that will be corrected). > >What are data attributes? In SGML, you can declare attributes for a notation and then use those attributes as part of a data entity declaration or (using the "Data attributes for elements" (DAFE) facility of the General Architecture [part of the SGML Extended Facilities published in ISO/IEC 10744:1997 ]) on elements governed by that notation. They are called "data attributes" because they are attributes of data entities (or, more generally, data governed by a notation processor), rather than attributes of elements. They are often coloquially referred to as "notation attributes", which isn't a bad name, it's just not the one the SGML standard chose. The idea is that the attributes act as parameters to the notation processor, whether the processor is processing a data entity, element, or attribute value. A typical example would be an attribute that influences the interpretation of a graphic, represented by a data entity: ]> In the HyTime architecture, through the DAFE mechanism, we use data attributes as a way to associate attributes of elements with their corresponding data attributes. The SGML standard doesn't define a mechanism by which element attributes and data attributes are correlated, so we had to invent the DAFE facility to define the correlation mechanism we needed for HyTime's purposes (feeling fairly certain that other applications would find it useful, which is why it's part of the General Architecture and not the HyTime architecture). The rule is very simple: if an element is governed by a notation (because it exhibits a NOTATION attribute) AND that notation has attributes AND the element exhibits attributes whose names match those of the notation's attributes THEN the attributes are taken to be instances of the notation's attributes. This means, for example, that when you pass an element to a notation processor it can, with confidence, interpret any attributes it recognizes as being those defined by the notation it implements. Without this facility, any name matches between element attributes and notation attributes might be coincidental and you would have no way of disambiguating name clashes as notation attributes and element attributes are separate name spaces. The facility also provides a name remapping facility that is just like the architecture name remapping facility (which is just like the one defined by Xlink). HyTime uses notations to define types of queries that are then used with elements (or attributes) that represent query instances (the "queryloc" element form and location type in the HyTime architecture). If you want to define a query that can take arguments (say a canned query for a specific purpose), you can use attributes to pass the arguments in a well-defined way. First, I define a notation that represents my query. A typical example would be a query that finds all elements of a particular type: ]> See all the sections of this document When a HyTime engine examines this document, it will perform the following processing: 1. It will see that the Elements-with-GI-Queryloc is a HyTime queryloc (because of the value of the HyTime attribute). 2. It will expect to find an attribute called "notation" whose value is the name of a notation declared in the same document. 3. It gets the notation name (Elements-with-GI) and looks up the notation declaration. 4. It goes to its "notation processor" table to see if there is a processor (DLL function, COM object, JavaBean, etc.) associated with the public ID "Query that returns all elements with a given GI within location source". 5. It finds a processor and passes it a pointer to the element object (grove node, DOM node, whatever). It expects to get back a node list (or its equivalent) representing the results of the query. It waits for that result. Upon being called, the notation processor does the following: 1. Looks at the element to see if there is a GI attribute specified. It knows to do this because it embodies the knowledge of the rules for the notation, including the fact that it takes a GI attribute. It knows this either because the programmer who created it knew it or because it examines the notation declaration and sees that there's an attribute declared for it as well. It depends on how generalized the processor is. 2. Sees that there is a GI attribute and, because this system implements the DAFE facility and because the document declares that it is using it (options="queryloc dafe") knows that it can interpret the GI attribute as its GI parameter. 3. It takes the value of the GI attribute ("Section"), performs its query, and returns the result to the HyTime engine. Upon being returned to (or called back), the HyTime engine takes the resulting node list and does whatever it does with it. If the address was used to define the members of a link anchor, as it is in this example, it would use the node list to populate the "anchored objects" property of that anchor, for example (using the terminology of HyTime's abstract data model for representing link-related information). The process I've described is no different from what people have been doing for years in SGML and HTML and XML, it's just that we've slapped a little layer of standardized syntax and semantics on it to enable wider generalization. It does, however, depend on the data attributes facility, which the XML WG, over my strong personal objection (for what that's worth), elected not to include in XML. Cheers, Eliot --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From andrewl at microsoft.com Sun Jul 12 12:46:31 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:02:47 2004 Subject: Data Types (was: RE: Dates in XML) Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA5CD@red-msg-08.dns.microsoft.com> Tim Bray suggests that there are too many datatypes defined. What is your opinion on 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 peter at ursus.demon.co.uk Sun Jul 12 12:50:35 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:47 2004 Subject: XCatalog proposal draft 0.1 In-Reply-To: <35A63F3B.7EDA9DBC@locke.ccil.org> Message-ID: <3.0.1.16.19980710212844.b4afe5a6@pop3.demon.co.uk> At 12:20 10/07/98 -0400, John Cowan wrote: >This is a proposal for XCatalogs, a system based on SGML/Open >catalogs (Socats) for translating public identifiers to >system identifiers in XML. I haven't read this in detail, but support the idea. I had to write some catalog software before XML and found it remarkable that SGML could have so many different syntaxes for a single language: - declaration - DTD - catalog - document instance and - stylesheet (though this wasn't standardised anyway). If we can reduce the syntax to one, great. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Jul 12 12:56:49 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:47 2004 Subject: Merging Object Oriented Design and SGML Architectures Message-ID: <3.0.1.16.19980710210029.bf2f26a8@pop3.demon.co.uk> [From Liora Alschuler] >X-Sender: liora@sover.net >X-Mailer: Windows Eudora Pro Version 2.2 (32) >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Date: Fri, 10 Jul 1998 09:55:48 -0400 >To: "Amit Rekhi" , "XML Mail List" >From: Liora Alschuler >Subject: >Cc: lloyd@infoauto.com > >Amit, > >You might be interested in >http://www.infoauto.com/articles/arch/rim/oo-sgml.htm by Lloyd Harding. It >is written in terms of a specific OO design (from the healthcare stds org >HL7), but with the intent to address the general question you raise. > >Liora > > >At 06:42 PM 7/10/98 +0530, Amit Rekhi wrote: >>Hello, >> Could anyone please guide to articles/technical notes regarding >OOD and SGML Architectures. >> Any help will be greatly appreciated >> Thanx, >> >> >AMIT >> Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Jul 12 12:59:49 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:47 2004 Subject: LISTRIVIA (was Re: Merging Object Oriented Design and SGML Architectures) In-Reply-To: <001701bdac08$d940a450$0201a8c0@amit.abinfosystems.com> Message-ID: <3.0.1.16.19980710213035.b4af9db8@pop3.demon.co.uk> At 18:42 10/07/98 +0530, [a poster] wrote: [...] > > >Attachment Converted: "c:\eudora\attach\MergingO.htm" Please try to avoid attachments of any sort on this list. Thanks. 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 ricko at allette.com.au Sun Jul 12 13:19:40 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:48 2004 Subject: NOTATION FPIs (was: ) In-Reply-To: <001d01bdac0f$789d3ee0$1811e391@mhklaptop.bra01.icl.co.uk> Message-ID: <000701bdac43$984c5e90$83bc38cb@NT.JELLIFFE.COM.AU> > From: Michael Kay > ->Anyway there is a general expectation in XML that system > identifiers should > >be URIs and that public identifiers should be SGML FPIs. > > I will be pedantic again. There may be a general expectation > among the XML congnoscenti, but there is no general > expectation "in XML", or in the wider community who assume > that XML is what the published standard says it is, nothing > more and nothing less. While I certainly agree that this should be spelled out in the XML spec, I disagree that about the distinction between "XML cogniscenti" and "XML" to an extent. It seems to me the way of the world that a technology and its human hosts cannot be divided. Unless a standard is about something trivial or unless the writers of the standard have perfect knowledge of the presuppositions of its readership, then a specification will always be incomplete (especially initially). It would be nice if a spec was presented complete like Moses' tablets, but actually when there is incompleness it will be subject to * iterative revisions, or * an "eldership/judges" system of dispute resolution, or * a Maoist/NRA "all power comes from from the barrel of a gun" system where the implementation from the largest players determines practise, or * some additional regulation system (e.g. extra TRs at w3.org), or * some communal agreement system like XML-DEV voting, or * anarchy. It has long been the bane of international standards that people treat incompleteness in standards as surprising flaws rather than expected incompleteness which must be constructively dealt with -- in the case of international standards, national bodies can request the international committees to clarify matters. Maybe the attitude is a sign of a text-based society rather than a human-interaction-based society in the West. Of course, specifications should be as complete as possible; but the expectation that they will be complete and therefore you dont need "congniscenti" is unrealistic, IMHO. (This is nothing more than the traditional criticism of non-iterative waterfall models where analysis and design and implementation cannot feedback, so I don't think it is a radical view.) 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 Sun Jul 12 13:19:48 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:48 2004 Subject: Merging Object Oriented Design and SGML Architectures In-Reply-To: <001701bdac08$d940a450$0201a8c0@amit.abinfosystems.com> Message-ID: <000201bdac40$c2549750$83bc38cb@NT.JELLIFFE.COM.AU> The big fat Cue book (I think it is called "Using SGML") has a chapter relating Smalltalk to SGML. Steve Newcomb has pointed out (reference lost-sorry) that SGML/XML and OO to a large extent have dissimilar goals, in that SGML/XML (i.e. generic markup) are attempts to (allow you to) have your data INDEPENDENT of particular methods while OO is an attempt to bundle methods with data. However, since the introduction of the PI target in XML, it is better to say that SGML/XML are attempts to (allow you to) have your data in a form which allows multiple methods to be attached. The big fat Holzer book (I think it is called "XML Complete") is full of code and analysis relating Java to XML. (But the reviews on amazon.com suggest that it may relate to a superceded version of MSXML too much.) In a sense, a lot of the questions about OO and XML may already be answered, in that XML/SGML embody a particular document system design methodology (i.e. generalized markup) and because common parsers will be using three APIs: * SAX, which XML-DEV contributed to * DOM, see www.w3.org/TR * GROVES: this is the big daddy of them all, and is not so much an API as an analysis of the properties needed for a complete and general SGML/XML/HyTime "parse tree". (In fact any data format whcih can be parsed into a tree with inter-node directed-graph arcs can be represented by GROVE, e.g. CGM the graphics format. Using the same GROVE concept allows navigation languages like Xptr to be defined that can locate particular nodes in the tree, regardless of what notation the tree was parsed from.) The GROVES information is at http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-7.1.html#clause-7.1.4 might be useful place to start. My big fat book, The XML and SGML Cookbook, does not have much OO in it (intentionally: there is no progamming code in it). Instead have put in chapter 3 "Software Engineering" a summary of various methodologies used in practise for developing DTDs. This is because once you have the generalized model OK, you can add methods (explicitly by using #FIXED attributes in the DTD, or by invoking a CSS-like stylesheet where there is an element type to contain mthod code or location, or by using PIs.) So the emphasis is that the more richly and appropriately your data is marked up, the less programming work (including OO analysis and design) there is to do. There is a widespread feeling in the SGML world that you should mark up data independent of any particular use of it. However, I certainly believe that a good DTD design will be informed by the known and potential uses of the data. In a way it comes down to whether you view XML as a "serialization format" format, where it is just dumping data from a known schema and known application, or whether it is "markup language" where you want to expose interesting and useful information to make life simpler for future software development. Rick Jelliffe -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Amit Rekhi Sent: Friday, 10 July 1998 23:12 To: XML Mail List Subject: Merging Object Oriented Design and SGML Architectures Hello, Could anyone please guide to articles/technical notes regarding OOD and SGML Architectures. Any help will be greatly appreciated Thanx, AMIT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980712/4d45a705/attachment.htm From andrewl at microsoft.com Sun Jul 12 13:44:29 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:02:48 2004 Subject: Dates in XML Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA5C2@red-msg-08.dns.microsoft.com> This all sounds sensible to me. -----Original Message----- From: rbourret@dvs1.informatik.tu-darmstadt.de [mailto:rbourret@dvs1.informatik.tu-darmstadt.de] Sent: Friday, July 10, 1998 8:38 AM To: xml-dev@ic.ac.uk Subject: Re: Dates in XML Peter Murray-Rust wrote: > ... > I was looking at the XML-Data proposal just today and thinking 'why don't > we use the primitives it defines, just as they are, without the rest of > XML-data?'. This encourages me to offer the question to a wider audience. I > am seriously missing a specification for primitives - what do other people > think about borrowing those from XML-data? Absolutely. For XSchema 1.1, I vote for a dt:dt attribute on the PCData element. The XML-Data spec shows the following ways to specify data types: Attribute: 8 Subelement: 8 Schema: I believe we should only adopt the first of these for now. While there are no technical problems with the second, it seems counter to the spirit of XML: We are now most closely labeling the value 8 as an int, rather than as a size, which is what it really is. The third is just plain confusing because the datatype subelement is not part of the content model. For example, what does the following XML-Data declaration mean? The sequence is an integer? I can imagine datatype elements as a substitute for content models, but not in addition to them. Anything I'm missing here? -- 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) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jubrown at projectcool.com Sun Jul 12 14:50:12 1998 From: jubrown at projectcool.com (Julie Brown) Date: Mon Jun 7 17:02:48 2004 Subject: XML--I need advice on an XML tutorial I wrote Message-ID: <000f01bdac4c$c9cba3a0$0a490ece@pluto.projectcool.com> Hi everyone! The company I work for, Project Cool.com, is about to release a tutorial on XML. I've been writing the first section of this area. It's called the XML QuickStart and it's part of an "XML Developer Zone" teaching web designers and developers how to use XML in their web sites. We'd like to have people who have been working with XML take a look at the site before it goes live. The Quickstart shouldn't take you more than 5 or 10 minutes to read. Here's the URL: http://www.projectcool.com/developer/xmlpub It is designed as an overview, but we still want to be sure that: the information is accurate, it makes sense and it gives people enough information on XML to determine whether they want to use it. Is this something you'd tell a just-assigned-to-your-XML project designer who has never worked with XML to read as basic background? Keep in mind that this is an introductory section. Over the next few months we'll have more tutorials that range from basic XML to advanced XML (and XSL, etc.) The purpose of this introductory section is to demystify and demythify XML. It's a dipping the toe in the water introduction. We're holding back on explicit definitions of Valid, Well-Formed, DTDs, and components until our next tutorial. In fact, we've avoided anything that the average web designer (think: fine arts student) might think is "scary." Thanks in advance for your help in making XML accessible to more web developers!! Check out http://www.projectcool.com/developer to see examples of our other Developer Zones. Thanks! Julie Brown xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ht at cogsci.ed.ac.uk Sun Jul 12 15:28:11 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:02:48 2004 Subject: Beta of XED, and XML instance editor, now available Message-ID: <8820.199807121328@mcilvanney.cogsci.ed.ac.uk> A new release of XED is now available, with bug fixes, additional features and improved installation packaging for WIN32 platforms. See http://www.ltg.ed.ac.uk/~ht/xed.html for details and download information. Notable changes since the last announcement include * Refilling of text content and indenting of element content on request; * Accented character support (ISO-8859-1); * An experimental file processing facility: you can now invoke processing of your file, and XED will then step you through any validation or application errors which are logged. Expects UN*X/gcc/emacs error line format, which e.g. nsgmls produces, so nsgmls and jade are both obvious candidates to use here. Thanks to all alpha users for much helpful feedback. ht xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sun Jul 12 17:09:34 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:48 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 4 Message-ID: At long last, here is the revised Attribute Declarations section. Note that it provides for attributes to be declared outside of XSC:ElementDecl elements, and uses attributes instead of child elements to make its declarations. I also gave XSC:AttDef an id attribute. This draft underwent some drastic changes based on XML-Dev discussions; I'm suspecting that there are more mistakes in here than usual. Please read it closely. There are some changes in other sections that need to be made, like Name vs. name as an attribute for XSC:ElementDecl. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.4 Attribute Declarations 2.4.1 Overview Attribute declarations are made with empty XSC:AttDef elements. XSC:AttDef elements may be nested inside of XSC:ElementDecl element declarations or linked to element. The data type of an attribute is defined with an attribute, as is a declaration of whether or not it is required and a possible default value. In XSchema 1.0, an attribute declaration (XSC:AttDef element) may be nested within the element declaration (XSC:ElementDecl element) for the element to which the attribute belongs. If the XSC:AttDef element appears nested inside an XSC:ElementDecl element, the Element attribute must be ignored. If the XSC:AttDef element appears nested under the XSC:XSchema element, the Element attribute should contain a name token corresponding to the Name attribute of the element to which this attribute applies. The Name attribute of the XSC:AttDef element provides the name by which the attribute will be identified. A nested declaration is shown below. ...additionalElementInformation... This declares an element with the name Species that has an attribute named status. If the status attribute was declared outside of the Species element declaration, the declarations would appear as shown below. ...additionalElementInformation... ... Merely naming an attribute may be adequate. Attribute declarations may identify data types and provide information about whether the attribute is required. By default, attributes will be assumed to contain character data (CData), not be required, and have no default value. This information is declared using additional attributes. The simplest attribute declaration possible identifies an attribute as containing character data (CData) and allows the attribute to be optional, as shown below. Applications may also use the id attribute to provide unique identifiers for attribute declarations using values that are unique within the XSchema. 2.4.2 Attribute Types XSchema 1.0 provides equivalents for all of the XML 1.0 DTD attribute types. All of them are declared using attribute values within the XSC:AttDef element. The CData attribute type is one of the most common, permitting an attribute to contain character data as defined by the XML 1.0 specification. If the Species element were to contain an attribute providing the Latin name of the species, the declaration could look like the following. (The Type attribute could actually be omitted in this case, as CData is the default type.) ...additionalElementInformation... This attribute would then be available for use in instances of the Species element: ...additionalContent... The ID attribute type is used to uniquely identify elements in a document for application processing. IDRef and IDRefs attribute types are used to refer to a single ID value in the same document or multiple ID values in the same document, separated by whitespace, respectively. These attribute declarations should be used with the same constraints as apply to ID, IDREF, and IDREFS attribute types in XML 1.0. The Entity and Entities attribute types identify the names of unparsed entities. The use of these attribute types should be made with the same constraints as apply to the ENTITY and ENTITIES attribute types in XML 1.0. If a document is checked directly against an XSchema without a conversion to a DTD, information regarding unparsed entities must be available from the parser for these attribute types to be meaningful. The Nmtoken and Nmtokens attribute types are used to declare attributes that must contain information conforming to the Nmtoken and Nmtokens productions in XML 1.0. The Notation and Enumerated attribute types are more complex, requiring an Enumeration attribute to identify their possible content. These two declarations use similar syntax, but the allowed values of Notation declarations must match the Notations declared elsewhere in the XSchema document. If the status attribute of the Species element were to allow the values of extinct, endangered, protected, and non-threatened, an appropriate enumerated type declaration would look like: ...additionalElementInformation... A Species element created conforming to this declaration might look like: ...additionalContentAboutDodos... 2.4.3 Attribute Defaults XSchema requires attribute declarations to provide information about the default value of a given attribute. XSchema provides for the four cases supported by XML 1.0: #REQUIRED, #IMPLIED, #FIXED AttValue, and AttValue, though they are expressed as choices between required and not required and fixed or not fixed, with an optional default value. There may be only one default value declaration per attribute. Required attributes (identified in XML 1.0 by #REQUIRED) are identified by assigning the value "Yes" to the Required attribute of an XSC:AttDef element. For instance, if the Latin attribute described above was required by the Species element, the XSC:AttDef element would contain a Required attribute: ...additionalElementInformation... Optional attributes (identified in XML 1.0 by #IMPLIED) are identified assigning the value "No" to the Required attribute of an XSC:AttDef element and not assigning a value to the AttValue attribute. Implied indicates that there is no default value provided, and also that no value is required. If the Latin attribute is optional, the XSC:AttDef element would contain an XSC:Implied element: (Note that this is the default status and the Required declaration does not need to be made explicitly.) ...additionalElementInformation... Fixed attributes (identified in XML 1.0 by #FIXED AttValue) are identified through the use of the Fixed attribute and the AttValue attribute, which contains the fixed value for the attribute. Attributes declared using fixed value cannot declare a different value for that attribute. Fixed effectively hard codes attribute values into particular elements. If the Species element had a planet attribute, a Fixed attribute given the value of "Yes" would identify the fixed nature of the attribute and the AttValue attribute would provide the value. ...additionalElementInformation... Attributes may also be provided with a default value that may be overridden by other declarations. These default values are identified through the use of the AttValue attribute. The status attribute of species elements described above would be an appropriate target for such a default value, especially if most species being described fell into a particular category: ...additionalElementInformation... Any type of default (required, fixed, etc.) may be used with any attribute type, though default values should always correspond to acceptable values for the attribute type. This notation also permits the declaration of certain attributes (IDs with defaults, for instance) that are prohibited by the standard XML 1.0 DTD syntax. Developers who use these combinations should be certain that their documents will work in DTD-only environments as well as XSchema environments. An XSchema processor that produced normalized-for-DTD use documents could expand these default values and include them in document instances for use with DTD-only environments. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 12 17:09:45 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:48 2004 Subject: Message-ID: W. Eliot Kimber wrote a long time ago: >This is not true. You can include any kind of data in an XML document, >including scripting languages. What there is not is a standard or >convention for interpreting any particular script language. But XML gives >you everything you need to *declare* the script you're using sufficient to >allow processing programs to recognize the fact of script use and do >whatever it is they do. >[material skipped] > > Script//EN" > > > (#PCDATA) > > > notation > NOTATION > (JavaScript) JavaScript > > > ... > ]> > > > Erp. Doesn't this (because of the #PCDATA) still leave out all those scripts that use < and > for something other than document markup? Really inconvenient, if so. 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 Sun Jul 12 17:13:30 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:48 2004 Subject: XSchema Specification - Notations (Section 2.5), Draft 3 Message-ID: Here's the latest Notations draft. It now sports an XSC:More element and uses attributes instead of child elements for its content. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.5 Notation Declarations Notation declarations are made with XSC:Notation elements nested in the XSC:XSchema element. Notations may include Public Identifier or a system literal, or both. XSchema processors should ignore XSC:Notation elements that contain neither. Public Identifiers and system literals should conform to the rules in Section 4.7 of the XML 1.0 Specification. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 12 17:13:56 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:48 2004 Subject: XSchema Spec - Extensions (Section 2.6), Draft 2 Message-ID: Here's the latest draft on Extensions for XSchema. I cleaned up some bits regarding IBTWSH. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.6 XSchema Extensions XSchema provides areas in which XSchema developers can provide supplemental information and metadata regarding XSchema components in both human- and machine-readable formats. Human-readable information is provided through the use of a subset of HTML that conforms to XML syntax, while machine-readable information may be provided through the XSC:More element. 2.6.1 Documentation Extensions Human-readable documentation for XSchemas should be provided using the Itsy Bitsy Teeny Weeny Simple Hypertext (IBTWSH) format created by John Cowan. The full DTD is available at http://www.ccil.org/~cowan/XML/ibtwsh.dtd. Documentation that uses portions of the IBTWSH format may be included in the XSC:Doc element, a subelement available to all declarations. The XSC:Doc element provides basic formatting options for XSchema documentation. %ibtwsh; Any element allowed in the horiz.model set of elements (A, BR, SPAN, XML, CITE, CODE, DFN, EM, KBD, SAMP, STRONG, VAR, FONT, or parsed character data) may be used in the XSC:Doc element. Note that IBTWSH does not use namespaces in order to preserve compatibility with HTML. XSchema applications should ignore all XSchema declarations (i.e., elements prefixed with XSC: or the appropriate XSchema prefix) within an XSC:Doc element. 2.6.2 Other Extensions The XSC:More element provides an area which developers can use to create their own supplements to XSchema, defining content types more tightly than is possible through XSchema 1.0. The XSC: More element has a simple ANY content model, though XSchema processors should ignore the appearance of any elements from the XSchema namespace in this area. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Sun Jul 12 17:27:31 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:02:48 2004 Subject: XML--I need advice on an XML tutorial I wrote Message-ID: <3.0.32.19980712082817.00a57588@pop.intergate.bc.ca> At 02:50 PM 7/10/98 -0700, Julie Brown wrote: >Is this something you'd tell a just-assigned-to-your-XML project designer >who has never worked with XML to read as basic background? Attractive design & layout. Extremely thin on content. Problems: 1. "You'll still need DHTML or JavaScript to make images fly around on your page or to define font colors. " Stylesheets are the right way to do colors and XML doesn't change that. 2. cyan on orange is a lousy color combination 3. It's not obvious how XML's 10 design goals were boiled down to 3. Why those 3? 4. " " Wrong. Read the spec. 5. The page entitled "Well-Formed XML" has a big problem. It defines thing called "Components" and "Rules" which I think are sorta kinda like elements and declarations... inventing new names for the central things of XML is only going to make the readers of this page unable to communicate with people who read any other XML intro. Uh, might it be a good idea to introduce basic concepts like "elements" and "attributes" xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Sun Jul 12 17:56:00 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:02:49 2004 Subject: XML--I need advice on an XML tutorial I wrote Message-ID: <01bdadad$d9a10d80$05addccf@bckman.ix.netcom.com> I think it would have been fairer to point out that xml should be lower case! is correct " " > >Wrong. Read the spec Prolog [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? [23] XMLDecl ::= '' [24] VersionInfo ::= S 'version' Eq (' VersionNum ' | " VersionNum ") [25] Eq ::= S? '=' S? [26] VersionNum ::= ([a-zA-Z0-9_.:] | '-')+ [27] Misc ::= Comment | PI | S Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com -----Original Message----- From: Tim Bray To: Julie Brown ; xml-dev@ic.ac.uk ; dturner@microsoft.com ; stevsk@microsoft.com Date: Sunday, July 12, 1998 11:29 AM Subject: Re: XML--I need advice on an XML tutorial I wrote > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Philippe.Le_Hegaret at sophia.inria.fr Sun Jul 12 18:10:45 1998 From: Philippe.Le_Hegaret at sophia.inria.fr (Philippe Le Hégaret) Date: Mon Jun 7 17:02:49 2004 Subject: XML--I need advice on an XML tutorial I wrote References: <3.0.32.19980712082817.00a57588@pop.intergate.bc.ca> Message-ID: <35A8DFDC.DE396EE6@sophia.inria.fr> Tim Bray wrote: > 4. " " > > Wrong. Read the spec. And the end tag too ... Philippe. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eliot at isogen.com Sun Jul 12 18:24:38 1998 From: eliot at isogen.com (W. Eliot Kimber) Date: Mon Jun 7 17:02:49 2004 Subject: Message-ID: <3.0.32.19980712112101.00b4ab0c@postoffice.swbell.net> At 03:09 PM 7/12/98 UT, Simon St.Laurent wrote: >> >> >> > >Erp. Doesn't this (because of the #PCDATA) still leave out all those scripts >that use < and > for something other than document markup? Really >inconvenient, if so. You can always put them inside a CDATA marked section or escape the markup characters--that's normal XML stuff. You can also put the script outside the document in a data entity or use something like Action Sheets. Cheers, E. --
W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Jul 12 19:23:33 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:49 2004 Subject: LISTRIVIA (RE: Merging Object Oriented Design and SGML Architectures) In-Reply-To: <000201bdac40$c2549750$83bc38cb@NT.JELLIFFE.COM.AU> References: <001701bdac08$d940a450$0201a8c0@amit.abinfosystems.com> Message-ID: <3.0.1.16.19980712131218.088f91ce@pop3.demon.co.uk> At 06:24 11/07/98 +1000, [a revered and prolific XML-DEVer] wrote: [... a valuable message ...] >Attachment Converted: "c:\eudora\attach\REMergin.htm" and attached it as HTML as well. This means I got a second copy (7+ Kbytes) which I didn't need and had to be paid for with real money. Please remember on XML-DEV: - no attachments (even if you use a browser to create replies) - excise *all* unnecessary quoted material and almost never include the whole posting to which you are replying. Never quote the XML-DEV sig. - do not reply to the poster (unless specifically requested) - only to the list. - many readers do not have EN as their first language P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Jul 12 19:26:54 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:49 2004 Subject: Role of CATALOGs (was Re: ) In-Reply-To: <3.0.32.19980711092053.009d3c04@postoffice.swbell.net> Message-ID: <3.0.1.16.19980712130253.348f5456@pop3.demon.co.uk> At 10:29 11/07/98 -0500, W. Eliot Kimber wrote: [...] > >The think about notations as opposed to MIME types is that notations are a >more general mechanism, not tied to any particular use domain, while MIME >types are designed specifically to make things work smoothly on the >Internet. Nothing wrong with that, but I just prefer the more general >solution as a rule (but I'm like that). Because MIME types can be >associated with notations (say by using the MIME type as the public or >system identifier for the notation), the two mechanisms can be complimentary. I think one of my problems with NOTATIONs in XML is that there has been no way of linking (F)PIs to system resources. I have realised (or re-realised) that this can be done through the CATALOG mechanism. Am I right, therefore, in thinking that use of NOTATION will often be accompanied by CATALOG entries? If so I am partially relieved. CATALOGs are NOT formally part of XML (though there is nothing forbidding them). They therefore seem to be potentially part of the *implementation* (and XML has always distanced itself from the implementation). I also used to dislike catalogs because they were one of the many files-that-could-get-lost when transmitting an SGML document to someone. If we use jar files (in Java) they can hold CATALOGs along with all the rest that we are going to have to deliver - stylesheets, schemas, DTDs and the rest. If this is the case then it relates nicely to our XML-DEV catalog 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 peter at ursus.demon.co.uk Sun Jul 12 19:56:08 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:49 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 4 In-Reply-To: Message-ID: <3.0.1.16.19980712185618.1d2f2e4a@pop3.demon.co.uk> At 15:09 12/07/98 UT, Simon St.Laurent wrote: [...] >2.4.1 Overview > >Attribute declarations are made with empty XSC:AttDef elements. XSC:AttDef >elements may be nested inside of XSC:ElementDecl element declarations or >linked to element. The data type of an attribute is defined with an attribute, > >as is a declaration of whether or not it is required and a possible default >value. > > The spec at purl.org specifies: This seems more reasonable to me and I suspect that what was posted to XML-DEV was a typo... Comments? P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sun Jul 12 21:34:21 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:49 2004 Subject: Message-ID: >You can always put them inside a CDATA marked section or escape the markup >characters--that's normal XML stuff. You can also put the script outside >the document in a data entity or use something like Action Sheets. I understand CDATA sections; I'm just depressed and fairly cranky that people still consider them a worthwhile tool that deserves regular use. Yecch. To think at one time I thought hiding JavaScript inside comments to shield it from old browsers was ugly. We'll all be doing it; a lot of us will just be wondering what genius came up with it. It would have been so much more convenient if the language designers hadn't chosen to interpret '<' as less than and '>' as greater than, but I suppose it was an innocent mistake on their part... 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 Sun Jul 12 21:37:04 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:49 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 4 Message-ID: > > >The spec at purl.org specifies: > > > >This seems more reasonable to me and I suspect that what was posted to >XML-DEV was a typo... Comments? You're right - it's a typo. I had trouble sending this to XML-Dev and probably edited the file thinking I'd kept it in sync when in fact I hadn't. No way would I _require_ an XSC:More anywhere, promise. 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 Mon Jul 13 01:01:16 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:49 2004 Subject: Role of CATALOGs (was Re: ) In-Reply-To: <3.0.1.16.19980712130253.348f5456@pop3.demon.co.uk> Message-ID: <000401bdade9$44ba09b0$a1bc38cb@NT.JELLIFFE.COM.AU> > From: Peter Murray-Rust > I also used to dislike catalogs because they were one of the many > files-that-could-get-lost when transmitting an SGML document to > someone. Browsers (and some OS) have a way to assiciate MIME types with applications. Catalogs need to be a distributable format for this. One of the decisions of the text/xml RFC is that it should work on an entity basis: it refers to a single entity, and NOT a complete document. In SGML there has been a long bunfight about MIME media types: both the camps have the view that whole documents should be sent, but one camp wants the types to only send entities which are actually used (for size minimisation) while the other side wants to leave that up to the sender. So for text/xml the WG wisely abandoned the idea of sending compound documents. But this does mean that questions about bundling catalogs are not answered. I think XML-DEV should similarly avoid the bundling question (it is more applicable to sending documents by email anyway). It should define a standard notation to allow embedded Catalogs in a PI. The PI should go as far towards the head of the document as possible. Of course, an external resource is OK too, but an internal PI saves a download. 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 at megginson.com Mon Jul 13 03:53:01 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:49 2004 Subject: In-Reply-To: References: Message-ID: <199807130149.VAA00218@unready.megginson.com> Simon St.Laurent writes: > I understand CDATA sections; I'm just depressed and fairly cranky > that people still consider them a worthwhile tool that deserves > regular use. Yecch. To think at one time I thought hiding > JavaScript inside comments to shield it from old browsers was ugly. They're not quite the same -- CDATA sections simply shift the parsing mode, so that the only delimiter recognised is "]]>" (or "]]"). That said, they are purely lexical and somewhat unattractive, and exist only as a convenience for people who write XML in regular text editing tools. Once there are XML editing tools in wide-spread use, they will probably hide this, so naive authors will just type if (x < y && a > b) { ... } and the editing software will write it to the XML file as if (x < y && a > b) { ... } 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 amitr at abinfosys.com Mon Jul 13 06:49:12 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:02:50 2004 Subject: Merging Object Oriented Design and SGML Architectures Message-ID: <001701bdae1a$54944db0$0201a8c0@amit.abinfosystems.com> Rick, Thanx for the info. > Instead have put in chapter 3 "Software Engineering" a summary of various > methodologies used in practise for developing DTDs. If you could kindly guide me to any URLs regarding Software Engineering Methodologies used for DTDs. Thanx in advance, AMIT -----Original Message----- From: Rick Jelliffe To: XML Mail List Date: Sunday, July 12, 1998 5:28 PM Subject: RE: Merging Object Oriented Design and SGML Architectures The big fat Cue book (I think it is called "Using SGML") has a chapter relating Smalltalk to SGML. Steve Newcomb has pointed out (reference lost-sorry) that SGML/XML and OO to a large extent have dissimilar goals, in that SGML/XML (i.e. generic markup) are attempts to (allow you to) have your data INDEPENDENT of particular methods while OO is an attempt to bundle methods with data. However, since the introduction of the PI target in XML, it is better to say that SGML/XML are attempts to (allow you to) have your data in a form which allows multiple methods to be attached. The big fat Holzer book (I think it is called "XML Complete") is full of code and analysis relating Java to XML. (But the reviews on amazon.com suggest that it may relate to a superceded version of MSXML too much.) In a sense, a lot of the questions about OO and XML may already be answered, in that XML/SGML embody a particular document system design methodology (i.e. generalized markup) and because common parsers will be using three APIs: * SAX, which XML-DEV contributed to * DOM, see www.w3.org/TR * GROVES: this is the big daddy of them all, and is not so much an API as an analysis of the properties needed for a complete and general SGML/XML/HyTime "parse tree". (In fact any data format whcih can be parsed into a tree with inter-node directed-graph arcs can be represented by GROVE, e.g. CGM the graphics format. Using the same GROVE concept allows navigation languages like Xptr to be defined that can locate particular nodes in the tree, regardless of what notation the tree was parsed from.) The GROVES information is at http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-7.1.html#clause-7.1.4 might be useful place to start. My big fat book, The XML and SGML Cookbook, does not have much OO in it (intentionally: there is no progamming code in it). Instead have put in chapter 3 "Software Engineering" a summary of various methodologies used in practise for developing DTDs. This is because once you have the generalized model OK, you can add methods (explicitly by using #FIXED attributes in the DTD, or by invoking a CSS-like stylesheet where there is an element type to contain mthod code or location, or by using PIs.) So the emphasis is that the more richly and appropriately your data is marked up, the less programming work (including OO analysis and design) there is to do. There is a widespread feeling in the SGML world that you should mark up data independent of any particular use of it. However, I certainly believe that a good DTD design will be informed by the known and potential uses of the data. In a way it comes down to whether you view XML as a "serialization format" format, where it is just dumping data from a known schema and known application, or whether it is "markup language" where you want to expose interesting and useful information to make life simpler for future software development. Rick Jelliffe -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Amit Rekhi Sent: Friday, 10 July 1998 23:12 To: XML Mail List Subject: Merging Object Oriented Design and SGML Architectures Hello, Could anyone please guide to articles/technical notes regarding OOD and SGML Architectures. Any help will be greatly appreciated Thanx, AMIT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980713/f764fd61/attachment.htm From peter at ursus.demon.co.uk Mon Jul 13 08:18:05 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:50 2004 Subject: LISTRIVIA (Re: Merging Object Oriented Design and SGML Architectures) In-Reply-To: <001701bdae1a$54944db0$0201a8c0@amit.abinfosystems.com> Message-ID: <3.0.1.16.19980713071828.208fcf02@pop3.demon.co.uk> At 10:24 13/07/98 +0530, Amit Rekhi wrote: [... about 30 words to XML-DEV ...] and then copied about 100 lines of previous material, quite unnecessarily > AMIT > >Attachment Converted: "c:\eudora\attach\ReMergi1.htm" and then duplicated it all in an HTML message. This represents an information content of about 1%, the rest being dross that I have to pay for. Given that I have posted twice about this in the last few days I regard this as discourteous to me and the list members. I do not normally name-and-shame and I hope I don't have to again. 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 Mon Jul 13 08:23:44 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:50 2004 Subject: Role of CATALOGs (was Re: ) In-Reply-To: <000401bdade9$44ba09b0$a1bc38cb@NT.JELLIFFE.COM.AU> References: <3.0.1.16.19980712130253.348f5456@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980713072337.235fe998@pop3.demon.co.uk> At 09:03 13/07/98 +1000, Rick Jelliffe wrote: > >One of the decisions of the text/xml RFC is that it should work on an entity >basis: it refers to a single entity, and NOT a complete document. Ah... I start to understand. > >In SGML there has been a long bunfight about MIME media types: both the >camps have the view that whole documents should be sent, but one camp wants >the types to only send entities which are actually used (for size >minimisation) while the other side wants to leave that up to the sender. So >for text/xml the WG wisely abandoned the idea of sending compound documents. > >But this does mean that questions about bundling catalogs are not answered. Yes - and we have to have an answer soon. > >I think XML-DEV should similarly avoid the bundling question (it is more >applicable to sending documents by email anyway). It should define a >standard notation to allow embedded Catalogs in a PI. The PI should go as >far towards the head of the document as possible. Of course, an external >resource is OK too, but an internal PI saves a download. Seems a useful idea - I assume this is novel? It also stops the problem of the wrong catalog getting associated with the wrong file (though not the wrong files being addressed by the catalog :-) > > ... >?> Understood. Perhaps to start with. Anyone? > >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) > > 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 ricko at allette.com.au Mon Jul 13 12:16:52 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:50 2004 Subject: Merging Object Oriented Design and SGML Architectures In-Reply-To: <001701bdae1a$54944db0$0201a8c0@amit.abinfosystems.com> Message-ID: <000501bdae47$a375f690$97bc38cb@NT.JELLIFFE.COM.AU> Check out www.sil.org/sgml website: there are thousands of references and links. Rick Jelliffe -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Amit Rekhi Sent: Monday, 13 July 1998 14:55 To: XML Mail List Cc: Rick Jelliffe Subject: Re: Merging Object Oriented Design and SGML Architectures Rick, Thanx for the info. > Instead have put in chapter 3 "Software Engineering" a summary of various > methodologies used in practise for developing DTDs. If you could kindly guide me to any URLs regarding Software Engineering Methodologies used for DTDs. Thanx in advance, AMIT -----Original Message----- From: Rick Jelliffe To: XML Mail List Date: Sunday, July 12, 1998 5:28 PM Subject: RE: Merging Object Oriented Design and SGML Architectures The big fat Cue book (I think it is called "Using SGML") has a chapter relating Smalltalk to SGML. Steve Newcomb has pointed out (reference lost-sorry) that SGML/XML and OO to a large extent have dissimilar goals, in that SGML/XML (i.e. generic markup) are attempts to (allow you to) have your data INDEPENDENT of particular methods while OO is an attempt to bundle methods with data. However, since the introduction of the PI target in XML, it is better to say that SGML/XML are attempts to (allow you to) have your data in a form which allows multiple methods to be attached. The big fat Holzer book (I think it is called "XML Complete") is full of code and analysis relating Java to XML. (But the reviews on amazon.com suggest that it may relate to a superceded version of MSXML too much.) In a sense, a lot of the questions about OO and XML may already be answered, in that XML/SGML embody a particular document system design methodology (i.e. generalized markup) and because common parsers will be using three APIs: * SAX, which XML-DEV contributed to * DOM, see www.w3.org/TR * GROVES: this is the big daddy of them all, and is not so much an API as an analysis of the properties needed for a complete and general SGML/XML/HyTime "parse tree". (In fact any data format whcih can be parsed into a tree with inter-node directed-graph arcs can be represented by GROVE, e.g. CGM the graphics format. Using the same GROVE concept allows navigation languages like Xptr to be defined that can locate particular nodes in the tree, regardless of what notation the tree was parsed from.) The GROVES information is at http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-7.1.html#clause-7.1.4 might be useful place to start. My big fat book, The XML and SGML Cookbook, does not have much OO in it (intentionally: there is no progamming code in it). Instead have put in chapter 3 "Software Engineering" a summary of various methodologies used in practise for developing DTDs. This is because once you have the generalized model OK, you can add methods (explicitly by using #FIXED attributes in the DTD, or by invoking a CSS-like stylesheet where there is an element type to contain mthod code or location, or by using PIs.) So the emphasis is that the more richly and appropriately your data is marked up, the less programming work (including OO analysis and design) there is to do. There is a widespread feeling in the SGML world that you should mark up data independent of any particular use of it. However, I certainly believe that a good DTD design will be informed by the known and potential uses of the data. In a way it comes down to whether you view XML as a "serialization format" format, where it is just dumping data from a known schema and known application, or whether it is "markup language" where you want to expose interesting and useful information to make life simpler for future software development. Rick Jelliffe -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of Amit Rekhi Sent: Friday, 10 July 1998 23:12 To: XML Mail List Subject: Merging Object Oriented Design and SGML Architectures Hello, Could anyone please guide to articles/technical notes regarding OOD and SGML Architectures. Any help will be greatly appreciated Thanx, AMIT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980713/82cc16a0/attachment.htm From rbourret at dvs1.informatik.tu-darmstadt.de Mon Jul 13 13:25:11 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:50 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 4 Message-ID: <199807131124.NAA24369@berlin.dvs1.tu-darmstadt.de> > 2.4.3 Attribute Defaults > > XSchema requires attribute declarations to provide information about the > default value of a given attribute. XSchema provides for the four cases > supported by XML 1.0: #REQUIRED, #IMPLIED, #FIXED AttValue, and AttValue, > though they are expressed as choices between required and not required and > fixed or not fixed, with an optional default value. There may be only one > default value declaration per attribute. I used to think that Required, Fixed, and default value were orthogonal, that the XML naming scheme was confusing, and that this new scheme was wonderful. Then I looked at the possible combinations, half of which are illegal: Required Fixed AttValue XML 1.0 Value -------- ----- -------- -------------------------------- Yes Yes #FIXED Yes Yes -- error [1] Yes No AttValue Yes No -- #REQUIRED No Yes error [2] No Yes -- error [1] No No error [2] No No -- #IMPLIED [1] Fixed=Yes without a value is clearly an error. [2] In XML, a default attribute value effectively implies that an attribute is required; that is, that it always has a value. Non-required defaults don't make sense, as they imply that an attribute can be missing (null in database terms) but, if present, use a default. XML has no concept of null-valued attributes, so non-required defaults are errors. What I realized is that the relationship between Required, Fixed, and AttValue is hierarchical, not orthogonal: Not required Required, no default Required with default Required with fixed default I like the wording of the current scheme, which is much clearer than XML's wording, but am leery that half the combinations are illegal. Should we change this to another syntax with no illegal possibilities (nothing equally clear comes to mind) or simply document the illegal combinations? -- 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 Mon Jul 13 14:18:15 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:50 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4 Message-ID: <199807131214.OAA24513@berlin.dvs1.tu-darmstadt.de> John Cowan wrote: > Ron Bourret wrote: > > > One can imagine an XSchema where the top-level element declarations themselves > > are relatively useless but exist so that an XLink can refer to their content > > models. This is a bit hacky, but it's the only way I can see to duplicate the > > horiz.model and vert.model entities in John Cowan's Itsy B > > Bitsy Teeny Weeny Simple Hypertext DTD. > > Very kludgy indeed. > > I have one new proposal and one old one. I'm thinking that several more > elements should be allowed at top level, namely AttDef, Choice, Sequence, > Mixed, NotationType, and EnumerationType. These would then exist > as free-floating resources which could be referred to by idrefs > elsewhere. > > The old proposal is for an AttGroup element, with a content model > of (Doc?, AttDef+), and available at top level and also within an Element > model. This would allow multiple attributes to be treated as a > single thing for either documentation or reference. I think what both of these suggestions and the discussion about root elements describe is the tension between two overlapping aims of XSchema. The first aim is to provide what I will call an instance syntax -- that is, the syntax of an XML document that people should follow exactly. The second aim is to provide a bag of definitions that can be used elsewhere. Note that while XSchemas in the first case can, with a bit of work, be reused as the second case, the opposite is unlikely to be true. Our current syntax satisfies the first aim. John's first suggestion satisfies the second aim. The XSchema subelement is a mechanism for grouping definitions: a group of attributes (negates the need for AttGroup), a group of element declarations, a complete content model, etc. To reference such a group, all you need is the XPointer xschema-subelement-id.child(all). I therefore think we should do the following: 1) Add the following sentence to the end of the first paragraph in section 2.1 after the syntax: "... The XSC:XSchema element may also contain other XSC:XSchema elements nested inside of it. ****This allows one XSchema document to contain other XSchema documents. It also serves as a way to group XSchema elements for inclusion in other XSchema documents.****" 2) As John suggests, expand the legal elements beneath an XSchema element. In particular, add AttDef, Choice, Sequence, Mixed, and Ref to the XSchema element. (NotationType and EnumerationType no longer exist. I have added Ref to John's list.) -- 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 Mon Jul 13 15:10:45 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:50 2004 Subject: XSchema Spec - Extensions (Section 2.6), Draft 2 In-Reply-To: "Simon St.Laurent"'s message of "Sun, 12 Jul 98 15:09:41 UT" References: Message-ID: Simon> Simon St.Laurent => In article , Simon => wrote: Simon> Simon> %ibtwsh; Simon> Simon> Simon> Any element allowed in the horiz.model set of elements (A, BR, Simon> SPAN, XML, CITE, CODE, DFN, EM, KBD, SAMP, STRONG, VAR, FONT, Simon> or parsed character data) may be used in the XSC:Doc element. This worries me a little. What's the purpose of FONT? It's being dropped from HTML (i.e. it's only in the "transitional" version of HTML 4), so why create a legacy that will need supporting later? I think we could also do with a definition or convention for referencing things defined in the XSchema. It would be nice to have something less verbose and more robust than DOC each time you want to mention your DOC element. A specialised reference type, with a choice of IDREF or extra-document linking would be welcome. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eriblair at mediom.qc.ca Mon Jul 13 15:52:29 1998 From: eriblair at mediom.qc.ca (Eric Riblair) Date: Mon Jun 7 17:02:50 2004 Subject: A question about the Mika's question Message-ID: <199807131352.JAA27624@netra.mediom.qc.ca> I miss the original question ... and I'm asking if it a question relative to the traitment by msxml of the latin character (ex: ?, ?, etc.) ... and if it the case, how can use this to parse a xml document with isolatin character!!! Thanks for any help ... Eric xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jul 13 16:28:14 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:50 2004 Subject: XSchema Spec - Extensions (Section 2.6), Draft 2 References: Message-ID: <35AA194F.DB1D8FEF@locke.ccil.org> Toby Speight wrote: > This worries me a little. What's the purpose of FONT? It's being > dropped from HTML (i.e. it's only in the "transitional" version of > HTML 4), so why create a legacy that will need supporting later? FONT has been removed from IBTWSH 4.0 in favor of BIG and SMALL, which really mean "important" and "unimportant", but there are no structural tags for these. -- 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 Mon Jul 13 16:39:32 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:50 2004 Subject: Message-ID: David Megginson wrote: >They're not quite the same -- CDATA sections simply shift the parsing >mode, so that the only delimiter recognised is "]]>" (or "]]"). That >said, they are purely lexical and somewhat unattractive, and exist >only as a convenience for people who write XML in regular text >editing tools. > >Once there are XML editing tools in wide-spread use, they will >probably hide this, so naive authors will just type >[...good example omitted...] If and when there are XML editing tools that are any good - and my pessimism comes from my rather miserable experiences with even the latest HTML tools - this may be true. In the meantime, lots and lots of experienced coders, the ones most likely to gravitate to XML, are still going to be hand-coding. I at least hand-edit all of my 'final' HTML - the XSchema drafts are just coming through Word's lousy Save as HTML option because I don't have time to hand-code them too. (The final drafts I'll pick clean by hand.) I really hope we can do something for the 'naive author' sometime soon, because otherwise they'll be awfully confused. This is turning into more of an XML-L discussion; while I've enjoyed being cranky, I doubt this discussion will bear much more fruit for XML-Dev. 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 James.Anderson at mecomnet.de Mon Jul 13 16:58:00 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:50 2004 Subject: XCatalog proposal draft 0.1 References: <35A63F3B.7EDA9DBC@locke.ccil.org> Message-ID: <35A6947F.8BB2DEE4@mecomnet.de> John Cowan wrote: > > This is a proposal for XCatalogs, a system based on SGML/Open > catalogs (Socats) for translating public identifiers to > system identifiers in XML. > 8. Open questions > > Should compliance require support for both syntaxes? yes. ? are there mime type to identify these things, or would one trust the extension in the resource name? or 'autodetect'? > I think the Socat syntax is essential for backward compatibility > with existing tools, and it is more compact (important for > huge catalogs full of Delegate entries), but the XML instance syntax > is more in the spirit of XML (and XSchema, etc.). > > If both syntaxes are supported, should Delegate and Extend entries > be allowed to refer from one syntax to another, yes: what benefit would there be from duplicating delegates / extensions? > or should Socat > catalogs refer only to other Socat catalogs and ditto for XML > instance catalogs? > ? what it the rational / history behind pruning the search at the first partial match? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From kimc at ned.dem.csiro.au Mon Jul 13 17:16:11 1998 From: kimc at ned.dem.csiro.au (Kim Covil) Date: Mon Jun 7 17:02:50 2004 Subject: Parser question... Message-ID: <199807131515.AA24949@zydeco> I am hoping this is the correct place to post a couple of questions I have at present... We (my boss and I) are currently developing a metadata system using xml to describe and reference the various different data sets we have, into a single body of information... The idea is to have a single description file for each resource (document, GIS dataset, 3d model) that enables us to index all our resources and create multiple views of each resource from the the description files... Currently we are using an SGML parser to parse the xml description files and a perl script to walk through the parsed tree and output whichever view of the data is required (HTML, VRML, image data...) The perl interface we are using is SGML::SPGrove written by Ken MacLeod to link with James Clark's SP... We are reasonably happy with the way this works although a touch more speed would be helpful as the views the scripts create are created on the fly... I have been wondering whether there are any tools out there that will 'cache' the parsing of a DTD... As all our resources use the same DTD, each time a view is created the xml file is parsed... the DTD is referenced... the DTD is parsed and then the xml is validated... It seems to me that we should be able to reuse the middle bit... Are there any tools that treat a DTD as an input to create a validating parser...? I am think of the sort of thing lex and yacc do... That was my first question... My second is more of a clarification... I am still a little unsure of the use of NOTATIONs... I think they would be perfect for encapsulating data that will be stored in the xml that we are going to hand to a 'handling' package to produce the resource... ie: Is this sort of thing correct usage of NOTATIONs or should this be done using PIs and if so could someone show me how it would be done...? Cheers, Kim -- ====================================================================== Kim Covil - Australian Geodynamics CRC E-mail: kimc@ned.dem.csiro.au CSIRO Exploration & Mining Tel: +61 8 9284 8425 ,-_!\ PO Box 437, Nedlands, Fax: +61 8 9389 1906 / \ Western Australia 6009 *_,-._/ =================================================================== v Please direct all personal e-mail to kimbotha@cygnus.uwa.edu.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 david at megginson.com Mon Jul 13 17:18:53 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:51 2004 Subject: In-Reply-To: References: Message-ID: <199807131514.LAA01070@unready.megginson.com> Simon St.Laurent writes: > If and when there are XML editing tools that are any good - and my > pessimism comes from my rather miserable experiences with even the > latest HTML tools - this may be true. In the meantime, lots and > lots of experienced coders, the ones most likely to gravitate to > XML, are still going to be hand-coding. By far the best solution is for developers to keep their scripts out of line and point to them -- that lets each language (programming or markup) be represented using its natural syntax. The advantages are quite significant: 1. Ease of authoring: you can create your script using tools customised for the script's language (such as an Emacs mode) -- that way, you get syntax highlighting, paren matching, etc., and don't have to escape XML delimiters. 2. Ease of management: since the script is outside of the XML/HTML document, is easy to create, store, test, and revision separately. 3. Ease of analysis: someone else looking at your work can easily tell what is markup and what is code; you don't need an analyst who knows _both_ XML and the scripting language. 4. Modularity: since the script is self-contained, it is easy to replace it later without necessarily editing the original document. 5. Ease of Reuse: since the CSS, ECMAScript, or whatever stands alone, you can reuse the same script for many documents, and all documents will register changes instantly and automatically. The disadvantage is that management becomes difficult when there are dozens (or hundreds) of small code fragments rather than one large one -- that is why my advice does not yet apply to literate programming (at least, not until there's good tool support). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jul 13 17:19:03 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:51 2004 Subject: Itsy Bitsy updates Message-ID: <35AA244B.F516C93A@locke.ccil.org> After reading an excellent article on the dangers of the HTML FONT element at http://www.mcsr.olemiss.edu/~mudws/font.html , I have decided to remove it from ibtwsh.dtd. Instead, I have supplied the BIG and SMALL elements for marking important and unimportant text, and decided to abandon color support altogether, since existing browsers do not permit it to be overridden (which may mean that the author's text color is invisible against the user's background color). -- 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 jubrown at projectcool.com Mon Jul 13 17:29:37 1998 From: jubrown at projectcool.com (Julie Brown) Date: Mon Jun 7 17:02:51 2004 Subject: XML--I need advice on an XML tutorial I wrote In-Reply-To: <01bdadad$d9a10d80$05addccf@bckman.ix.netcom.com> Message-ID: <001501bdae73$44961340$0a490ece@pluto.projectcool.com> Hi everyone, again. I wanted to thank everyone for your advice on my XML pages. I didn't realize that I had made some serious errors with starting and ending an xml document. I'll be fixing it over the next day, and explaining a bit more about elements and attributes--we wanted to avoid discussing them until the "Basics Section," but I think you're all right about briefly mentioning them. Thanks again for the advice! -Julie -----Original Message----- From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk] On Behalf Of Frank Boumphrey Sent: Sunday, July 12, 1998 8:58 AM To: Tim Bray; Julie Brown; xml-dev@ic.ac.uk; dturner@microsoft.com; stevsk@microsoft.com Subject: Re: XML--I need advice on an XML tutorial I wrote I think it would have been fairer to point out that xml should be lower case! is correct " " > >Wrong. Read the spec Prolog [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? [23] XMLDecl ::= '' [24] VersionInfo ::= S 'version' Eq (' VersionNum ' | " VersionNum ") [25] Eq ::= S? '=' S? [26] VersionNum ::= ([a-zA-Z0-9_.:] | '-')+ [27] Misc ::= Comment | PI | S Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com -----Original Message----- From: Tim Bray To: Julie Brown ; xml-dev@ic.ac.uk ; dturner@microsoft.com ; stevsk@microsoft.com Date: Sunday, July 12, 1998 11:29 AM Subject: Re: XML--I need advice on an XML tutorial I wrote > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe 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 ht at cogsci.ed.ac.uk Mon Jul 13 17:42:37 1998 From: ht at cogsci.ed.ac.uk (Henry S. Thompson) Date: Mon Jun 7 17:02:51 2004 Subject: Parser question... In-Reply-To: Kim Covil's message of Mon, 13 Jul 1998 23:15:31 +0800 References: <199807131515.AA24949@zydeco> Message-ID: Kim asks about caching DTDs for faster parsing: LT NSL (http://www.ltg.ed.ac.uk/software/nsl/) does exactly that, but doesn't validate except the first step in the pipe. If you don't care about validation, but do want speed, I recommend LT XML (new release just out: http://www.ltg.ed.ac.uk/software/xml/) which is written in C, runs on WIN32 and UN*X platforms, comes with a number of pre-built tools (including two for downtranslation) which might well handle a lot of your needs -- if not it also includes a powerful API supporting both stream and event views of your documents. Of course the truely correct approach is to use XSL+XSLJ+Jade or DSSSL+Jade, avoiding the procedural (slow) Perl step altogether. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jul 13 18:22:54 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:51 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4 References: <199807131214.OAA24513@berlin.dvs1.tu-darmstadt.de> Message-ID: <35AA33D5.2CBB00FF@locke.ccil.org> Ron Bourret wrote: > The first aim is to provide what I will call an instance syntax -- that is, the > syntax of an XML document that people should follow exactly. The second aim is > to provide a bag of definitions that can be used elsewhere. Note that while > XSchemas in the first case can, with a bit of work, be reused as the second > case, the opposite is unlikely to be true. Just so. > Our current syntax satisfies the first aim. John's first suggestion satisfies > the second aim. The XSchema subelement is a mechanism for grouping definitions: > a group of attributes (negates the need for AttGroup), You're right. I withdraw AttGroup; XSC:XSchema does it all. > "... The XSC:XSchema element may also contain other XSC:XSchema elements nested > inside of it. ****This allows one XSchema document to contain other XSchema > documents. It also serves as a way to group XSchema elements for inclusion in > other XSchema documents.****" Good. > 2) As John suggests, expand the legal elements beneath an XSchema element. In > particular, add AttDef, Choice, Sequence, Mixed, and Ref to the XSchema > element. (NotationType and EnumerationType no longer exist. I have added Ref > to John's list.) My only criticism: I don't think Ref belongs here, simply because Refs don't have any content themselves: they are just pointers, so it seems useless, over-complicated, and confusing in XSchema to have pointers to pointers. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Mon Jul 13 18:35:57 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:02:51 2004 Subject: What are data attributes (was Re: ) References: <3.0.32.19980711100020.00cf2d50@postoffice.swbell.net> Message-ID: <35AA37F0.FA0A26F9@mecomnet.de> W. Eliot Kimber wrote: > > [an extended example related to 'data attributes' ...] > > In SGML, you can declare attributes for a notation and then use those > attributes as part of a data entity declaration or (using the "Data > attributes for elements" (DAFE) facility of the General Architecture ... > on elements governed by that notation. They are called "data attributes" ... > ... > The process I've described is no different from what people have been doing > for years in SGML and HTML and XML, it's just that we've slapped a little > layer of standardized syntax and semantics on it to enable wider > generalization. It does, however, depend on the data attributes facility, > which the XML WG, over my strong personal objection (for what that's > worth), elected not to include in XML. why this last proviso? the attribute namespace distinctions could be accomplished with namespace declarations and the data attributes hung on 'notational' (rather than, but analogous to 'architectural') elements. except for entity notations, wouldn't that achieve the same thing. and as long as one can use 'notation-enabled' x-links rather than entities, the 'notational' elements would suffice? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 13 18:38:30 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:51 2004 Subject: XCatalog proposal draft 0.1 References: <35A63F3B.7EDA9DBC@locke.ccil.org> <35A6947F.8BB2DEE4@mecomnet.de> Message-ID: <35AA3636.1374AF2E@locke.ccil.org> james anderson wrote: > ? are there mime type to identify these things, or would one trust the > extension in the resource name? or 'autodetect'? Good question. application/xml and application/x-socat probably make sense. > yes: what benefit would there be from duplicating delegates / extensions? Probably none. > ? what it the rational / history behind pruning the search at the first > partial match? When you find a Delegate entry, that's assumed to be authoritative information about part of the FPI tree. Thus, the "master catalog" would be a whole lot of Delegate entries, stating where the catalogs are for -//ThisCo//, -/ThatCo//, and -//TotherCo. It's like DNS glue records. -- 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 Jul 13 18:41:37 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:51 2004 Subject: XSchema Spec - Extensions (Section 2.6), Draft 2 References: <35AA194F.DB1D8FEF@locke.ccil.org> Message-ID: <35AA384B.A0CF9C8F@locke.ccil.org> Toby Speight wrote: > [I suppose I ought to go & read IBTWSH 4.0 - when I can escape from my > Real Work...] Hey, the DTD is only 300 lines long, and you already know what all the elements and attributes are for. Go for 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 jtigue at DataChannel.com Mon Jul 13 18:50:33 1998 From: jtigue at DataChannel.com (John Tigue) Date: Mon Jun 7 17:02:51 2004 Subject: Data Types (was: RE: Dates in XML) Message-ID: <4435AEE04AAED111A41F00A0C99B60230FCFF0@ZEUS> I would say that XML-Data is pretty good in terms of how many datatypes it has. We could clean up some duplicates like int and i4 (and maybe one or two more like that). Any more significant modification should be done within the context of ISO 11404 and HTTP-NG. A comparison to ISO 11404 (ISO/IEC 11404:1996 Information technology -- Programming languages, their environments and system software interfaces -- Language-independent datatypes) would put XML-Data in context of relevant precedence. Anyone interested in LID (Language-independent datatypes) should read 11404 or the papers of Brian Meek; the latter is cheaper and his papers are on the Web. Meek's "A taxonomy of datatypes" is very relevant and helps to set the stage for these types of discussions. If the goal is to reduce the count of datatypes then consider the HTTP-NG type system. It has only two numeric primitives, fixed-point and floating-point. See the third section of http://www.w3.org/TR/WD-HTTP-NG-architecture/ for details and motivation. The document's attitude is summed up by the following quoted phrase though: "We use this approach, instead of specifying a procrustean flock of predefined integer types...". Since HTTP-NG is another activity of the W3C, synchronization of HTTP-NG and XML-Data would be good. > -----Original Message----- > From: Andrew Layman [mailto:andrewl@microsoft.com] > Sent: Friday, July 10, 1998 3:49 PM > To: 'John Tigue' > Cc: Bryan Gilbert; 'xml-dev@ic.ac.uk' > Subject: RE: Data Types (was: RE: Dates in XML) > > > Tim Bray suggests that there are too many datatypes defined. > What is your > opinion on 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 cowan at locke.ccil.org Mon Jul 13 19:44:25 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:51 2004 Subject: Data Types (was: RE: Dates in XML) References: <4435AEE04AAED111A41F00A0C99B60230FCFF0@ZEUS> Message-ID: <35AA4759.EB0E3137@locke.ccil.org> John Tigue wrote: > Anyone interested in LID (Language-independent > datatypes) should read 11404 or the papers of Brian Meek; the latter is > cheaper and his papers are on the Web. Meek's "A taxonomy of datatypes" > is very relevant and helps to set the stage for these types of > discussions. Unfortunately, King's says those papers are offline until further notice. -- 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 Mon Jul 13 19:58:36 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:51 2004 Subject: Message-ID: David Megginson wrote: >By far the best solution is for developers to keep their scripts out >of line and point to them -- that lets each language (programming or >markup) be represented using its natural syntax. The advantages are >quite significant: >[...plausible advantages snipped...] I see you like to keep me cranky! While the recommendation that code and content be kept separate is indeed appropriate for many applications, it doesn't make sense in every case. Interface components within web browsers are rarely generic code divorced from abstract content; the code and content tend to be much more closely intertwined partners, completely dependent on each other for proper operation. Keeping scripts separate is indeed useful when it's generic and reusable code; keeping them separate when they are tightly bound to a particular document instance is much more of a hassle than it's worth, in my strongly-felt opinion. (Keep in mind that I did Dynamic HTML: A Primer before XML: A Primer appeared on the radar screen.) That said, programmers will be stuck using the even-more-grotesque-than-comments CDATA marked section for precisely those instances and we'll have to deal with it. 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 Jul 13 20:01:25 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:51 2004 Subject: Itsy Bitsy updates In-Reply-To: <35AA244B.F516C93A@locke.ccil.org> (message from John Cowan on Mon, 13 Jul 1998 11:14:19 -0400) Message-ID: <199807131759.NAA05614@ruby.ora.com> [John Cowan] > After reading an excellent article on the dangers of the HTML FONT > element at http://www.mcsr.olemiss.edu/~mudws/font.html , I have > decided to remove it from ibtwsh.dtd. Instead, I have supplied the > BIG and SMALL elements for marking important and unimportant text, > and decided to abandon color support altogether, since existing > browsers do not permit it to be overridden (which may mean that the > author's text color is invisible against the user's background > color). You're making progress! Now take out and , , , and , which are purely presentational, and use and , , , , and , unless you're trying to re-invent TeX (which is pretty much what HTML did). For XSchema I would suggest, as another poster did, that some element types specific to the subject at hand might be useful, such as , , and . Don't force IBTWML into XSchema; adapt it to the task at hand. That is, after all, the point of XML. -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 andrewl at microsoft.com Tue Jul 14 00:07:57 1998 From: andrewl at microsoft.com (Andrew Layman) Date: Mon Jun 7 17:02:51 2004 Subject: XLF: Legacy Log Problems Message-ID: <5BF896CAFE8DD111812400805F1991F7038CA5F1@red-msg-08.dns.microsoft.com> This is an interesting topic. I ran some tests a while ago and found that XML, after compression, was within about 10% of the file size of a text file containing the same data but without tags. My datasets may differ, of course, but I'm wondering whether anyone has run tests of log data in XML versus not in XML, and compared compressed sizes? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Jul 14 00:40:26 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:51 2004 Subject: XLF: Legacy Log Problems Message-ID: <003601bdaeae$029f78b0$2ee044c6@arcot-main> Andrew, >This is an interesting topic. I ran some tests a while ago and found that >XML, after compression, was within about 10% of the file size of a text file >containing the same data but without tags. My datasets may differ, of >course, but I'm wondering whether anyone has run tests of log data in XML >versus not in XML, and compared compressed sizes? I don't think there are any log data in XML. I'll ask the XLF members though. I do not expect XLF to be much more verbose than average XML because regularity in log data can be taken advantage of. For example, timestamps can be abbreviated by logging absolute time first and then logging relative time subsequently. Following is a link to my "Time and Time Again" proposal which I proposed on the XLF mailing list: http://www.jxml.com/archive/xlf/0006.html FYI, the XLF home page is at http://www.docuverse.com/xlf Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jubrown at projectcool.com Tue Jul 14 01:39:39 1998 From: jubrown at projectcool.com (Julie Brown) Date: Mon Jun 7 17:02:51 2004 Subject: XML--I need advice on an XML tutorial I wrote Message-ID: <001e01bdaeb7$bec87ba0$0a490ece@pluto.projectcool.com> Hi everyone, again. Not to be annoying, but I did make the corrections that some of you suggested on my xml page. Here's the URL for those who'd like to see what I fixed: http://www.projectcool.com/developer/xmlpub/index.html I fixed my css problem which turned all my examples to cyan (no I didn't intend that). Thanks again to everyone who gave me nice suggestions. I'm tyring the best I can to understand this (and it is complicated stuff for a lot of people). Thanks! I'll go back to my beginner XML list now. :) -Julie xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From kimc at ned.dem.csiro.au Tue Jul 14 08:19:55 1998 From: kimc at ned.dem.csiro.au (Kim Covil) Date: Mon Jun 7 17:02:51 2004 Subject: NOTATIONs vs PIs (was Parser question...) Message-ID: <199807140619.AA25533@zydeco> I have just realised that my first phrasing of this question got a bit lost in my last post... I am still a little unsure of the use of NOTATIONs... I think they would be perfect for encapsulating data that will be stored in an xml file that describes a resource...ie: The idea is that the xml file describes a gis data resource and this element is used by a processing program to retrieve that resource... It is application specific data that is not required to be parsed by the processing application... it just needs to hand the whole lot to the correct gis package and expect the resource to be returned to it... Is this sort of thing correct usage of NOTATIONs or should this be done using PIs and if so could someone show me how it would be done...? I think my problem lies in that I am not clear on the difference between the two... Thanks for any assistance, Kim Covil -- ====================================================================== Kim Covil - Australian Geodynamics CRC E-mail: kimc@ned.dem.csiro.au CSIRO Exploration & Mining Tel: +61 8 9284 8425 ,-_!\ PO Box 437, Nedlands, Fax: +61 8 9389 1906 / \ Western Australia 6009 *_,-._/ =================================================================== v Please direct all personal e-mail to kimbotha@cygnus.uwa.edu.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 rbourret at dvs1.informatik.tu-darmstadt.de Tue Jul 14 10:12:03 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:52 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 4 Message-ID: <199807140810.KAA01235@berlin.dvs1.tu-darmstadt.de> John Cowan wrote: > > 2) As John suggests, expand the legal elements beneath an XSchema element. In > > particular, add AttDef, Choice, Sequence, Mixed, and Ref to the XSchema > > element. (NotationType and EnumerationType no longer exist. I have added Ref > > to John's list.) > > My only criticism: I don't think Ref belongs here, simply because Refs > don't have any content themselves: they are just pointers, so it seems > useless, over-complicated, and confusing in XSchema to have pointers > to pointers. But Ref is a valid content model: (i.e. ) If I want to be able to store more complex content models in an XSchema element (for reference from other XSchemas), why can't I store this one? -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Jul 14 10:22:55 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:52 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 4 Message-ID: <199807140820.KAA01448@berlin.dvs1.tu-darmstadt.de> David Brownell wrote: > > Required Fixed AttValue XML 1.0 Value > > -------- ----- -------- -------------------------------- > > No Yes error [2] > > No No error [2] > > > > [2] In XML, a default attribute value effectively implies that an > > attribute is required; that is, that it always has a value. > > Not quite -- "#REQUIRED" means "must be provided in the document text", > not "always has a value". The defaulting mechanism applies in both cases > above, they're not errors. You are right. I was thinking about the end result, not what the XML file looked like. Simon -- is this worth clarifying in the spec (your call)? -- 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 Jul 14 19:02:31 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:52 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 4 Message-ID: > > Required Fixed AttValue XML 1.0 Value > > -------- ----- -------- -------------------------------- > > No Yes error [2] > > No No error [2] > > > > [2] In XML, a default attribute value effectively implies that an > > attribute is required; that is, that it always has a value. > > Not quite -- "#REQUIRED" means "must be provided in the document text", > not "always has a value". The defaulting mechanism applies in both cases > above, they're not errors. > >You are right. I was thinking about the end result, not what the XML file >looked like. Simon -- is this worth clarifying in the spec (your call)? I'll add a table identifying these - based on your table - to section 2.4. Coming soon! Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Tue Jul 14 19:49:36 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:52 2004 Subject: XML--I need advice on an XML tutorial I wrote In-Reply-To: <001501bdae73$44961340$0a490ece@pluto.projectcool.com> References: <01bdadad$d9a10d80$05addccf@bckman.ix.netcom.com> Message-ID: <3.0.1.16.19980714183819.084788ba@pop3.demon.co.uk> At 08:31 13/07/98 -0700, Julie Brown wrote: >Hi everyone, again. > >I wanted to thank everyone for your advice on my XML pages. I didn't >realize that I had made some serious errors with starting and ending an xml >document. We all have to learn somewhere and you chose a good place to ask questions :-) I'd strongly urge that whenever you write an XML document - especially for a tutorial that you run it through a parser. This will pick up misconceptions and typos very effectively. As with all error-reporting it can sometimes be difficult to identify precisely what you have done wrong so it's a good idea to use more than one parser. This is now easy with the SAX interface - and you can use JUMBO2 if you like. What's harder - and only comes with experience - is to learn good style in XML documents. It's worth having a look at quite a few to get an idea. [... LISTRIVIA alert: an awful lot of quoted material snipped :-(...] P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Tue Jul 14 22:15:07 1998 From: jtauber at jtauber.com (James K. Tauber) Date: Mon Jun 7 17:02:52 2004 Subject: Reference Model In-Reply-To: <3.0.1.16.19980625045308.2e67b93e@pop3.demon.co.uk> Message-ID: <000001bdaf64$15fc7960$ba6118cb@caleb> Has anyone developed (or is anyone developing) a reference model for document-based knowledge/information interchange (with a generic markup focus)? I've recently taken up a teaching and research position at Curtin Business School and my research focus is going to be (you guessed it) XML. Initial work will feed a PhD thesis I hope to be starting before the end of the year. At least as part of my initial research, I'd like to develop a reference model (and/or assess existing models) inspired by number conversations I've been having with people, partly on this list, but which actually started at Sun Labs East early 1996. A few weeks ago I wrote: > Off the top of my head (thinking aloud as always), these are > the sorts of things one might want to say about the class of things (say elements) > labelled FOO. > 1. what FOOs can contain > 2. where FOOs can be > 3. what FOOs look like when presented > 4. what FOOs do when the user does something > 5. what an application is to do when it gets a FOO. > 6. what other labels people use for FOOs. > 7. what people mean by FOO. [...] > I would tend to use 'syntax' for 1 and 2, 'presentation' or > 'style' for 3, 'behaviour' for 4, 'action' for 5, and 'semantics' for 6 and > 7. To avoid 'semantics', I might use 'thesaurus' in the context of 6 and > 'meaning' for 7. To which PMR replied (amongst other things): > I think this is worth pursuing. Is it worth trying to get a small, tight > list here? [As far as I know, the thread wasn't continued.] Furthermore, in a post earlier the same day I used the following OSI-inspired models: > In normal publishing: > > AUTHOR CONCEPT [semantics] > --presentation--> > DOCUMENT [presentation] > --interpretation--> > READER CONCEPT [semantics] > > With generic markup: > > AUTHOR CONCEPT [semantics] > --markup--> > XML DOCUMENT [syntax] > --stylesheet--> > DOCUMENT [presentation] > --interpretation--> > READER CONCEPT [semantics] > > Now, where a machine (or a human, for that matter) directly reads the XML documents we have: > > AUTHOR CONCEPT [semantics] > --markup--> > XML DOCUMENT [syntax] > --processing--> > MACHINE ACTION [?semantics] > > [of course, machines can generate the documents too, a case I haven't considered in the above > diagrams] All my thinking on this kind of thing has been ad hoc to date. I'm keen to tie the ideas into existing literature and dialogue with the many wonderful brains on this list (although, not necessarily ON this list). Comments? James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Jul 14 22:29:17 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:52 2004 Subject: SAX: AttributeList in startElement Message-ID: <199807142028.WAA22494@berlin.dvs1.tu-darmstadt.de> If an element doesn't have any attributes, should the AttributeList argument in DocumentHandler.startElement be null or empty? -- 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 srn at techno.com Tue Jul 14 22:50:47 1998 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:02:52 2004 Subject: Reference Model In-Reply-To: <000001bdaf64$15fc7960$ba6118cb@caleb> (jtauber@jtauber.com) References: <000001bdaf64$15fc7960$ba6118cb@caleb> Message-ID: <199807142052.PAA06585@bruno.techno.com> > Has anyone developed (or is anyone developing) a reference model for > document-based knowledge/information interchange (with a generic markup > focus)? Check out topic maps, which are in the throes of standardization by ISO, and which are expressible using extended XLinks or HyTime links. http://www.hightext.com has a draft or two. > > 1. what FOOs can contain > > 2. where FOOs can be > > 3. what FOOs look like when presented > > 4. what FOOs do when the user does something > > 5. what an application is to do when it gets a FOO. > > 6. what other labels people use for FOOs. > > 7. what people mean by FOO. The topic map stuff deals with 6 and 7 only. The rest of the issues you raise are handled by other standards, existing and planned: 1. Schema languages. 2. Addressing. See the HyTime standard for a wealth of generality. 3. Stylesheets. 4. Scripts. 5. Applications; maybe SGML architectures and property sets, too. (again, see HyTime for a general approach) -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 15 01:24:32 1998 From: ricko at allette.com.au (Rick Jelliffe) Date: Mon Jun 7 17:02:52 2004 Subject: Reference Model In-Reply-To: <000001bdaf64$15fc7960$ba6118cb@caleb> Message-ID: <000001bdaf7e$d9814630$a1bc38cb@NT.JELLIFFE.COM.AU> > From: James K. Tauber > Has anyone developed (or is anyone developing) a reference model for > document-based knowledge/information interchange (with a generic markup > focus)? ... > Furthermore, in a post earlier the same day I used the following > OSI-inspired models: > > > In normal publishing: > > > > AUTHOR CONCEPT [semantics] > > --presentation--> > > DOCUMENT [presentation] > > --interpretation--> > > READER CONCEPT [semantics] > > > > With generic markup: > > > > AUTHOR CONCEPT [semantics] > > --markup--> > > XML DOCUMENT [syntax] > > --stylesheet--> > > DOCUMENT [presentation] > > --interpretation--> > > READER CONCEPT [semantics] > > > > Now, where a machine (or a human, for that matter) directly > reads the XML > documents we have: > > > > AUTHOR CONCEPT [semantics] > > --markup--> > > XML DOCUMENT [syntax] > > --processing--> > > MACHINE ACTION [?semantics] > > > > [of course, machines can generate the documents too, a case I haven't > considered in the above > diagrams] In my book I develop a six view model of publications (I even found a word "senocular" meaning "having six eyes" :-). The first three correspond to "presentation markup" and the latter three correspond to "logical markup", and may be all simulataneously present (though often piggybacked): (Page) Layout (Page) Objects Glyphs Characters Editorial Structure Topical Stucture I comment that editorial and topical structure are usually marked up with elements, that characters and glyphs are usually marked up (in SGML at least) with entity (and numeric character) references, and that page layout and page object manipulation are where PIs tend to fit in. I use this model to explain the "flow of dependence" idea behind generic markup, and thus which kinds of flows are not straightforward to implement with generic markup. I found that a more detailed model like this makes it simpler to think about many issues in markup. The various models that James T proposes hard-codes the flow (i.e. "processing") between the various views, which I think misses the basic problem that the relationships between the different views (especially w.r.t. causality) are complex: a simple flow from higher to lower works often, but not always. (Take a newspaper for example: the page design and the rendered sizes of the other articles on a page will constrain how many paragraphs a new article can have: in effect this disguises that paragraphs and sentences in newspapers have a priority (which could be labelled with an attribute) which determines which ones will be selected. In fact, an editor-free system could allow various alternative paragraphs, depending on space, though perhaps that causes other problems.) To give another example of why a simple model which dependency flows from higher-level to lower level structures is often an over-simplification: in my book, the each chapter starts with a summary--I had to write these summaries with knowledge of the layout and the amount of space available. So text often has layout dependencies. The result of ignore presentation->topical depencies is ugly and sterile typeset documents--I notice that both the TeX and the Scribe manuals comment that page-breaking is never 100% successful (i.e. w.r.t. traditional typesetting aesthetics) just from automation: I think the same thing is true about hyphenation. Scroll-bars do get rid of a lot of the media-restrictions from paper publishing, it is true, but visual and design rules still exist. However, every model has its limitations of course: this five view model sticks "metadata" in as a "topical structure", which is not so comfortable. And it skips over the fundamental "document/publication" dichotomy, to a certain extent: a publication is made from combining many sub-publications from various structured documents, each of which is rendered/published at a different time (browsing-time, caching-time, site-building-time, editing-time, authoring-time, etc.) Anyway, I have found this six-view model to be very useful in many situations: it is not difficult to understand and fits in with the ISO character/glyph model, the DSSSL/XSL flow-object model, and Topic Navigation Maps. So I certainly commend the six-view model, but with the proviso that it helps explain which kinds of publications are suitable for generic markup processing. The generic markup movement IMHO is based on exploring which kinds of publications are simple for computer processing: I certainly don't think the generic markup movement should promote the idea that all publications exhibit a simple "flow of dependence" from the sensed page-objects to the imagined underlying logical structures. That is a danger of models like the ones James T is brainstorming. 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 neilc at stanford.edu Wed Jul 15 02:15:09 1998 From: neilc at stanford.edu (Neil Crellin) Date: Mon Jun 7 17:02:52 2004 Subject: RESULT: comp.text.xml passes 365:22 Message-ID: <900461662.8366@isc.org> RESULT unmoderated group comp.text.xml passes 365:22 There were 365 YES votes and 22 NO votes, for a total of 387 valid votes. There were 7 abstentions and 5 invalid ballots. For a group to pass, YES votes must be at least 2/3 of all valid (YES and NO) votes. There must also be at least 100 more YES votes than NO votes. A five day discussion period follows this announcement. If no serious allegations of voting irregularities are raised, the moderator of news.announce.newgroups will create the group shortly thereafter. Newsgroups line: comp.text.xml The Extensible Markup Language (XML). The voting period closed at 23:59:59 UTC, 14 Jul 1998. This vote was conducted by a neutral third party. Questions about the proposed group should be directed to the proponent. Proponent: James Tauber Votetaker: Neil Crellin RATIONALE: comp.text.xml XML is a new language, and it appears that it will be extremely popular. Over the past few months, traffic on the XML-DEV and XML-L mailing lists has grown rapidly. With the release of the W3C Recommendation for XML 1.0, developer interest is growing rapidly and an increasing amount of software is being released. A newsgroup would make it much easier for a wider audience to participate in and benefit from these discussions. While it may appear at first that comp.text.sgml is appropriate, there will be those interested in XML who do not care about the arcana of SGML, and there will be those interested in SGML who do not care to see many basic questions about XML. CHARTER: comp.text.xml Comp.text.xml shall be an unmoderated newsgroup for the general discussion of the Extensible Markup Language (XML) and its application. This includes, but is not limited to the specifications and syntax, document creation and editing, interchange, software, processing and database integration. This applies not only to XML itself but also the Extensible Linking Language (XLL), the Extensible Style Language (XSL), Cascading Style Sheets (CSS) as applied to XML documents, and to document types and applications of XML. Policy on Advertising We encourage discussion of the merits and shortcomings of commercial products. A certain amount of advertising (both objective and advocative) is to be expected and this is to be encouraged as long as the products and services relate directly to XML and the announcements are brief. Company representatives are expected to participate in discussions of their product that they themselves did not initiate. Please refer to the widely available Internet literature on the subject of common net abuses (indiscriminate newsgroup spamming, multiple advertisement posting, and chain letters being among the most frequent). END CHARTER. comp.text.xml Final Voter list Voted YES ------------------------------------------------------------------------------ hockemey [at] fechner.kfunigraz.ac.at Cord Hockemeyer jmodre [at] edu.uni-klu.ac.at Juergen Modre jawe [at] adis.at Jan Wessely neilr [at] a2.com.au Neil Robinson mrc [at] allette.com.au Marcus Carr ricko [at] allette.com.au Rick Jelliffe Ted.Harper [at] bankerstrust.com.au Ted Harper Smith.Adrian.A [at] bhp.com.au Adrian Mark Smith Brooke.Smith [at] Butterworths.com.au Brooke Benjamin Smith Kevin [at] metrocs.com.au Kevin Azzopardi tim_josling [at] nag.national.com.au Tim Josling bmhughes [at] ozemail.com.au Baden Hughes John.Lamp [at] deakin.edu.au John Lamp msf [at] mds.rmit.edu.au Michael Fuller house [at] usq.edu.au Ron House ajc [at] bing.wattle.id.au Andrew Cosgriff Geert.Bormans [at] esat.kuleuven.ac.be Geert Bormans hca [at] xs4all.be Hans C. Arents jdeseyne [at] xs4all.be Jacques Deseyne chriseb [at] nortel.ca Chris Ebenezer gauthier.gilles [at] uqam.ca Gilles Gauthier relander [at] calum.csclub.uwaterloo.ca Richard Lander kshapiro [at] julian.uwo.ca Kivi Shapiro Benedikt.Heinen [at] infrasys.ascom.ch Benedikt Heinen bhilton [at] adc.com Brand Hilton bmv [at] plaza.ds.adp.com
  SMUENCH [at] us.oracle.com Steve Muench crism [at] oreilly.com Christopher R. Maden jsaylor [at] osicom.com John Saylor sal [at] panix.com salvatore denaro MarkS [at] Partes.com Mark Schnitzer seanwebb [at] pictorius.com Sean Webb bw [at] pindar.com Bob Wilkinson clau [at] plaintree.com Carmel Lau mjd-vote-xml [at] plover.com Mark-Jason Dominus ackme [at] pobox.com Jim Gallagher mra [at] pobox.com Mark Atwood ABREAUJ [at] POLAROID.COM John Abreau JLewis [at] PubList.com John D. Lewis francis [at] redrice.com francis frank.richards [at] nagexserver.reedtech.com Frank Richards tony.stewart [at] rivcom.com Tony Stewart GNorth [at] columbus.rr.com Gloria North oisin [at] sbcm.com Oisin McGuinness avirr [at] searchtools.com Avi Rappoport cmunro [at] selsius.com Charlie Munro wcox [at] austin.apc.slb.com BILL COX heaney [at] cambridge.scr.slb.com Steven Heaney huntley [at] smarts.com Huntley Eshenroder Kris.Keener [at] mail.sprint.com Kris W. Keener dak [at] sq.com David 'Dak' Keldsen burton.lee [at] sqribe.com Burton Lee stamper [at] stamper.com Chris Stamper ciarlone [at] world.std.com Leonor Ciarlone barry [at] strategies.com Barry Schaeffer gbs [at] swdc.stratus.com George Smith Jon.Bosak [at] eng.Sun.COM Jon Bosak db [at] Eng.Sun.COM David Brownell altheim [at] mehitabel.eng.Sun.COM Murray Altheim Trevor.Jenkins [at] suneidesis.com Trevor Jenkins whunt [at] devtools.symantec.com Wil Hunt north [at] Synopsys.COM Simon North arielle [at] taronga.com Stephanie da Silva cae [at] telesynthesis.com Carlos A Elizondo benoit.barre [at] teluco.com Benoît BARRE Jeremy.Verity [at] thomtech.com Jeremy Verity mundie [at] micro.ti.com David Mundie mariusz [at] tibco.com Mariusz Podsiadlo danny [at] tridium.com Danny Wahlquist Michael.Lauer [at] tstnet.com Michael Lauer slger [at] twurl.com Susan Gerhart casiello [at] ultranet.com Brian Casiello ken [at] usefulweb.com Ken Elwert rajesh_n1 [at] verifone.com Rajesh N dgulbran [at] vervet.com David Gulbransen gsez020 [at] compo.bedford.waii.com Pete Forman JLemire [at] walldata.com John Lemire jlapp [at] webMethods.com Joe Lapp barry [at] webveranda.com Barry Campbell szpak [at] well.com Mark Szpakowski xanthian [at] well.com Kent Paul Dolan Lloyd.Seamans [at] westgroup.com Lloyd H. Seamans DHable [at] XLinkCorp.com Dan Hable sns [at] xmlcenter.com Steven Noels parsons [at] xyvision.com Jonathan Parsons Hoenicka [at] pbmail.me.kp.dlr.de Markus Hoenicka macherius [at] darmstadt.gmd.de Ingo Macherius Ekkehard.Uthke [at] gmx.de Ekkehard Uthke c.schabacker [at] gis.ibfs.de Carsten Schabacker m.sckopke [at] gis.ibfs.de Martin Sckopke m.wachowitz [at] gis.ibfs.de Marc Wachowitz schwarze [at] isa.de Jochen Schwarze michael.urban [at] hamburg.netsurf.de Michael Urban list-votes [at] dream.hb.north.de Martin Schr"oder g.wulfes [at] berlin.snafu.de Georg Wulfes Harald.Joerg [at] mch.sni.de Harald Joerg nwoh [at] software-ag.de Nigel Hutchison ThB.com [at] t-online.de Thomas Berger Sebastian [at] TRIVIUM.DE klaus.kreulich [at] mb3.tu-chemnitz.de Klaus Kreulich H.Duerer [at] ZAIT.Uni-Bremen.DE Holger Dürer lannert [at] uni-duesseldorf.de cnwetzel [at] linguistik.uni-erlangen.de Christian Wetzel Fotis.Jannidis [at] lrz.uni-muenchen.de Fotis Jannidis ht.ohlsen [at] ddf.dk Hans-Henrik T. Ohlsen tobez [at] plab.ku.dk Anton Berezin dsew [at] packrat.aml.arizona.edu David Sewell jdavis [at] lectura.CS.Arizona.EDU Jim Davis jmcdonou [at] library.berkeley.edu Jerome McDonough grechaw [at] socrates.berkeley.edu John_Lavagnino [at] Brown.edu John Lavagnino jeliza+ [at] red-dwarf.fac.cs.cmu.edu Jeliza Patterson dsr [at] mail.lns.cornell.edu Dan Riley pdurusau [at] emory.edu Patrick Durusau salber [at] cc.gatech.edu Daniel Salber mpslon01 [at] morehead-st.edu Michael Slone pkasieck [at] coe.neu.edu Philip T. Kasiecki kuipers [at] plains.NoDak.edu Gilbert Kuipers lverhulst [at] nmff.nwu.edu Leane Verhulst donahue [at] acf2.nyu.edu Adam M. Donahue zsh [at] cs.rochester.edu Shenghuo ZHU rogersba [at] Rose-Hulman.Edu Brian A. Rogers iburrell [at] leland.Stanford.EDU Ian Burrell goldste3 [at] jeflin.tju.edu Herschel P. Goldstein jason [at] primal.ucdavis.edu Jason Christian fensterm [at] cs.uchicago.edu Kurt Fenstermacher ehood [at] hydra.acs.uci.edu Earl Hood jkcohen [at] uci.edu Jonathan K. Cohen kamikaze [at] kuoi.asui.uidaho.edu llopis [at] zonker.ecs.umass.edu Noel Llopis ser [at] javalab.uoregon.edu Sean Russell jdruck [at] lexus.gslis.utexas.edu Jon Drucker priestdo [at] cs.vassar.edu Greg E. Priest-Dorman rufinus [at] mbe.ece.wisc.edu J Rufinus 1jasagar [at] rigel.deusto.es Jaime Sagarduy barranquero [at] laley-actualidad.es Juanma Barranquero lat [at] iki.fi Lassi A. Tuura vili [at] sun3.oulu.fi Ville Varjonen basile.starynkevitch [at] cea.fr Basile STARYNKEVITCH fre3d [at] club-internet.fr Emilie Danna didier [at] cln46ae.der.edf.fr Didier Bolf benoit.germaneau [at] francetelecom.fr GERMANEAU Benoit SNPSI besagni [at] inist.fr Dominique Besagni Floriano.Conte [at] itbs.fr Floriano Conte Joel.Wilf [at] jpl.nasa.gov Joel Wilf mike [at] eurodyn.com.gr Mihalis Tsoukalos kata [at] kltesrv.klte.hu Katalin Rutkovszky Rory.Quinn [at] berlitz.ie Rory Quinn digitome [at] iol.ie Sean Mc Grath eamon [at] lendac.ie Eamon Hayes david.abrahamson [at] cs.tcd.ie David M. Abrahamson pflynn [at] imbolc.ucc.ie Peter Flynn ecampbell [at] xmlw.ie Eoin Campbell sudarshan [at] pspl.co.in Sudarshan Purohit jatin [at] darkstar.tatainfotech.co.in JATIN SHUKLA marj [at] rhi.hi.is Mar Jonsson mau [at] beatles.cselt.it Maurizio Codogno jwt [at] dskk.co.jp Jim Tittsler numa [at] rp.open.cs.fujitsu.co.jp NUMATA Toshinori jylee [at] t2000.co.kr Lee, Jiyun robert [at] ais.net Robert Morrison geoff20 [at] banet.net Geoff Morris cdarney [at] bellatlantic.net Chuck Darney jrj [at] access.digex.net Joseph R. Justice drclue [at] drclue.net Dr. Clue ellis [at] ftel.net Rick Ellis marty44 [at] gmx.net Martin Boehme d.maltby [at] greater.net David Maltby axxion [at] ibm.net Alexander Stigsen novice [at] ibm.net W. A. Gerrard ghewitt [at] inc.net Gary M Hewitt ford [at] interactive.net Paul Ford cmcurtin [at] interhack.net Matt Curtin stanton [at] interport.net Stanton Teters richard.obeirne [at] lineone.net Richard O'BEIRNE fcy [at] Mcs.Net Fred Yankowski jborden [at] mediaone.net Jonathan A. Borden sgmlgeek [at] top.monad.net Mary P McRae ezy [at] mail1.nai.net Asim Yosafi alexdawson [at] pemail.net Alex Dawson simpson [at] polaris.net John E. Simpson aray [at] q2.net Arjun Ray sherds [at] radiant.net A.I. Persofsky rabin [at] shore.net Paul Rabin stephenp [at] sover.net Stephen Perkins alister [at] theoffice.net A Bulman af137 [at] torfree.net Al Aab ginigma [at] ultracom.net c gold mahto [at] uswest.net Robert N. Thomas skquinn [at] wt.net Shawn K. Quinn michael [at] michaeln.demon.nl Michael Nieuwenhuizen egonw [at] sci.kun.nl Egon Willighagen jdassen [at] wi.leidenuniv.nl J.H.M. Dassen (Ray) michiel.verhoef [at] wkap.nl Michiel Verhoef eikie [at] worldonline.nl Erik van Elsas bjornts [at] infotek.no Bjorn Tore Sund grove [at] infotek.no Geir Ove Grønmo martin [at] texcel.no Martin Dransfield kjetil.kjernsmo [at] astro.uio.no Kjetil Kjernsmo larsga [at] ifi.uio.no Lars Marius Garshol oyvind.eide [at] ub.uio.no Oyvind Eide antony [at] ihug.co.nz Antony Simmonds DeanS [at] WAIRC.GOVT.NZ Dean Stringer sbandy [at] aaas.org S. Bandy fdrake [at] acm.org Fred L. Drake, Jr. mprakash [at] acm.org Praki Prakash roggenkamps [at] acm.org Steve Roggenkamp doyle [at] aps.org Mark Doyle herisman [at] cas.org Howard Erisman cowan [at] locke.ccil.org John Cowan donkiely [at] computer.org Don Kiely nospam [at] haar.ddns.org Jan Haar vote [at] erle.org Tobias Erle nat [at] nataa.fr.eu.org Nat Makarevitch abby [at] foad.org Abby Franquemont fabien [at] girardin.org Fabien Girardin Paul.V.Biron [at] kp.org Paul V Biron junga [at] leo.org Achim Jung peewee [at] scc.mi.org Jason Wright bkdelong [at] naw.org B.K. DeLong kclark [at] superfly.ntlug.org Kendall Clark hebisch [at] math.uni.wroc.pl Waldemar Hebisch Johan.Dahl [at] ling.lu.se Johan Dahl svante [at] nemesis.se Svante Kleist John.Gotze [at] post.statskontoret.se John Gotze SuanTK [at] ocbc.com.sg Suan Teck Kin cvecwt [at] nus.edu.sg Chan Weng Tat janez.zupanic [at] gov.si Janez @upani~ emt [at] perun.dcs.fmph.uniba.sk Jana Chlebikova hk [at] yore.com.tr Hakan Kalyoncu richard [at] cogsci.ed.ac.uk Richard Tobin norman [at] astro.gla.ac.uk Norman Gray schwarze [at] cs.man.ac.uk Eckhard Schwarzat bmm [at] inf.rl.ac.uk Brian Matthews D.J.Beckett [at] ukc.ac.uk Dave Beckett fqp1 [at] ukc.ac.uk Francisco Queiros Pinto m.mower [at] unl.ac.uk Matt Mower steve.parkinson [at] bellhow.co.uk Steve Parkinson kate.curtis [at] bt-sys.bt.co.uk Katherine Curtis nickle [at] calfp.co.uk Nick Leaton wrigley [at] cre.canon.co.uk Ave Wrigley john_singleton [at] chrystal.co.uk John Singleton Hammy [at] croila.demon.co.uk Hamish Bell marty [at] ehabitat.demon.co.uk Martin McCarthy js [at] jswan.demon.co.uk Johnathan Swan richard [at] light.demon.co.uk Richard Light alan.ralph [at] redunser.demon.co.uk Alan Ralph aidan [at] sgml.demon.co.uk Aidan Killian Margaret [at] syntagma.demon.co.uk Margaret Aldis murble [at] xencat.demon.co.uk William Boughton neal.champion [at] exchange.co.uk Neal Champion M.H.Kay [at] eng.icl.co.uk Michael Kay nik [at] iii.co.uk Nik Clayton trevor [at] rds-ltd.co.uk Trevor Wood ianw [at] sunbather.co.uk Ian Westbrook R.Taylor [at] eris.dera.gov.uk Richard Taylor akuchlin [at] cnri.reston.va.us A.M. Kuchling Voted NO ------------------------------------------------------------------------------ mib [at] deakin.edu.au Mike Battersby chet.ensign [at] bender.com Chet Ensign stainles [at] bga.com Dwight Brown guymacon [at] deltanet.com guymacon@deltanet.com (Guy Macon) tomo [at] everyware.com Tom Otvos jason [at] gaydeceiver.com Jason Steiner cipher [at] mindspring.com Cipher Greg_Baber [at] mindspring.com Gregory Baber olav [at] viking.mv.com Olav Nieuwejaar nwelch1 [at] rochester.rr.com Welch Family eric_albright [at] sprynet.com Eric Albright pan [at] syix.com Pan daver [at] teleport.com David Reynolds tbray [at] textuality.com Tim Bray nolda [at] komma.fddi2.fu-berlin.de Andreas Nolda naddy [at] mips.rhein-neckar.de Christian Weisgerber rick [at] bcm.tmc.edu Richard Miller Emma.K.Antunes.1 [at] gsfc.nasa.gov Emma Kolstad Antunes pbern7 [at] earthlink.net Paul Bernhardt marquez [at] pacbell.net Aaron Marquez tobotras [at] jet.msk.su Boris Tobotras Voting [at] valdena.demon.co.uk AST Abstained ------------------------------------------------------------------------------ cdt [at] audiophile.com Chris Trumbore luisrmcosta [at] gyral.com Lui's Ricardo Costa chris [at] kzim.com Christopher Robin Zimmerman billy-ace.baker [at] smtp.cnet.navy.mil Billy-Ace Baker sean.duffy [at] bbs.goldengate.net Sean Duffy k-j-nore [at] dsv.su.se Karl-Johan Noren peter [at] ursus.demon.co.uk Peter Murray-Rust Invalid votes ------------------------------------------------------------------------------ Christophe.BURTIN [at] OPOCE.cec.be Burtin Kristov ! No vote statement in message m.schneider [at] gis.ibfs.de Dr. Michael Schneider ! Invalid ballot jwv [at] tradoc.fr John Wilcock ! Undeliverable address wish [at] 5.9.0.6.3.6.8.1.8.1.4.4.tpc.int Bill Hay ! Invalid address phetland [at] online.no Jo Hetland ! No vote statement in message -- Neil Crellin, UVV xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sharris at primus.com Wed Jul 15 02:55:35 1998 From: sharris at primus.com (Steve Harris) Date: Mon Jun 7 17:02:52 2004 Subject: Parameter entity reference error with expat Message-ID: <4108F4A8F2E7D011A20300A024513B6001A27CB8@mailsrv.primus.com> I'm working out a small DTD by inlining it with some sample data. It uses a single internal parameter entity and refers to the entity twice in the DTD. Emacs's 'psgml' seems to validate and do all the substitutions as expected. If I run the file through expat, though, it reports the following error: illegal parameter entity reference My understanding of the spec. is that a non-validating parser does not have to expand an external entity, and I could understand that behavior being applied here, but is it truly 'illegal' to use a parameter entity reference in this fashion? Here's a snippet of problematic file: __BEGIN ]> ... __END Note that the ATTLISTs for entities 'flag' and 'arg' attempt to expand an entity called 'entry-atts', for which expat reports an error. I'd appreciate any assistance in interpreting the spec. here. Is expat doing the right thing? Thanks, Steven Harris Software Engineer Primus Knowledge Solutions xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 15 03:08:36 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:53 2004 Subject: Parameter entity reference error with expat In-Reply-To: <4108F4A8F2E7D011A20300A024513B6001A27CB8@mailsrv.primus.com> (message from Steve Harris on Tue, 14 Jul 1998 17:57:31 -0700) Message-ID: <199807150106.VAA26844@ruby.ora.com> [Steve Harris] > If I run the file through expat, though, it reports the following > error: > illegal parameter entity reference [...] > %entry-atts;> The spec states in [29] markupdecl: Well-Formedness Constraint: PEs in Internal Subset In the internal DTD subset, parameter-entity references can occur only where markup declarations can occur, not within markup declarations. (This does not apply to references that occur in external parameter entities or to the external subset.) HTH, 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 david at megginson.com Wed Jul 15 03:14:25 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:53 2004 Subject: Parameter entity reference error with expat In-Reply-To: <4108F4A8F2E7D011A20300A024513B6001A27CB8@mailsrv.primus.com> References: <4108F4A8F2E7D011A20300A024513B6001A27CB8@mailsrv.primus.com> Message-ID: <199807150110.VAA00655@unready.megginson.com> Steve Harris writes: > I'm working out a small DTD by inlining it with some sample data. It > uses a single internal parameter entity and refers to the entity twice > in the DTD. Emacs's 'psgml' seems to validate and do all the > substitutions as expected. If I run the file through expat, though, it > reports the following error: > illegal parameter entity reference You've run up against a somewhat obscure constraint from section 2.8 of the XML 1.0 Recommendation: Well-Formedness Constraint: PEs in Internal Subset In the internal DTD subset, parameter-entity references can occur only where markup declarations can occur, not within markup declarations. (This does not apply to references that occur in external parameter entities or to the external subset.) Source: http://www.w3.org/TR/1998/REC-xml-19980210#sec-prolog-dtd As a result, the following is legal in an _external_ DTD subset, but not in an internal one: PSGML doesn't catch this one yet. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cbullard at hiwaay.net Wed Jul 15 04:43:16 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:02:53 2004 Subject: References: <199807131514.LAA01070@unready.megginson.com> Message-ID: <35AC16D2.C95@hiwaay.net> David Megginson wrote: > > Simon St.Laurent writes: > > > If and when there are XML editing tools that are any good - and my > > pessimism comes from my rather miserable experiences with even the > > latest HTML tools - this may be true. In the meantime, lots and > > lots of experienced coders, the ones most likely to gravitate to > > XML, are still going to be hand-coding. > > By far the best solution is for developers to keep their scripts out > of line and point to them -- that lets each language (programming or > markup) be represented using its natural syntax. Yes. This <% " 'SELECT '&_ %> is a syntax that will sell an editor particularly when spread across concatenated statements on multiple lines. > The advantages are quite significant: > > 1. Ease of authoring: you can create your script using tools > customised for the script's language (such as an Emacs mode) -- > that way, you get syntax highlighting, paren matching, etc., and > don't have to escape XML delimiters. Yes. OTOH, my hope is XML editors are cheap enough to make that having specialized editors for XML application types is common, so the *dirty word coming - semantic* or symbolic representation in an icon hides the markup at the edit level. Remember the final battle cry of SGML authors: HIDE THE MARKUP from the typing-impaired. > 2. Ease of management: since the script is outside of the XML/HTML > document, is easy to create, store, test, and revision separately. Question for the document object model gurus: what happens to the scope and execution order if function calls in event attributes are removed as well as other post-form inline code? Right now we have include statements with different syntaxes in both client and server side scripts. I know it's a neat thing that we can mix VBScript and JavaScript in a page, but wow, if that is OK then is beautiful. > 3. Ease of analysis: someone else looking at your work can easily tell > what is markup and what is code; you don't need an analyst who > knows _both_ XML and the scripting language. That is good separation of work functions. Those of us who have to generally have to know both to create code of that complexity. This brings back a good feature of early SGML systems like the Mentor Context editor where the authors could see markup if they wanted too, but otherwise never saw the scripting. The script language did not mix in the SGML constructs. However, in contrast to HTML, GUI scripting was also separate. I think this is an interesting problem for XML applications to solve since quite a lot of the scripting in web pages supports the GUI. I understand of course, that the IE event model opens up all objects for events so

4. Modularity: since the script is self-contained, it is easy to > replace it later without necessarily editing the original document. Yes as long as the namespace relationships are easy to track for the author of the code but again, no worse than include files. > 5. Ease of Reuse: since the CSS, ECMAScript, or whatever stands alone, > you can reuse the same script for many documents, and all documents > will register changes instantly and automatically. Yes. Include statements. More? > The disadvantage is that management becomes difficult when there are > dozens (or hundreds) of small code fragments rather than one large one That is the web in general, so folks are used to it. > -- that is why my advice does not yet apply to literate programming > (at least, not until there's good tool support). Or generalized literacy. :-) len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From schampeo at hesketh.com Wed Jul 15 05:05:03 1998 From: schampeo at hesketh.com (Steven Champeon) Date: Mon Jun 7 17:02:53 2004 Subject: In-Reply-To: <35AC16D2.C95@hiwaay.net> Message-ID: On Tue, 14 Jul 1998, len bullard wrote: > Question for the document object model gurus: what happens to the scope > and execution order if function calls in event attributes are removed > as well as other post-form inline code? Oddly enough, the only thing that is supported by both Big Browser Vendors in a fairly consistent manner is just this sort of embedded event handling. Remove this, and you're left to the idiosyncracies of the event bubbling model versus the "you have to ask" model provided by Netscape. AFAIK, the DOM stuff doesn't go so far as to prescribe the manner in which a given event is propogated, preferring to remain well in the world of IDLs and other high-level stuff like object inheritance hierarchies. Somebody please correct me if I'm wrong. > > 4. Modularity: since the script is self-contained, it is easy to > > replace it later without necessarily editing the original document. > > Yes as long as the namespace relationships are easy to track for > the author of the code but again, no worse than include files. I must say this was something that gave me the screaming fantods, when I realized that there seemed to be no way to track the namespace of a given Javascript function - I wanted to provide the name of the included file in a debug statement, but there is no difference between function tim() in one included Javascript from function tim() in another - the latest one is kept and all others blown away. For all practical intents and purposes, they may as well be one inline Javascript. There isn't even a simple package function like Perl has. > > The disadvantage is that management becomes difficult when there are > > dozens (or hundreds) of small code fragments rather than one large one > > That is the web in general, so folks are used to it. People are becoming more and more aware of the enormous cost involved, however. Saying Web folks are just "used to it" is adding to an already ridiculous burden. S -- "All the good geek things, | schampeo@hesketh.com only without all the | http://a.jaundicedeye.com bad geek things." | http://hesketh.com/schampeo/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 15 07:49:07 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:02:53 2004 Subject: XLF Initiative Status Message-ID: <019b01bdafb3$15f5f7d0$2ee044c6@arcot-main> Hello, I have promised to keep everyone on XML-DEV updated as the XLF Initiative progresses. Below is the latest status of the XLF Intiative. BTW, the XLF Initiative Home Page is at: http://www.docuverse.com/xlf/ ============================================================================ ==== MOMENTUM We now have well over 50 participants from small and large companies, universities, government, and research institutes. In another word, XLF is picking up steam. HELP WANTED We now have our Editors: Gavin Thomas Nicol and Lisa Rein. Gavin is, of course, well known to everyone in the XML world. Frankly, I don't know how Gavin will be able to split his time between the DOM spec and XLF spec but I am grateful for his participation. Lisa Rein was a member of the RDF WG and has written countless articles, reports. Lisa also holds the title of World's Prettiest XML Nut (see http://www.finetuning.com/editor.html). INGREDIENTS I have invited web server log analyzer companies and they actually showed up! We now need to invite some of the missing notable server companies/groups like Apache, Netscape, and Sun. I am open to suggestions and especially contact informations. OBJECTIVES XLF Initiative's immediate goal is to design the XML-based web server log format. Its long term goal remains to be the design of universal log format based on XML. NAMES Until now, the name XLF has been thrown about careless but now is the time to clarify things a bit. "XLF Initative" is the name of our group. I use the word "initiative" because this group exists only while it is moving. "XLF Specification" is the Core specification that specifies the common elements and attributes used to build application specific formats. "XLF-HTTP Specification" is the specification for Extensible Log Format for Web Server Logs. This is our immediate goal. HOMEWORK I would like everyone to be familiar with the "Extended Log Format" specification which is available at http://www.w3c.org/TR/WD-logfile In light of our new immediate objective, the spec has added importance to our own effort and could serve as a common ground of understanding so that we can communicate more effectively. GOODBYTE That is all for now. Remember that XLF is not a shopping mall. XLF is more like that bus in the movie "Speed" and you are on it. Do something about it. Best wishes, Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tms at ansa.co.uk Wed Jul 15 11:41:16 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:53 2004 Subject: Validating XML constraints with psgml (was: Parameter entity ...) In-Reply-To: David Megginson's message of "Tue, 14 Jul 1998 21:10:53 -0400" References: <4108F4A8F2E7D011A20300A024513B6001A27CB8@mailsrv.primus.com> <199807150110.VAA00655@unready.megginson.com> Message-ID: David> David Megginson => In article <199807150110.VAA00655@unready.megginson.com>, David => wrote: David> You've run up against a somewhat obscure constraint from section David> 2.8 of the XML 1.0 Recommendation: David> David> Well-Formedness Constraint: PEs in Internal Subset David> David> In the internal DTD subset, parameter-entity references can David> occur only where markup declarations can occur, not within David> markup declarations. (This does not apply to references that David> occur in external parameter entities or to the external David> subset.) David> David> Source: David> David> David> PSGML doesn't catch this one yet. It's true that psgml itself doesn't catch this; however, it does provide a means of calling an external parser (C-c C-v). You can set this parser using the variable sgml-validate-command - in my case, I use "nsgmls -s %s %s" (the default) for SGML files, and for XML files I use "nsgmls -wxml -s %s %s". You could also use this variable to do application-level validation. For example, you might want to check that the target of an IDREF attribute is of a particular type. You could do that using a DSSSL processor with a style sheet that checks for errors. (Although I've given up trying to write a stylesheet that works with the -wxml flag; instead I validate the XML restrictions seperately.) -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 15 12:00:04 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:53 2004 Subject: Parser question... (DTD pre-parsng) Message-ID: <001801bdafd7$b0eb9320$1e09e391@mhklaptop.bra01.icl.co.uk> Kim Covil wrote > >...I have been wondering whether there are any >tools out there that will 'cache' the parsing of a DTD... As all >our resources use the same DTD, each time a view is created the >xml file is parsed... the DTD is referenced... the DTD is parsed >and then the xml is validated... > A very interesting question. I had the same thought about a related problem: the cost of repeated parsing and validation of the same XML document instance. I did a few experiments to try and devise a format for "pre-parsed XML" that would be faster to read than the original. My experiments failed, mainly I think because most of the formats I tried used a greater number of bytes than the original, and the parsing cost is dominated by the "read next byte" cost. For reference, the three formats I played with were: - a file representing a sequence of SAX events - a Java serialisation of this sequence - a variant of James Clark's "canonical XML" (with tricks such as minimized end tags) I came to the conclusion that the last of these could give a slight saving but the gain isn't worth the pain. The only practical way I found of cutting out repeated work was to remove the DTD reference once I know the document is valid. With very few exceptions (e.g. white space handling, attribute defaults) the presence of a DTD makes no difference to the processing of a valid document, other than to add to its cost. And if these features (white space, default attributes) are important, you can apply them to the instance in a preprocessing stage. 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 jmtang at us.ibm.com Wed Jul 15 16:53:50 1998 From: jmtang at us.ibm.com (jmtang@us.ibm.com) Date: Mon Jun 7 17:02:53 2004 Subject: HTML to XML converter Message-ID: <85256640.006762C5.00@us.ibm.com> Hi: I am working on a project that needs to convert any HTML to XML. Is there any available tool? If I want to write a tool with HTML file as my input and XML as my output, can I use any XML parser to parse the HTML file? Jung-Mu Tang xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From magnus.ahlden at foreningssparbanken.se Wed Jul 15 17:01:12 1998 From: magnus.ahlden at foreningssparbanken.se (Magnus Ahlden) Date: Mon Jun 7 17:02:53 2004 Subject: HTML to XML converter References: <85256640.006762C5.00@us.ibm.com> Message-ID: <35ACC3B2.2301@foreningssparbanken.se> jmtang@us.ibm.com wrote: > > Hi: > I am working on a project that needs to convert any HTML to XML. Is there > any available tool? If I want to write a tool with HTML file as my input > and XML as my output, can I use any XML parser to parse the HTML file? That would be actually quite difficult. E.g. XML alone has no means for presentation. /with regards Magnus xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jul 15 17:09:14 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:53 2004 Subject: HTML to XML converter In-Reply-To: <85256640.006762C5.00@us.ibm.com> References: <85256640.006762C5.00@us.ibm.com> Message-ID: <199807151505.LAA06572@unready.megginson.com> jmtang@us.ibm.com writes: > I am working on a project that needs to convert any HTML to XML. > Is there any available tool? If I want to write a tool with HTML > file as my input and XML as my output, can I use any XML parser to > parse the HTML file? What XML document type are you converting the HTML original to? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rhanson at blast.net Wed Jul 15 17:17:28 1998 From: rhanson at blast.net (Robert Hanson) Date: Mon Jun 7 17:02:53 2004 Subject: HTML to XML converter Message-ID: <00b301bdb003$857268a0$12b919ce@Bertha> >I am working on a project that needs to convert any HTML to XML. Is there >any available tool? Not that I know of.... unless you a text processing language like Perl a tool ( I do ). There will be things like this in the future, but I think it mostly depends on how exactly you want it converted. In a project I did, the XML version only barely resembled the HTML version... the XML was grouped differently than the HTML page. This required a custom solution. ...On the other hand, if you want something that is just XML compliant, then that is a whole other story. So I guess it depends on exactly what you want to do, >can I use any XML parser to parse the HTML file? The XML parser will only parse the XML file, not the HTML file... so no. Once the HTML is XML complient then the answer is still no ( because it seems that most of the parsers out there are not 100% complient, but are working on it ). ...But most XML parsers ( if not all ) should work with it, assuming that the XML document is "normal"... like UTF-8. Robert Hanson xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 15 17:19:31 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:53 2004 Subject: Message-ID: DM> > The disadvantage is that management becomes difficult when there are DM> > dozens (or hundreds) of small code fragments rather than one large one > LB>> That is the web in general, so folks are used to it. > SC>People are becoming more and more aware of the enormous cost involved, SC>however. Saying Web folks are just "used to it" is adding to an already SC>ridiculous burden. I agree with Steven Champeon - let's not get into the habit of allowing costly management strategies just because they're already employed in the impromptu world of HTML or the more (and less) structured world of SGML. XML already has a difficult enough burden to carry as its inheritance. I had the pleasure of working with someone who kept track of 10,000 pages and their dependencies in her head. There were basic rules, but she could keep track of the (many) exceptions as well. If only I could find a product that did nearly as good a job as she did, then maybe these issues wouldn't be so critical. Until then, I'd rather not see them shrugged off. I would _much_ rather see efforts to encourage Web developers to move to XML because of its ease of use than "well, it's not any worse". XML may be skyrocketing in anouncements for data applications, but getting Web developers to use it on its supposed killer app is going to take a lot of further development and consideration for the needs of that application. 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 jmtang at us.ibm.com Wed Jul 15 20:58:47 1998 From: jmtang at us.ibm.com (jmtang@us.ibm.com) Date: Mon Jun 7 17:02:53 2004 Subject: HTML to XML Message-ID: <85256642.00671BAC.00@us.ibm.com> Sorry that I did not make the question clear. What I am working on is to retrieve some information, e.g. news articles, from the web and feed the content to an application client which only knows application-specific XML. Therefore, I need to read the HTML file, analyze it, strip away all presentation tags/contents, and convert the real content to the application-specific XML. Instead of writing my own HTML parser, I hope I can find some tool to help me or hopefully one of the XML parser can do the job. I prefer Java, but I'll consider anything available. Jung-Mu Tang xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From gang at cs.wisc.edu Wed Jul 15 22:52:33 1998 From: gang at cs.wisc.edu (Gang He) Date: Mon Jun 7 17:02:53 2004 Subject: C++ XML Parser Message-ID: <35AD1687.2DA5@cs.wisc.edu> Hi,all: I am currently working on a project which requires to parse big XML files(like 10-100MB). I did it by using Java parser from DataChannel. But it turns out it is very slow. And the project doesn't allow me to convert the java bytecode executables into native executables. So I am trying to find a standalone C++ XML parser for Unix. Because my progarm runs on Unix, Microsoft's C++ parser(I guess it only runs on Windows) seems not suitable for me and also that one seems only embeded in IE4.0, not a satndalone one. Could anyone please give me some info about C++ parser for Unix? Many thanks in advance. Gang He xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From eriblair at mediom.qc.ca Thu Jul 16 01:01:51 1998 From: eriblair at mediom.qc.ca (eriblair@mediom.qc.ca) Date: Mon Jun 7 17:02:53 2004 Subject: Let's talk... Message-ID: <199807152300.SAA19231@x13.dejanews.com> Hello, Today, I created a forum at Deja News where we can discuss things online. It's our own forum and is called: dejanews.members.tech.eriblair.dhtml-and-mac and I described it like this: The development of DHTML using applet, activeX , ... for the Macintosh environment. If you are already registered for My Deja News, go here to join our new forum http://www.dejanews.com/%5BST_uf=1%5D/rg_join.xp?m=1&u=xml-dev@ic.ac.uk&g=dejanews.members.tech.eriblair.dhtml-and-mac Or, if you haven't registered for My Deja News, go here http://www.dejanews.com/%5BST_uf=1%5D/rg_join.xp?u=xml-dev@ic.ac.uk&g=dejanews.members.tech.eriblair.dhtml-and-mac Now, here's some stuff Deja News wants to tell you to help you out. By joining 's new discussion forum you will automatically get a Free My Deja News account. This means you will also be able to read and participate in more than 50,000 other high quality discussions on almost every conceivable topic, from sports to parenting to java development. We will also give you a free email account you can use to participate in any discussion on the Internet without worrying about people sending spam email to your permanent account. You can even create your own free discussion forum. Deja News was recently named one of the Top 10 Essential Web Sites by Yahoo! Internet Life magazine. We look forward to seeing you soon! The Deja News Team :-) --------------------------------------------------------------------- Deja News - The Discussion Network http://www.dejanews.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mrc at allette.com.au Thu Jul 16 01:17:54 1998 From: mrc at allette.com.au (Marcus Carr) Date: Mon Jun 7 17:02:53 2004 Subject: Parser question... References: <199807131515.AA24949@zydeco> Message-ID: <35AD3872.4DACBFAA@allette.com.au> Kim Covil wrote: > We are reasonably happy with the way this works although a touch > more speed would be helpful as the views the scripts create are > created on the fly... I have been wondering whether there are any > tools out there that will 'cache' the parsing of a DTD... As all > our resources use the same DTD, each time a view is created the > xml file is parsed... the DTD is referenced... the DTD is parsed > and then the xml is validated... This may not fit with the rest of your suite of tools, but for the record, OmniMark will allow what you describe. A common complaint in the past was the fact that invocation of the application and recognition of the DTD often took longer than processing the data - this has been addressed by allowing any number of DTDs to be read in, then any number of instances to be processed by a continually running application. -- 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 sblackbu at erols.com Thu Jul 16 02:24:24 1998 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:02:53 2004 Subject: C++ XML Parser Message-ID: <001501bdb04f$fc9d63c0$432e0318@cc221812-a.hwrd1.md.home.com> If you don't need validation, take a look at my freeware C++ parser at http://ourworld.compuserve.com/homepages/sam_blackburn/wfc.htm I've ported it to Unix and it works fine. I haven't tried it on such a big XML file though. Hope this helps, Sam -----Original Message----- From: Gang He To: xml-dev@ic.ac.uk Date: Wednesday, July 15, 1998 4:54 PM Subject: C++ XML Parser >Hi,all: >I am currently working on a project which requires to parse big XML >files(like 10-100MB). I did it by using Java parser from DataChannel. >But it turns out it is very slow. And the project doesn't allow me to >convert the java bytecode executables into native executables. So I am >trying to find a standalone C++ XML parser for Unix. Because my progarm >runs on Unix, Microsoft's C++ parser(I guess it only runs on Windows) >seems not suitable for me and also that one seems only embeded in IE4.0, >not a satndalone one. >Could anyone please give me some info about C++ parser for Unix? Many >thanks in advance. >Gang He > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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 Thu Jul 16 02:34:21 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:54 2004 Subject: HTML to XML In-Reply-To: <85256642.00671BAC.00@us.ibm.com> References: <85256642.00671BAC.00@us.ibm.com> Message-ID: <199807160030.UAA00202@unready.megginson.com> jmtang@us.ibm.com writes: > Sorry that I did not make the question clear. What I am working on > is to retrieve some information, e.g. news articles, from the web > and feed the content to an application client which only knows > application-specific XML. Therefore, I need to read the HTML file, > analyze it, strip away all presentation tags/contents, and convert > the real content to the application-specific XML. Instead of > writing my own HTML parser, I hope I can find some tool to help me > or hopefully one of the XML parser can do the job. I prefer Java, > but I'll consider anything available. To my knowledge, there has never been a general SGML parser written in Java; however, there is a Java-based HTML parser with much SGML functionality that was written originally for HotJava. I have no idea where it lives right now, but it might be worth poking around. Another alternative, if the HTML really is valid HTML, is to do a first pass with James Clark's SX application (part of SP) to convert the HTML to well-formed XML, then do the rest of the work in Java with XML parsers. We desperately need a SAX parser that parses HTML instead of XML -- any takers? 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 kent at trl.ibm.co.jp Thu Jul 16 02:59:59 1998 From: kent at trl.ibm.co.jp (TAMURA Kent) Date: Mon Jun 7 17:02:54 2004 Subject: HTML to XML In-Reply-To: jmtang@us.ibm.com's message of "Wed, 15 Jul 1998 14:57:23 -0400" <85256642.00671BAC.00@us.ibm.com> References: <85256642.00671BAC.00@us.ibm.com> Message-ID: <199807160058.JAA29242@ns.trl.ibm.com> In message "HTML to XML" on 98/07/15, jmtang@us.ibm.com writes: > application-specific XML. Instead of writing my own HTML parser, I hope I > can find some tool to help me or hopefully one of the XML parser can do the > job. I prefer Java, but I'll consider anything available. `HTML TIDY' by Dave Raggett parse a HTML document and correct it and can convert it to XML. http://www.w3.org/People/Raggett/tidy/ -- TAMURA, Kent @ Tokyo Research Laboratory, IBM Japan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Thu Jul 16 09:48:12 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:54 2004 Subject: HTML to XML In-Reply-To: <199807160030.UAA00202@unready.megginson.com> References: <85256642.00671BAC.00@us.ibm.com> <85256642.00671BAC.00@us.ibm.com> Message-ID: <3.0.1.16.19980716080713.096fbda8@pop3.demon.co.uk> At 20:30 15/07/98 -0400, David Megginson wrote: > >We desperately need a SAX parser that parses HTML instead of XML -- >any takers? I agree completely. The SwingSet (from com.sun.java) has HTML functionality. I'm not sure exactly what, but it can read in HTML and render it. Since Swing is very well written (and based in part on SGML ideas) it wouldn't surprise me if much of what we want is hidden within it. There is a list for Swing at http://www.eos.dk/archive/swing - perhaps someone could ask. 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 Jul 16 09:48:15 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:54 2004 Subject: Use of XML-DEV@ic.ac.uk (was Re: Let's talk...) In-Reply-To: <199807152300.SAA19231@x13.dejanews.com> Message-ID: <3.0.1.16.19980716082059.096f619e@pop3.demon.co.uk> I'm slightly mystified by this message. At 18:00 15/07/98 -0500, eriblair@mediom.qc.ca wrote: > >Hello, > >Today, I created a forum at Deja News where we can discuss >things online. It's our own forum and is called: Is this a real-time chat forum? > >dejanews.members.tech.eriblair.dhtml-and-mac > >and I described it like this: > > The development of DHTML using applet, activeX , ... for the >Macintosh >environment. XML-DEV has virtually no discussion of any of these topics > >If you are already registered for My Deja News, go here to join >our new forum > >http://www.dejanews.com/%5BST_uf=1%5D/rg_join.xp?m=1&u=xml-dev@ic.ac.uk&g=d ejanews.members.tech.eriblair.dhtml-and-mac > If I understand this URL correctly, you have set up an interactive system to discuss what happens on XML-DEV. I certainly wasn't consulted about this and I doubt that Henry was. At first sight it seems discourteous to set up a facility to discuss someone else's list *without consulting the list moderator(s)*. Of course you are welcome to set up an XML discussion forum, but I think it is not appropriate to refer to it by the name xml-dev nor to imply that it is in any way associated with xml-dev@ic.ac.uk I know little about your Deja News system - but your posting has something of the air of an advertisement and the flavour of something that is re-used in other contexts. I'd be grateful for a reply. If not I shall have to make it clear that xml-dev at Deja News has no formal connection with xml-dev@ic.ac.uk In any case, if the members of XML-DEV wish a char facility I have had many years in setting up virtual environments and Henry and I would see it as our role to consider how it should be best done. We have built up a virtual community on XML-DEV which is of top quality and we wish to develop it in pour own way. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jul 16 11:57:35 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:02:54 2004 Subject: C++ XML Parser In-Reply-To: <35AD1687.2DA5@cs.wisc.edu> Message-ID: <3.0.1.32.19980716115515.00d5969c@ifi.uio.no> * Gang He > >I am currently working on a project which requires to parse big XML >files(like 10-100MB). I did it by using Java parser from DataChannel. >But it turns out it is very slow. And the project doesn't allow me to >convert the java bytecode executables into native executables. So I am >trying to find a standalone C++ XML parser for Unix. DXP seems to be much slower than the other XML parsers, and informal tests done by myself at home had XP parsing documents about 10 times faster than DXP. (This test was done on only a single large document and with previous versions of both parsers, so your results may be different.) So perhaps you should switch parsers to XP, Lark or AElfred, which all have comparable speed. (And of course, you've used SAX so that you can change parsers without changing your code?) Anyway, you can find a complete list of all free C++ and Java parsers at --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jul 16 12:07:08 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:02:54 2004 Subject: HTML to XML In-Reply-To: <199807160030.UAA00202@unready.megginson.com> References: <85256642.00671BAC.00@us.ibm.com> <85256642.00671BAC.00@us.ibm.com> Message-ID: <3.0.1.32.19980716120442.006dc984@ifi.uio.no> * David Megginson > >We desperately need a SAX parser that parses HTML instead of XML -- >any takers? It seems that Anders Kristiansen already has done this, his HEX (HTML-Enabled XML parser) claims to parse both HTML and XML. I haven't checked the level of support, but it might be useful, and the current version supports the old SAX draft. (He's stated in private email that he probably will release a version with a SAX 1.0 driver.) The URL is Feedback on how useful the program is would be appreciated, so that my coverage of this parser on my XML tools list could be improved. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jamesr at steptwo.com.au Thu Jul 16 14:13:44 1998 From: jamesr at steptwo.com.au (James Robertson) Date: Mon Jun 7 17:02:54 2004 Subject: HTML to XML In-Reply-To: <85256642.00671BAC.00@us.ibm.com> Message-ID: <199807161213.WAA17782@oznet11.ozemail.com.au> At 04:57 16/07/1998 , you wrote: | Sorry that I did not make the question clear. What I am working on is to | retrieve some information, e.g. news articles, from the web and feed the | content to an application client which only knows application-specific XML. | Therefore, I need to read the HTML file, analyze it, strip away all | presentation tags/contents, and convert the real content to the | application-specific XML. Instead of writing my own HTML parser, I hope I | can find some tool to help me or hopefully one of the XML parser can do the | job. I prefer Java, but I'll consider anything available. This sounds like a job for a custom-written translation. In particular: * You are only interested in a specific set of tags within the HTML, which you can convert to a particular "meaning". The rest you throw away, or convert to some standard form. * You presumably have some XML DTD that you want to convert to, and it sounds like it is fairly specific for your needs. I would recommend using a text processing environment like Perl, or my preferred tool, Omnimark. Particularly if you want to do this in a stable, ongoing fashion. I would steer away from using an XML parser, and trying to build a conversion package yourself. Let someone else do the hard work for you ... ;-) Cheers, J ------------------------- James Robertson Step Two Designs Pty Ltd SGML, XML & HTML Consultancy http://www.steptwo.com.au/ jamesr@steptwo.com.au "Beyond the Idea" ACN 081 019 623 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jul 16 14:48:13 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:54 2004 Subject: HTML to XML In-Reply-To: <3.0.1.16.19980716080713.096fbda8@pop3.demon.co.uk> References: <85256642.00671BAC.00@us.ibm.com> <199807160030.UAA00202@unready.megginson.com> <3.0.1.16.19980716080713.096fbda8@pop3.demon.co.uk> Message-ID: <199807161244.IAA00256@unready.megginson.com> Peter Murray-Rust writes: > The SwingSet (from com.sun.java) has HTML functionality. I'm not > sure exactly what, but it can read in HTML and render it. Since > Swing is very well written (and based in part on SGML ideas) it > wouldn't surprise me if much of what we want is hidden within > it. There is a list for Swing at http://www.eos.dk/archive/swing - > perhaps someone could ask. A quick peek inside swingall.jar shows that there is a package com.sun.java.swing.text.html. Within the package (and judging from namesa alone), the following classes look like good starting points: - com.sun.java.swing.text.html.HTMLDocument - com.sun.java.swing.text.html.HTMLEditorKit - com.sun.java.swing.text.html.HTMLStyleCallback - com.sun.java.swing.text.html.HTMLWriter - com.sun.java.swing.text.html.StyleSheet I have not had a chance to dig through the JavaDoc's yet, but it may be that we can write at least a partial SAX driver on top of this. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jul 16 15:13:13 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:54 2004 Subject: SAX: AttributeList in startElement In-Reply-To: <199807142028.WAA22494@berlin.dvs1.tu-darmstadt.de> References: <199807142028.WAA22494@berlin.dvs1.tu-darmstadt.de> Message-ID: <199807161309.JAA00358@unready.megginson.com> Ron Bourret writes: > If an element doesn't have any attributes, should the AttributeList > argument in DocumentHandler.startElement be null or empty? I think that it should be empty rather than null (it simplifies client code that way), but I failed to specify that in the docs. I'd be interested in hearing what current implementors have done. Thanks for pointing this out, and all the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jul 16 15:25:52 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:02:54 2004 Subject: SAX: AttributeList in startElement In-Reply-To: <199807161309.JAA00358@unready.megginson.com> References: <199807142028.WAA22494@berlin.dvs1.tu-darmstadt.de> <199807142028.WAA22494@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.32.19980716152351.0070b2bc@ifi.uio.no> * David Megginson > >I think that it should be empty rather than null (it simplifies client >code that way), but I failed to specify that in the docs. I'd be >interested in hearing what current implementors have done. The Python version of SAX consistenly uses empty AttributeLists, for exactly the reason you describe. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Thu Jul 16 16:29:50 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:55 2004 Subject: HTML to XML Message-ID: <005601bdb0c6$8cab6d60$1e09e391@mhklaptop.bra01.icl.co.uk> -----Original Message----- From: Peter Murray-Rust To: xml-dev@ic.ac.uk Date: 16 July 1998 08:50 Subject: Re: HTML to XML >At 20:30 15/07/98 -0400, David Megginson wrote: >> >>We desperately need a SAX parser that parses HTML instead of XML -- >>any takers? > >The SwingSet (from com.sun.java) has HTML functionality. I'm not sure >exactly what, but it can read in HTML and render it. Good thinking. I've had a look at the Swing source. It includes a parser (html32.java) generated using the java compiler-compiler JavaCC. This calls a callback interface HTMMLParserCallback.java, similar in concept to SAX, though it seems to include both generic (start/end element) and element-specific (e.g. startUL) callbacks. Of course the main difference from a SAX application will be that the elements are not properly nested. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 16 17:13:20 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:55 2004 Subject: C++ XML Parser In-Reply-To: <3.0.1.32.19980716115515.00d5969c@ifi.uio.no> References: <35AD1687.2DA5@cs.wisc.edu> Message-ID: <3.0.1.16.19980716154606.0d57fd38@pop3.demon.co.uk> At 11:55 16/07/98 +0200, Lars Marius Garshol wrote: > > >DXP seems to be much slower than the other XML parsers, and informal >tests done by myself at home had XP parsing documents about 10 times >faster than DXP. (This test was done on only a single large document >and with previous versions of both parsers, so your results may be >different.) > I have been using DXP for validation when required and have found that it is not only slow but can throw OutOfMemoryError for large documents. This is with a version about 1998-02 - I am not clear whether there is a later one. [I didn't find a SAX1.0-compliant one last time I looked.] I normally use AElfred as my non-validating parser under SAX and have switched to using xml4j for the validating parser which has managed an 11 Mbyte document for me without problems. 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 Jul 16 17:13:30 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:55 2004 Subject: HTML to XML In-Reply-To: <005601bdb0c6$8cab6d60$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <3.0.1.16.19980716155400.791f673e@pop3.demon.co.uk> At 15:32 16/07/98 +0100, Michael Kay wrote: >> >PMR>The SwingSet (from com.sun.java) has HTML functionality. >>I'm not sure >>exactly what, but it can read in HTML and render it. > >Good thinking. I've had a look at the Swing source. It >includes a parser (html32.java) generated using the java >compiler-compiler JavaCC. This calls a callback interface >HTMMLParserCallback.java, similar in concept to SAX, though >it seems to include both generic (start/end element) and >element-specific (e.g. startUL) callbacks. Of course the >main difference from a SAX application will be that the >elements are not properly nested. I assume that *after* it has parsed the HTML there is something isomorphic to a DOM inside and this must have properly nested elements. [I appreciate that really bad HTML may give erroneous results, but that is not our problem.]. It should then be possible to extract this as xHTML and: (a) mix it with other XML (b) render it in the Swing Component The other thing I'd like to do is generate HTML as a string (e.g String s = "

Hello world

"; and pass s to the renderer. Any idea how? This would then give us part of an XML2HTML renderer in Swing P. BTW I am making progress with JUMBO2beta. I have had a moderate amount of feedback, all of which was very useful. I am really keen that we use Swing to enhance our functionality here. Also, someone told me yesterday that the next versions of Swing were promised to be much faster and better...RSN P. > >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) > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Thu Jul 16 19:28:28 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:55 2004 Subject: HTML to XML In-Reply-To: <005601bdb0c6$8cab6d60$1e09e391@mhklaptop.bra01.icl.co.uk> References: <005601bdb0c6$8cab6d60$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <199807161724.NAA00210@unready.megginson.com> Michael Kay writes: > Good thinking. I've had a look at the Swing source. It > includes a parser (html32.java) generated using the java > compiler-compiler JavaCC. This calls a callback interface > HTMMLParserCallback.java, similar in concept to SAX, though > it seems to include both generic (start/end element) and > element-specific (e.g. startUL) callbacks. Of course the > main difference from a SAX application will be that the > elements are not properly nested. The SAX driver could enforce proper nesting using an element stack and various heuristics, but it might not always get it right. 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 macherius at darmstadt.gmd.de Thu Jul 16 20:02:58 1998 From: macherius at darmstadt.gmd.de (Ingo Macherius) Date: Mon Jun 7 17:02:55 2004 Subject: HTML to XML In-Reply-To: <85256642.00671BAC.00@us.ibm.com> Message-ID: <199807161801.UAA03141@sonne.darmstadt.gmd.de> jmtang@us.ibm.com wrote at 15 Jul 98, 14:57: > What I am working on is to > retrieve some information, e.g. news articles, from the web and feed the > content to an application client which only knows application-specific XML. So are we. > Therefore, I need to read the HTML file, analyze it, strip away all > presentation tags/contents, and convert the real content to the > application-specific XML. So you don't want HTML->XML but "arbitrary, somewhat regular string" to XML. Buggy HTML is just that, a somewhat regular string. You want to extract information and map it to a Schema, e.g. an XML-DTD. Right ? > Instead of writing my own HTML parser, I hope I > can find some tool to help me or hopefully one of the XML parser can do the > job. I prefer Java, but I'll consider anything available. Please have a look at http://www.darmstadt.gmd.de/oasys/projects/jedi/jedie.html http://www.darmstadt.gmd.de/oasys/projects/jedi/jp.pdf The online demos already use Jedi 2.0, which is currently being prepared for (*.class only) distribution. Expect 2.0 for download in about 7 days. The current downloadable version is 0.1, which is about 2 years old. ++im -- Ingo Macherius//Dolivostrasse 15//D-64293 Darmstadt//+49-6151-869-882 GMD-IPSI German National Research Center for Information Technology mailto:macherius@gmd.de http://www.darmstadt.gmd.de/~inim/ Information!=Knowledge!=Wisdom!=Truth!=Beauty!=Love!=Music==BEST (Zappa) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Jul 16 21:44:49 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:55 2004 Subject: C++ XML Parser In-Reply-To: <35AD1687.2DA5@cs.wisc.edu> (message from Gang He on Wed, 15 Jul 1998 15:52:23 -0500) Message-ID: <199807161943.PAA26420@ruby.ora.com> I'm surprised no one's mentioned Expat, formerly xmltok. . This is the toolkit used in Larry Wall's XML::Parser and in Netscape 5.0. -Chris xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 16 22:02:48 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:55 2004 Subject: Perl (was C++ XML Parser) Message-ID: Chris Maden wrote: >Larry Wall's XML::Parser Is there a site for that? My brief search yielded little. 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 pazandak at OBJS.com Thu Jul 16 22:07:00 1998 From: pazandak at OBJS.com (Paul Pazandak) Date: Mon Jun 7 17:02:55 2004 Subject: C++ XML Parser References: <35AD1687.2DA5@cs.wisc.edu> Message-ID: <35AE5DEB.AD85C848@OBJS.com> Gang He, I used Blackburn's XML parser (http://ourworld.compuserve.com/homepages/sam_blackburn/wfc.htm) which I modified and embedded in Mozilla (I wanted C++ objects versus expat's C structs). It worked fine for me [but the design wasn't extension-friendly (at least for my alterations) -- in case you are in need of modifying the parser]. Paul. Gang He wrote: > Hi,all: > I am currently working on a project which requires to parse big XML > files(like 10-100MB). I did it by using Java parser from DataChannel. > But it turns out it is very slow. And the project doesn't allow me to > convert the java bytecode executables into native executables. So I am > trying to find a standalone C++ XML parser for Unix. Because my progarm > runs on Unix, Microsoft's C++ parser(I guess it only runs on Windows) > seems not suitable for me and also that one seems only embeded in IE4.0, > not a satndalone one. > Could anyone please give me some info about C++ parser for Unix? Many > thanks in advance. > -- ******************************************************************** Paul Pazandak pazandak@objs.com Object Services and Consulting, Inc. http://www.objs.com Minneapolis, Minnesota 55420-5409 612-884-9551 ******************************************************************** xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Jul 16 22:10:44 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:55 2004 Subject: Perl (was C++ XML Parser) In-Reply-To: (SimonStL@classic.msn.com) Message-ID: <199807162008.QAA27338@ruby.ora.com> [Simon St.Laurent] > Chris Maden wrote: > >Larry Wall's XML::Parser > > Is there a site for that? My brief search yielded little. . The "eg" directory contains examples of its use, which are partly incomplete; discussion of the module can be found on xml-perl, hosted by ActiveState (). It's a bit old; it uses xmltok instead of Expat. Larry's been working on Unicode support instead, and says that he's pretty much done with that and will be coming back to XML::Parser. It seems to work pretty well, though out of the box it will only build correctly if `ar` implies `ranlib` on your system (e.g., Solaris, Linux). If not (e.g., FreeBSD), run `ranlib` manually on libxmltok.a. If you're on Windows, you have to get the Cygnus tools, or wait for ActiveState to come out with a binary. -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 cbullard at hiwaay.net Fri Jul 17 01:47:18 1998 From: cbullard at hiwaay.net (len bullard) Date: Mon Jun 7 17:02:55 2004 Subject: References: Message-ID: <35AE9098.5A3B@hiwaay.net> Simon St.Laurent wrote: > > DM> > The disadvantage is that management becomes difficult when there are > DM> > dozens (or hundreds) of small code fragments rather than one large one > > > LB>> That is the web in general, so folks are used to it. > > > SC>People are becoming more and more aware of the enormous cost involved, > SC>however. Saying Web folks are just "used to it" is adding to an already > SC>ridiculous burden. > > I agree with Steven Champeon - let's not get into the habit of allowing costly > management strategies just because they're already employed in the impromptu > world of HTML or the more (and less) structured world of SGML. > Until then, I'd rather not see them shrugged off. We neither allow or deny. We propose and implement. If the burden is ridiculous, it is still borne daily. If I was shrugging it off, you might be right. However, in short form, I am noting the situation as is. Modularity is a highly prized goal in any programming or documentation tool. That usually means "lots of little files". The advantages are obvious and practical. From the inception of the web design (eg, transmitting information inside URL strings and headers (get/post)), keeping file sizes small has been a design goal. Otherwise, wav files would be more practical than they are. Bandwidth remains the most pressing problem for complex web applications. It is the management of the namespace with regards to the scripts that is of interest. Not inlining scripts has disadvantages as well. The more pressing issue is how XML systems interact with non-XML systems using the same set of scripting languages. Enterprise integration committees hit this problem head on eventually. However much one chooses to complain or criticize, the current browser models and the languages they support are being used to create both transaction-bound and viewing applications. These are tough to build. If XML concepts can make this easier, que bueno. If not, next. We need to know what the W3C has in mind for scripts on the client and server sides. I know its a tough problem having worked with groups that tried to solve it. Complete separation of script and content is a worthy goal, but a tough design. Best of luck to all who are working on it. len xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From bckman at ix.netcom.com Fri Jul 17 05:27:22 1998 From: bckman at ix.netcom.com (Frank Boumphrey) Date: Mon Jun 7 17:02:55 2004 Subject: Web Typography Message-ID: <01bdb132$52887e40$36addccf@bckman.ix.netcom.com> For those who may be interested, I have added several pages on "web typography" to my web pages. Just follow the typography links. Regards, Frank Frank Boumphrey XML and style sheet info at Http://www.hypermedic.com/style/index.htm Author: - Professional Style Sheets for HTML and XML http://www.wrox.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jul 17 10:18:45 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:02:55 2004 Subject: C++ XML Parser In-Reply-To: <3.0.1.16.19980716154606.0d57fd38@pop3.demon.co.uk> References: <3.0.1.32.19980716115515.00d5969c@ifi.uio.no> <35AD1687.2DA5@cs.wisc.edu> Message-ID: <3.0.1.32.19980717101648.0072a144@ifi.uio.no> * Peter Murray-Rust > >I have been using DXP for validation when required and have found that it >is not only slow but can throw OutOfMemoryError for large documents. This >is with a version about 1998-02 - I am not clear whether there is a later >one. The latest version is 1.0 beta1d, released on June 5th. >[I didn't find a SAX1.0-compliant one last time I looked.] The current version has both SAX 1.0 and DOM support. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Fri Jul 17 10:20:41 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:02:55 2004 Subject: Perl (was C++ XML Parser) In-Reply-To: Message-ID: <3.0.1.32.19980717101720.0072855c@ifi.uio.no> * Chris Maden > >Larry Wall's XML::Parser * Simon St.Laurent > >Is there a site for that? My brief search yielded little. I don't want to "push" my XML tools list here, but it does seem that people need to be told about it. Every parser mentioned by in this thread so far has been on that list for at least a month. I recommend people looking for parsers and other free XML tools to take a look at as a natural part of any search for XML tools. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Fri Jul 17 15:41:55 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:55 2004 Subject: For compatibility Message-ID: <199807171311.PAA20792@berlin.dvs1.tu-darmstadt.de> Section 2.5, "Comments", states that "For compatibility, the string "--" (double-hyphen) must not occur within comments." I figured that this meant the spec authors were not totally happy with this restriction, but they added it for SGML compatibility reasons and that "--" really was not allowed in comments. However, both MSXML and Aelfred allow it. XP does not. Who is correct? Does "for compatibility" mean the parser is not required to support this if it is not interested in SGML compatibility? Is this something special about comments? -- 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 Michael_Durbin at em.fcnbd.com Fri Jul 17 15:53:54 1998 From: Michael_Durbin at em.fcnbd.com (Michael_Durbin@em.fcnbd.com) Date: Mon Jun 7 17:02:55 2004 Subject: Looking for DTD parser Message-ID: <00160C8F.1944@em.fcnbd.com> Greetings... After a number of years away from SGML I'm happy to be working on DTDs once again, this time on an XML initiative. One thing I can use is a DTD (not instance) parser, to validate against the XML spec. Something small that runs on NT is all I really need, nothing fancy. Something that produces a diagram (a la David Megginson's in his book) would be especially nice, but not essential. Any suggestions? Sorry I'm not up on the latest tools available. I last worked with SGML when I was at Datalogics (before Frame acquisition, and Adobe acquisition, etc ) from 1990-93. As a former SGML hack, it's tremendously encouraging to see the best (IMHO) of that technology burst back into my little corner of the world. Thanks in advance for any tips. Michael... ------------------------------------------------------------------ Michael Patrick Durbin, First Chicago NBD Corp. mailto:michael_durbin@em.fcnbd.com Personal: mailto:mdurbin@mcs.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jul 17 15:58:28 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:55 2004 Subject: For compatibility In-Reply-To: <199807171311.PAA20792@berlin.dvs1.tu-darmstadt.de> References: <199807171311.PAA20792@berlin.dvs1.tu-darmstadt.de> Message-ID: <199807171354.JAA00916@unready.megginson.com> Ron Bourret writes: > Section 2.5, "Comments", states that "For compatibility, the string "--" > (double-hyphen) must not occur within comments." > > I figured that this meant the spec authors were not totally happy > with this restriction, but they added it for SGML compatibility > reasons and that "--" really was not allowed in comments. However, > both MSXML and Aelfred allow it. XP does not. > Who is correct? Does "for compatibility" mean the parser is not > required to support this if it is not interested in SGML > compatibility? Is this something special about comments? XP is correct. This constraint is built directly into the grammatical production: [15] Comment ::= '' All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From richard at cogsci.ed.ac.uk Fri Jul 17 17:00:12 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:02:55 2004 Subject: For compatibility In-Reply-To: Ron Bourret's message of Fri, 17 Jul 1998 15:11:06 +0200 Message-ID: <199807171459.PAA05556@stevenson.cogsci.ed.ac.uk> > Who is correct? Does "for compatibility" mean the parser is not required to > support this if it is not interested in SGML compatibility? The spec says: for compatibility A feature of XML included solely to ensure that XML remains compatible with SGML. "For compatibility" is just an explanation of the requirement. You'll notice that all the "for compatibility" comments are associated with "must" or similar wording. So a conforming processor must indicate an error if it encounters -- in a comment. Contrast this with "for interoperability", which does not impose any requirement. This term is used in conjunction with "should" or "may" rather than "must", though I notice that in Section 3.1 it is used with "must", which seems like an error in the standard to me. -- 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 David.T.Jones at cdc.com Fri Jul 17 17:05:25 1998 From: David.T.Jones at cdc.com (Dave Jones) Date: Mon Jun 7 17:02:55 2004 Subject: XSL with a background image Message-ID: <3.0.1.32.19980717155934.00aa6760@euroms.europe.cdc.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1152 bytes Desc: not available Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980717/d00ccc65/attachment.bin From JHouston at walldata.com Fri Jul 17 17:26:46 1998 From: JHouston at walldata.com (JHouston@walldata.com) Date: Mon Jun 7 17:02:56 2004 Subject: Leaving the List Message-ID: After subscribing for a while, it appeared that this mailing list isn't a good fit for me (I need practical info, not theoretical discussions). So I sent email to majordomo asking to unsubscribe, and got a reply telling me that my request had succeeded. Does anyone have a clue why I'm still getting messages every day? True, the volume seems to have been reduced somewhat, but I'm obviously still subscribed, because my email address is nowhere in the "to:" or "cc:" fields of the messages that arrive here. Just xml-dev!ia.ac.uk. (My email reader at work doesn't make the full headers available, so I can't comment on fields that aren't displayed.) Arriving email interrupts my work (intentionally, so I won't overlook anything that's important), and this list produces far too many interruptions. Since I'm not sure of my status with the list server, please reply directly to me. Thanks in advance for any helpful suggestions! xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From JHouston at walldata.com Fri Jul 17 17:33:23 1998 From: JHouston at walldata.com (JHouston@walldata.com) Date: Mon Jun 7 17:02:56 2004 Subject: Leaving the List Message-ID: My suspicions were just verified. I sent a message to the list, and received a copy of it a few minutes later. Apparently I've NOT been unsubscribed, even though majordomo says I have. What does work? Trying it a for second time? > -----Original Message----- > From: JHouston@walldata.com [SMTP:JHouston@walldata.com] > Sent: Friday, July 17, 1998 8:33 AM > To: xml-dev@ic.ac.uk > Subject: Leaving the List > > After subscribing for a while, it appeared that this mailing list > isn't > a good fit for me (I need practical info, not theoretical > discussions). > So I sent email to majordomo asking to unsubscribe, and got a reply > telling me that my request had succeeded ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 17 17:43:13 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:56 2004 Subject: Perl (was C++ XML Parser) In-Reply-To: <3.0.1.32.19980717101720.0072855c@ifi.uio.no> References: Message-ID: <3.0.1.16.19980717163154.9b173dca@pop3.demon.co.uk> At 10:17 17/07/98 +0200, Lars Marius Garshol wrote: > >I don't want to "push" my XML tools list here, but it does Feel free to announce it occasionally :-). It's central to what we do on XML-DEV. And *I* am clearly not keeping up with the tools... 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 Jul 17 17:43:16 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:56 2004 Subject: XSL with a background image In-Reply-To: <3.0.1.32.19980717155934.00aa6760@euroms.europe.cdc.com> Message-ID: <3.0.1.16.19980717163646.a70fec44@pop3.demon.co.uk> At 15:59 17/07/98 +0100, Dave Jones wrote: >Hi all, > >I've been coding some XSL stylesheets for a webpage i'm creating, i wish to >show examples of CSS and XSL, but i'm having difficulties with displaying >a background image on the page. I've tried including the background properties >for in the definition and as a seperate element - both >examples are shown below, but neither seem to work, are background images >supported by Explorer 4.0 and with XSL? Hi, Although I am sure you will get helpful replies from members of XML-DEV. you would be better to ask directly on the XSL list: XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list 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 cameron at cs.sfu.ca Fri Jul 17 17:54:26 1998 From: cameron at cs.sfu.ca (Rob Cameron) Date: Mon Jun 7 17:02:56 2004 Subject: A different comment syntax question Message-ID: <199807171553.IAA00133@orpheus.cs.sfu.ca> Although the XML specification makes clear that "--" is not allowed in comments, there is another case that is less clear. Can the body of a comment end in a single hyphen, that is, is a comment like "<--A+, A or A--->" legal? There is no explicit mention of this in the text of the specification, but a careful read of the grammar does not allow it. Comment ::= '' Clarification of this issue is important to designers of XML generation tools in particular. If you need to generate an XML comment from an arbitrary string do you have to deal with both the double hyphen case and the trailing hyphen case? If, as I assume, the answer is that only the double hyphen case is a concern, then the grammar needs to be changed. Comment ::= '' Robert D. Cameron, Associate Professor cameron@cs.sfu.ca School of Computing Science FAX: (604) 291-3045 Simon Fraser University Burnaby, B.C., Canada V5A 1S6 Internet Electronic Library Project at SFU http://elib.cs.sfu.ca/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Fri Jul 17 18:03:56 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:56 2004 Subject: A different comment syntax question In-Reply-To: <199807171553.IAA00133@orpheus.cs.sfu.ca> References: <199807171553.IAA00133@orpheus.cs.sfu.ca> Message-ID: <199807171559.LAA01469@unready.megginson.com> Rob Cameron writes: > If, as I assume, the answer is that only the double hyphen case > is a concern, then the grammar needs to be changed. > > Comment ::= '' I imagine that there would be look-ahead problems: a parser would find '--', then see that '-' is the following character, and then report an error. I don't think that anything in the XML 1.0 REC currently requires more than one character look-ahead. As a simple work-around, I'd recommend always adding a space to the beginning and end of your comment string before surrounding it by the delimiters, so you'd have rather than All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Fri Jul 17 18:06:09 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:02:56 2004 Subject: A different comment syntax question In-Reply-To: <199807171553.IAA00133@orpheus.cs.sfu.ca> Message-ID: <199807171606.AA01762@murata.apsdc.ksp.fujixerox.co.jp> Rob Cameron wrote: > > If, as I assume, the answer is that only the double hyphen case > is a concern, then the grammar needs to be changed. > > Comment ::= '' > This is semantically identical to the current rule: Comment ::= '' I agree with you in that your proposal is clearer and more readable. In fact, I did the same proposal prior the XML PR, but it was not accepted. Probably, I should try again in the next version of the XML specification. 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 crism at oreilly.com Fri Jul 17 18:18:50 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:02:56 2004 Subject: A different comment syntax question In-Reply-To: <199807171553.IAA00133@orpheus.cs.sfu.ca> (message from Rob Cameron on Fri, 17 Jul 1998 08:53:55 -0700 (PDT)) Message-ID: <199807171616.MAA25755@ruby.ora.com> [Rob Cameron] > Although the XML specification makes clear that "--" is not allowed > in comments, there is another case that is less clear. Can the body > of a comment end in a single hyphen, that is, is a comment like > "<--A+, A or A--->" legal? There is no explicit mention of this in > the text of the specification, but a careful read of the grammar > does not allow it. Correct. The production reflects the SGML reality that -- ends a comment. In SGML terms: '' could be considered to end the comment declaration, but we're now in error-recovery mode, and outside the scope of the specification. is a legal comment. -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 cameron at cs.sfu.ca Fri Jul 17 18:21:46 1998 From: cameron at cs.sfu.ca (Rob Cameron) Date: Mon Jun 7 17:02:56 2004 Subject: A different comment syntax question Message-ID: <199807171619.JAA00164@orpheus.cs.sfu.ca> Makoto replies: > Rob Cameron wrote: > > > > If, as I assume, the answer is that only the double hyphen case > > is a concern, then the grammar needs to be changed. > > > > Comment ::= '' > > > > This is semantically identical to the current rule: > > Comment ::= '' > No, I don't think it is equivalent. Proof: (a) No string in (Char - '-') ends with a hyphen. (This is the set of all single character strings except the hyphen.) (b) Thus, no string in ('-' (Char - '-')) ends with a hyphen. (c) Thus, no string in ((Char - '-') | ('-' (Char - '-'))) ends with a hyphen. (d) Thus, no string in ((Char - '-') | ('-' (Char - '-')))* ends with a hyphen. Robert D. Cameron, Associate Professor cameron@cs.sfu.ca School of Computing Science FAX: (604) 291-3045 Simon Fraser University Burnaby, B.C., Canada V5A 1S6 Internet Electronic Library Project at SFU http://elib.cs.sfu.ca/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 17 18:54:06 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:56 2004 Subject: XSchema: DTD-to-XSchema converter Message-ID: <199807171650.SAA21583@berlin.dvs1.tu-darmstadt.de> An early version of the DTD-to-XSchema converter is now available from: http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xschema/dtdtoxschema.ht ml This is a SAX parser that parses a DTD and generates SAX XSchema events. Also included is a small SAX application that prints these events to a file, so you can easily convert your DTD files to XSchema files. A few major caveats (see the Web page for minor caveats): * NO ENTITY SUPPORT. I'll try to get this in next week, but what it means right now is that you have to replace entities with actual values before running them through the converter. * STANDALONE DTDs ONLY. For the moment, the converter only reads standalone DTDs (which match the production extSubset). The only real effect is that you can't have (namespace) PIs in the external subset. Is there any reason to support DTDs in the instance file? * SPEC. This supports the latest version of the spec, which will probably be outdated by Monday. Note that the reverse converter (XSchemaToDTD) has not been updated for the latest version of the spec, so those of you wanting to chain them together will just have to wait. As usual, send your bugs and other abuse to me at rbourret@dvs1.informatik.tu-darmstadt.de. Have fun! -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Fri Jul 17 20:29:27 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:56 2004 Subject: Leaving the List In-Reply-To: Message-ID: <3.0.1.16.19980717165123.a5b79108@pop3.demon.co.uk> At 08:39 17/07/98 -0700, JHouston@walldata.com wrote: >My suspicions were just verified. I sent a message to the list, and >received a copy of it a few minutes later. Apparently I've NOT been >unsubscribed, even though majordomo says I have. What does work? >Trying it a for second time? Unsubscription is automatic most of the time, but many things can cause problems (mail addresses can change unbeknownst to the mailer (e.g. the company's gateway is renamed). Also I suspect that majordomo was not written to the same software standards as airplane control systems and it doesn't always 'work'. There is a human in the loop - Henry - who gets zillions of mail messages every week due to this list (about 600 per weekend I think). Most of these announce that someone has gone fishing or the company's server has gone down. However Henry works through them and will take action on 'Please, I can't unsubscribe'. 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 cameron at cs.sfu.ca Fri Jul 17 23:35:58 1998 From: cameron at cs.sfu.ca (Rob Cameron) Date: Mon Jun 7 17:02:56 2004 Subject: A different comment syntax question Message-ID: <199807172135.OAA00397@orpheus.cs.sfu.ca> Thanks to Chris Maden for setting me straight. I have been reading the XML specification without a detailed knowledge of SGML. Although you can do this to an extent, this seems to be one of the small exceptions. (The big exception of course is the issue of parameter-entity references in the external document subset. An area for further work.) Chris Maden writes: > > [Rob Cameron] > > Although the XML specification makes clear that "--" is not allowed > > in comments, there is another case that is less clear. Can the body > > of a comment end in a single hyphen, that is, is a comment like > > "<--A+, A or A--->" legal? There is no explicit mention of this in > > the text of the specification, but a careful read of the grammar > > does not allow it. > > Correct. The production reflects the SGML reality that -- ends a > comment. In SGML terms: > > ' '--' starts the comment. > 'A+, A or A' is the content of the comment. > '--' ends the comment. > '-' is an error. > '>' could be considered to end the comment declaration, but > we're now in error-recovery mode, and outside the scope > of the specification. > > is a legal comment. > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Jul 18 01:24:57 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:56 2004 Subject: XSchema: DTD-to-XSchema converter In-Reply-To: <199807171650.SAA21583@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980718002022.2a1f2436@pop3.demon.co.uk> At 18:50 17/07/98 +0200, Ron Bourret wrote: >An early version of the DTD-to-XSchema converter is now available from: > >http://www.informatik.tu-darmstadt.de/DVS1/staff/bourret/xschema/dtdtoxsche ma.ht >ml Wonderful news. I am getting the impression that the 'current draft' of the spec is close to what we shall end up with - i.e. because of the way it has been developed - in full public view - anyone who has reservations would have said something by now. But are you all planning an final 'evaluation' period for the spec? 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 chris.m.hinds at mail.sprint.com Sat Jul 18 01:58:57 1998 From: chris.m.hinds at mail.sprint.com (chris m hinds) Date: Mon Jun 7 17:02:56 2004 Subject: EDI Message-ID: Xml-dev listeners: I was reading the July 13th issue of Network World and ran across an XML article on page 6 regarding a software product that will bridge the gap between EDI and XML. In this article, it suggests that XML was "concocted somewhat as a replacement for EDI." Is this true? Although I'm an XML novice, I have read quite a few of the XML tutorials and FAQs and have never seen EDI mentioned. I am in the process of writing a basic whitepaper on XML, however, and want to be sure my information is correct. Thanks, Chris Hinds Technology Deployment (Internet Research) Sprint xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From ricker at xmls.com Sat Jul 18 03:05:59 1998 From: ricker at xmls.com (Jeffrey Ricker) Date: Mon Jun 7 17:02:56 2004 Subject: File extensions Message-ID: <199807180105.VAA17267@mclean2.his.com> Has anyone given any thought to XML file extensions? I know that the !DOCTYPE instructions tells the processor what kind of document it is, but I can't see expecting the file operating system to go that far. The extension ".xml" does not seem to be used much. We see instead things like ".cdf". I can not imagine that it is feasible to allow every document type (DTD) its own file extension. Perhaps we could have a double layer of file extensions. The last extension would be ".xml" preceded by an extension for the document type. For example, "mymetadata.rdf.xml" and "mychannelinfo.cdf.xml". These SECONDARY file extensions could be 2, 3, or 4 letters. Perhaps XML-valid HTML documents could be "mypage.html.xml"? On second thought, that's probably silly. Any ideas out there, kids? Jeffrey Ricker ricker@xmls.com XMLSolutions, LLC 601 Pennsylvania Ave. Suite 900, South Bldg. Washington, DC 20004 202.434.8379 http://www.xmls.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sat Jul 18 03:49:53 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:56 2004 Subject: XSchema evaluation period - upcoming Message-ID: Peter Murray-Rust wrote: (Re: XSchema: DTD-to-XSchema converter) >I am getting the impression that the 'current draft' of the spec is close >to what we shall end up with - i.e. because of the way it has been >developed - in full public view - anyone who has reservations would have >said something by now. But are you all planning an final 'evaluation' >period for the spec? It is very close to final. I have one last round of corrections to make, hopefully tomorrow, and section 2 - the 'key' section for most development - will be complete. The glossary in section 1, some namespace issues in section 3, and the big pictures of sections 4 and 5 will still need work, but the foundation will be poured for XSchema 1.0. We do need an evaluation period once these drafts are posted; people are still finding nits. A week sounds like a good idea to me, but what do other people think? There have been good ideas about inheritance and other potentially exciting stuff coming in. I'd like to hammer out 1.0, but be ready for 1.1 and 2.0! (If the W3C doesn't scoop this up before we get there, of course.) 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 CurtA at worldnet.att.net Sat Jul 18 08:41:39 1998 From: CurtA at worldnet.att.net (Curt Arnold) Date: Mon Jun 7 17:02:56 2004 Subject: Javadoc comments or equivalent in XSchema Message-ID: <000101bdb217$3162ea80$6bf7490c@curtathome> I posted some observations from my use of XML-Data to define fairly large grammers to microsoft.public.xml a few days ago. I have just become aware of XScheme from the recent announcement here and since it doesn't express inheritance, 2 out of the 3 suggestions don't apply (allowing element types that exist only for inheritance to be defined as pure virtual (that is not to be used in file definition or show up in editors) and allowing to define a group as all elements that inherit from an particular superclass). I think the remaining one might be useful (or possibly already discussed here). I have been using some JavaDoc-like comments in my XML-Data definitions to automatically generate HTML documentation for the document content. I have had my XML-Data to DTD converter modified to produce the HTML documentation at the same time as it builds the DTD. I haven't been making a distinction between regular comments and processed comments and have only been using @see and @example formulations. Between minimal comments and information in the schema, it is able to do a reasonably good job documenting how to use the schema. Has any body else been doing anything in this area? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Jul 18 09:55:45 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:56 2004 Subject: Javadoc comments or equivalent in XSchema In-Reply-To: <000101bdb217$3162ea80$6bf7490c@curtathome> Message-ID: <3.0.1.16.19980718083115.2d27c740@pop3.demon.co.uk> At 01:42 18/07/98 -0500, Curt Arnold wrote: >I posted some observations from my use of XML-Data to define fairly large >grammers to microsoft.public.xml a few days ago. I have just become aware >of XScheme from the recent announcement here and since it doesn't express >inheritance, 2 out of the 3 suggestions don't apply (allowing element types >that exist only for inheritance to be defined as pure virtual (that is not >to be used in file definition or show up in editors) and allowing to define >a group as all elements that inherit from an particular superclass). > I think the idea of 'inheritance' in documents is substantially different from that in software. There are already ideas of 'inheritance' or scoping in the xml:lang attribute and also in attributes in XLink. This is very intimately connected with namespaces and I'd wait for the next draft of that before doing too much in this area. [By all means go ahead and experiment, but be warned that this is a tough area!] P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Jul 18 09:55:48 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:56 2004 Subject: XSchema evaluation period - upcoming In-Reply-To: Message-ID: <3.0.1.16.19980718083638.2a577c80@pop3.demon.co.uk> At 01:50 18/07/98 UT, Simon St.Laurent wrote: > >There have been good ideas about inheritance and other potentially exciting >stuff coming in. I'd like to hammer out 1.0, but be ready for 1.1 and 2.0! >(If the W3C doesn't scoop this up before we get there, of course.) Inheritance is very closely bound up with namespaces. Until those are settled I'd advise waiting before doing anything here. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sat Jul 18 15:31:54 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:57 2004 Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 5 Message-ID: Here's draft 5 of Element Declarations. This was mostly minor cleanup, to make sure XSchema authors know that element names need to conform to the Name production, not merely the NMTOKEN production. Attribute names received an initial cap to conform to the results of the earlier balloting and be consistent with the rest of the spec. (id is a notable exception throughout the spec.) As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.2 Element Declarations Element declarations in XSchemas are made using the XSC:ElementDecl element and its contents: The XSC:Name attribute identifies the name of the element, and is required. An element declaration would look like: ...additionalElementInformation... This declaration would declare an element named "Species", which would appear in an instance as: ...content... The XSC:Name attribute must be unique within the set of elements, as it provides the name of the element as declared here, and is also used by other elements to refer to this element in their content model declarations. The XSC:Name attribute must also match the Name production in the XML 1.0 spec. (Effectively, this requires element names to begin with a letter, underscore, or colon.) The XSC:id attribute, if it appears, must be unique within the document. This attribute may be used to uniquely identify this XSC:ElementDecl element for reference using XPointers and other tools. The XSC:Root attribute provides authoring tools with a guide for which elements are likely root elements for documents. This is intended to simplify the choices presented to authors during document composition. Composition tools could use this to build a menu of likely starting points for a document. Note that an element must declare a content model of some type, even if that content model is empty. Documentation (in the XSC:Doc element), non-XSchema extensions (in the XSC:More element) and attribute declarations (using XSC:AttDef elements) are optional. Documentation about the element, additional extensions, 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. Additional extensions are covered in 2.6.2, Further Extensions. Content Models are covered in 2.3, Content Model Declarations, and attributes are covered in 2.4, Attribute Declarations. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sat Jul 18 15:33:34 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:57 2004 Subject: XSchema Spec - Content Model Declarations (Section 2.3), Draft 5 Message-ID: This section has received much rougher treatment. A paragraph at the top explains the mostly undetermined issues of putting content model declarations inside XSC:XSchema elements. All elements now have (optional) id attributes for easy reference. I also cleaned out a lot of odd conditional language. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.3 Content Model Declarations Content model declarations are made within the declaration for the element to which they apply. Reference, Mixed, Choice, and Sequence models may appear inside XSchema elements for reusability, documentation, and reference, but will need to be linked to particular element declarations through mechanisms not yet defined (most likely XLink). All content model declarations have an optional id value for reference. 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. For example, to declare the Species element shown in the previous section empty, use the following XSchema declaration: This would not allow the Species element to contain any text or sub-elements. 2.3.2 Any Content Model The Any content model, which allows the element to contain parsed character data or any other elements as content, is equally simple: Using the Any content model is much like using the Empty content model. To declare that the Species element had a content model of any, use the following declaration: This allows the Species element to contain text and any sub-elements an author desired. 2.3.3 PCData Content Model The PCData content model, which allows the element to contain only parsed character data, is also represented by a single empty element. Using the PCData content model is much like using the Empty and Any content models. For example, to assign the Species element a content model of PCData, use the following declaration: This allows the Species element to contain text, but no sub-elements. 2.3.5 Reference Content Model The Reference content model allows an element to specify other elements which it may contain, as well as their quantity. XSC:Ref elements identify the element to be contained, as well as the frequency with which it must appear: The Element attribute must refer to the Name attribute of an XSC:ElementDecl element elsewhere in the XSchema document. An XSC:ElementDecl element may contain at most one XSC:Ref element. The Frequency attribute controls the number of referenced elements that may occur. To define content models that permit or require the use of more elements, the Any, Mixed, Choice, or Sequence content models should be used as appropriate. To declare that the Species element may contain a single CommonName element, and nothing else, use the following declaration: This requires the Species element to contain a single CommonName element. To make the CommonName element optional - though it may still only appear once, set the Frequency attribute to 'Optional': Optional is the equivalent of the ? occurrence indicator in XML 1.0 DTDs. To require the Species element to contain at least one but possibly multiple CommonName elements, set the Frequency attribute to 'OneOrMore': OneOrMore is the equivalent of the + occurrence indicator in XML 1.0 DTDs. Finally, to allow the Species element to contain any number (including zero) of CommonName elements, set the Frequency attribute to 'ZeroOrMore': ZeroOrMore is the equivalent of the * occurrence indicator in XML 1.0 DTDs. 2.3.6 Mixed Content Model Mixed content model allows the unordered use of different element types and character data. Content within an element that uses a mixed declaration must be PCData or one or more of the elements referenced by XSC:Ref elements nested within the XSC:Mixed declaration. Only XSC:Ref elements can be nested under an XSC:Mixed element; the PCData content is inherent in the Mixed content model. To declare that the Species element may contain a mix of PCData, CommonName elements, LatinName elements, and PreferredFood elements in any order, use the following declaration: The XSchema processor should ignore any frequency attributes in XSC:Ref elements that appear as subelements of the XSC:Mixed element. 2.3.7 Choice Content Model The Choice content model allows for either-or inclusions of elements and groups of elements. The Choice content model represents groups of element content possibilities and must contain at least two sub-elements. Situations where only one element is needed should use the Ref content model instead of Choice. The XSC:Choice element may 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. The simplest XSC:Choice element will contain two Ref elements and a frequency attribute. By default, the XSC:Choice element's content model is required to appear once. To declare that a Species element may contain either a common name or a Latin name, but not both, use the following declaration: The 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 sub-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. 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. The simplest XSC:Seq element will contain two Ref elements in the order in which they should appear and a frequency attribute. By default, the XSC:Seq element's content model is required to appear once. To declare that the Species element requires a common name and a Latin name, in that order, use the following declaration: The 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 SimonStL at classic.msn.com Sat Jul 18 15:34:56 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:57 2004 Subject: XSchema Spec - XSchema Element (Sections 2.0 and 2.1), Draft 5 Message-ID: Here is Draft 5 of the XSchema Element section. I'm hoping that this is close to final and may be used shortly as part of the complete section 2 for review. I made XSC:Namespace optional (minor glitch), added a lot of possible sub-elements to XSC:XSchema as requested by a number of writers on this list, and added a bit more explanation of why nesting XSchemas might be a good idea. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.0 XSchema Syntax This section describes the XSchema document syntax. The XSchema document is an XML document containing a single XSchema element in which information describing the schema is nested. The XSchema element must be preceded by an XML declaration and may be preceded by other declarations, comments, and processing instructions. 2.1 The XSchema Element The XSchema element is the root element for all XSchema documents. The declaration for the XSchema element is: The 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. This nesting of XSC:XSchema elements improves reusability of XSchemas by allowing the combination of multiple XSchemas inside of a single XSchema framework. It also allows finer-grained control over documentation for subsections of an XSchema. The XSC:XSchema element's attributes include information about the version of the XSchema specification used as well as information about the type of documents described by the XSchema. Information about the XSchema specification version used to create this XSchema, 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 the XSchema specification should identify themselves differently. No provision is made at this time for nesting XSchemas using different versions of the specification under a parent XSchema element. The 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. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Sat Jul 18 16:15:56 1998 From: jtauber at jtauber.com (James K. Tauber) Date: Mon Jun 7 17:02:57 2004 Subject: EDI In-Reply-To: Message-ID: <002801bdb256$8b862d80$de6118cb@caleb> > Xml-dev listeners: > I was reading the July 13th issue of Network World and > ran across an XML article on page 6 regarding a software product that will > bridge the gap between EDI and XML. In this article, it suggests > that XML was "concocted somewhat as a replacement for EDI." Is this true? XML certainly wasn't "concocted" as a replacement for EDI, but it can be used for EDI. There is a lot of work being done on X12 and EDIFACT in XML (along with a number of heated discussions on whether using XML syntax gives any benefits over X12). XML has its origins as as a means for using SGML (and hence structured documents) on the Web. It has a range of uses, but structured documents on the Web was the original goal. James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sat Jul 18 17:12:19 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:57 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 5 Message-ID: Here's the latest version of Attribute declarations. The largest addition is section 2.4.3, which focuses on the new oddities of XSchema->DTD conversion brought on by the shift from child elements to attributes for declaring type and default value. Equally important is the new language about the Element attribute of the AttDef element, built on suggestions from Ron Bourret and John Cowan. I'm not sure if allowing these to apply to all elements is a good idea, or if they should simply be ignored. If ignored is the choice, the last sentence of this paragraph will be easier to fix than going the other way: --------------------------------------------------------- In XSchema 1.0, an attribute declaration (XSC:AttDef element) may be nested within the element declaration (XSC:ElementDecl element) for the element to which the attribute belongs. If the XSC:AttDef element appears nested inside an XSC:ElementDecl element, the Element attribute must be ignored. If the XSC:AttDef element appears nested under the XSC:XSchema element, the Element attribute may contain a name token corresponding to the Name attribute of the element to which this attribute applies. If the Element attribute is missing, that XSC:AttDef declaration applies to all elements within the declaration's parent XSC:XSchema element and any child XSC:XSchema elements. ---------------------------------------------------------- As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.4 Attribute Declarations 2.4.1 Overview Attribute declarations are made with empty XSC:AttDef elements. XSC:AttDef elements may be nested inside of XSC:ElementDecl element declarations or linked to element. The type of an attribute is defined with an attribute, as is a declaration of whether or not it is required and a possible default value. In XSchema 1.0, an attribute declaration (XSC:AttDef element) may be nested within the element declaration (XSC:ElementDecl element) for the element to which the attribute belongs. If the XSC:AttDef element appears nested inside an XSC:ElementDecl element, the Element attribute must be ignored. If the XSC:AttDef element appears nested under the XSC:XSchema element, the Element attribute may contain a name token corresponding to the Name attribute of the element to which this attribute applies. If the Element attribute is missing, that XSC:AttDef declaration applies to all elements within the declaration's parent XSC:XSchema element and any child XSC:XSchema elements. The Name attribute of the XSC:AttDef element provides the name by which the attribute will be identified. A nested declaration is shown below. ...additionalElementInformation... This declares an element with the name Species that has an attribute named status. If the status attribute was declared outside of the Species element declaration, the declarations would appear as shown below. ...additionalElementInformation... ... Merely naming an attribute may be adequate. Attribute declarations may identify types and provide information about whether the attribute is required. By default, attributes will be assumed to contain character data (CData), not be required, and have no default value. This information is declared using additional attributes. The simplest attribute declaration possible identifies an attribute as containing character data (CData) and allows the attribute to be optional, as shown below. Applications may also use the id attribute to provide unique identifiers for attribute declarations using values that are unique within the XSchema. 2.4.2 Attribute Types XSchema 1.0 provides equivalents for all of the XML 1.0 DTD attribute types. All of them are declared using attribute values within the XSC:AttDef element. The CData attribute type is one of the most common, permitting an attribute to contain character data as defined by the XML 1.0 specification. If the Species element were to contain an attribute providing the Latin name of the species, the declaration could look like the following. (The Type attribute could actually be omitted in this case, as CData is the default type.) ...additionalElementInformation... This attribute would then be available for use in instances of the Species element: ...additionalContent... The ID attribute type is used to uniquely identify elements in a document for application processing. IDRef and IDRefs attribute types are used to refer to a single ID value in the same document or multiple ID values in the same document, separated by whitespace, respectively. These attribute declarations must be used with the same constraints as apply to ID, IDREF, and IDREFS attribute types in XML 1.0. The Entity and Entities attribute types identify the names of unparsed entities. The use of these attribute types must be made with the same constraints as apply to the ENTITY and ENTITIES attribute types in XML 1.0. If a document is checked directly against an XSchema without a conversion to a DTD, information regarding unparsed entities must be available from the parser for these attribute types to be meaningful. The Nmtoken and Nmtokens attribute types are used to declare attributes that must contain information conforming to the Nmtoken and Nmtokens productions in XML 1.0. The Notation and Enumerated attribute types are more complex, requiring an Enumeration attribute to identify their possible content. These two declarations use similar syntax, but the allowed values of Notation declarations must match the Notations declared elsewhere in the XSchema document. If the status attribute of the Species element were to allow the values of extinct, endangered, protected, and non-threatened, an appropriate enumerated type declaration would look like: ...additionalElementInformation... A Species element created conforming to this declaration might look like: ...additionalContentAboutDodos... 2.4.3 Attribute Defaults XSchema requires attribute declarations to provide information about the default value of a given attribute. XSchema provides for the four cases supported by XML 1.0: #REQUIRED, #IMPLIED, #FIXED AttValue, and AttValue, though they are expressed as choices between required and not required and fixed or not fixed, with an optional default value. There may be only one default value declaration per attribute. Required attributes (identified in XML 1.0 by #REQUIRED) are identified by assigning the value "Yes" to the Required attribute of an XSC:AttDef element. For instance, if the Latin attribute described above was required by the Species element, the XSC:AttDef element would contain a Required attribute with a value of "Yes": ...additionalElementInformation... Optional attributes (identified in XML 1.0 by #IMPLIED) are identified assigning the value "No" to the Required attribute of an XSC:AttDef element and not assigning a value to the AttValue attribute. Implied indicates that there is no default value provided, and also that no value is required. If the Latin attribute is optional, the XSC:AttDef element would contain a "No" value for the Required attribute. (Note that this is the default status and the Required declaration does not need to be made explicitly.) ...additionalElementInformation... Fixed attributes (identified in XML 1.0 by #FIXED AttValue) are identified through the use of the Fixed attribute in combination with the AttValue attribute, which must contain the fixed value for the attribute. Attributes declared using fixed value cannot declare a different value for that attribute. Fixed effectively hard codes attribute values into particular elements. If the Fixed attribute has a value of "Yes", the AttValue attribute must be present. A Fixed value without an AttValue must be treated as an error. For example, to declare a planet attribute for the Species element, a Fixed attribute given the value of "Yes" would identify the fixed nature of the attribute and the AttValue attribute would provide the value. ...additionalElementInformation... Attributes may also be provided with a default value that may be overridden by other declarations. These default values are identified through the use of the AttValue attribute. The status attribute of species elements described above would be an appropriate target for such a default value, especially if most species being described fell into a particular category: ...additionalElementInformation... Any default (required, fixed, etc.) may be used with any attribute type, though default values should always correspond to acceptable values for the attribute type. 2.4.4 Combinations of Types, Defaults, and Default Values This notation also permits the declaration of certain attributes (IDs with defaults, for instance) that are prohibited by the standard XML 1.0 DTD syntax. Developers who use these combinations should test that their documents will behave as expected in DTD-only environments as well as XSchema environments. Additional processing of document instances may be necessary to produce normalized-for-DTD use documents if they included such attributes as default values. The attribute type should always be considered more important than its default values in XSchema to DTD conversion. The table below summarizes the possible combinations of XSchema attribute defaults and their XML 1.0 DTD equivalents. Required Fixed AttValue XML 1.0 Value Yes Yes This does not occur in XML. It means that the instance file must include the value and the value must be the fixed value. At best this enforces duplication. Yes Yes -- error - Fixed=Yes without a value is clearly an error. Yes No This does not occur in XML. It means that the instance file must include a value and the default happens to be whatever is given with AttValue. This should be treated as simply AttValue for maximum compatibility. Yes No -- #REQUIRED No Yes #FIXED No Yes -- error - Fixed=Yes without a value is clearly an error. No No AttValue No No -- #IMPLIED xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sat Jul 18 17:13:05 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:57 2004 Subject: XSchema Specification - Notations (Section 2.5), Draft 4 Message-ID: Here's the latest on section 2.5. Tiny grammatical nits and capitalization have been fixed; nothing substantive. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.5 Notation Declarations Notation declarations are made with XSC:Notation elements nested in the XSC:XSchema element. Notations may include a public identifier or a system literal, or both. XSchema processors should ignore XSC:Notation elements that contain neither. Public identifiers and system literals should conform to the rules in Section 4.7 of the XML 1.0 Specification. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sat Jul 18 17:25:57 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:02:57 2004 Subject: XSchema Specification - Extensions (Section 2.6), Draft 3 Message-ID: This is a minor revision of the extensions section, stripping out FONT and clarifying how XSC: elements might creep into the documentation. A bigger documentation issue remains - Chris Maden wrote: >For XSchema I would suggest, as another poster did, that some element >types specific to the subject at hand might be useful, such as >, , and . I don't think these need to go into IBTWSH - we can provide for them here. But what (if anything) would people like for this? As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.6 XSchema Extensions XSchema provides areas in which XSchema developers can provide supplemental information and metadata regarding XSchema components in both human- and machine-readable formats. Human-readable information is provided through the use of a subset of HTML that conforms to XML syntax, while machine-readable information may be provided through the XSC:More element. 2.6.1 Documentation Extensions Human-readable documentation for XSchemas should be provided using the Itsy Bitsy Teeny Weeny Simple Hypertext (IBTWSH) format created by John Cowan. The full DTD is available at http://www.ccil.org/~cowan/XML/ibtwsh.dtd. Documentation that uses portions of the IBTWSH format may be included in the XSC:Doc element, a subelement available to all declarations. The XSC:Doc element provides basic formatting options for XSchema documentation. %ibtwsh; Any element allowed in the horiz.model set of elements (A, BR, SPAN, XML, CITE, CODE, DFN, EM, KBD, SAMP, STRONG, VAR, or parsed character data) may be used in the XSC:Doc element. Note that IBTWSH does not use namespaces in order to preserve compatibility with HTML. XSchema applications should ignore all XSchema declarations (i.e., elements prefixed with XSC: or the appropriate XSchema prefix) within an XSC:Doc element. (The XML element of IBTWSH allows an ANY content model.) 2.6.2 Other Extensions The XSC:More element provides an area which developers can use to create their own supplements to XSchema, defining content types more tightly than is possible through XSchema 1.0. The XSC: More element has a simple ANY content model, though XSchema processors should ignore the appearance of any elements from the XSchema namespace in this area. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From carl at chage.com Sat Jul 18 23:33:47 1998 From: carl at chage.com (Carl Hage) Date: Mon Jun 7 17:02:57 2004 Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 5 In-Reply-To: Message-ID: <199807182133.QAA23870@rgate2.ricochet.net> > Date: Sat, 18 Jul 98 12:55:18 UT > From: "Simon St.Laurent" > Root (Recommended | Possible | Unlikely) "Possible"> > The XSC:Name attribute must be unique within the set of elements, Do you mean unique within the set of ElementDecls? (I suggest rewording since element is ambiguous.) > The XSC:Root attribute provides authoring tools with a guide for which > elements are likely root elements for documents. The semantics of the enumerated values is undefined. (A 1 word definition is not suitable for a standard.) Clearly you have some specific ideas in mind. There must be an unambiguous definition of the semantics, so developers who create tools have a predictable behavior, and authors have guidelines as to which choice is appropriate. Otherwise the attribute should be removed. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From carl at chage.com Sat Jul 18 23:36:01 1998 From: carl at chage.com (Carl Hage) Date: Mon Jun 7 17:02:58 2004 Subject: EDI Message-ID: <199807182134.QAA07498@rgate.ricochet.net> > From: chris m hinds > ...In this article, it suggests that XML was > "concocted somewhat as a replacement for EDI." Is this true? [Oops. Sorry, this email ended up being a long manifesto. Note- there's some comments below related specifically to what's important about XML and what's needed in XSC.] The act of exchanging XML files is EDI by definition, according to the original grandiose acronym and project definition. EDI is essentially thing to solve the identical problem as XML, though the focus is business transactions. Put some people use the horrid X12 format to try and exchange documents, i.e. what SGML tries to do. What is typically meant by "EDI" is the X12/EDIFACT set of "standards" and proprietary networks used to transmit these protocols. (EDIFACT is the internationalized version of X12). X12 has 2 parts: 1. A record formatting standard 2. Definitions for data elements, i.e. a DTD of sorts In my opinion X12 has severe problems that have limited it's usefulness to only a small number of large corporations (or small companies trying to do business with a giant). One problem is the record formatting structure-- a punch-card era structure that is unimaginable to a modern C/Java programmer. Instead of simple parsers, $2-10K software packages are required. It's based on fixed length fields, and fixed nesting structures-- completely the opposite of xml. Normally, companies need to hire EDI consultants to help untangle the mess. XML can be used as a record format to escape from the limitations and complexity of the X12 method of packaging data elements. It's not difficult to convert a parsed X12 message into xml. However, it's very useful to untangle the X12 structure. For example, instead of one data element like, , X12 might use 2-5 elements-- extra elements are used for qualifiers, if the fixed lengths are exceeded, or for repeated values. A good X12-XML translator would do more that a simplistic mapping of raw X12 elements. The other problem with X12 is that the equivalent of the DTD isn't really a "standard", it's more like a vague suggestion. Potentially XML/SGML could have the same problem if one writes a DTD without documentation. Each company interpret's the specification in thier own way. Instead of having a paragraph to precisely define the semantics and syntax, there's typically a few words. The result is that to implement EDI, you typically hire an EDI consultant who uses specialized data conversion software to translate the formatting conventions used by each trading partner into a useful form. In other words, instead of having everyone exchange data formatted according to a precisely defined standard, you write a translator for each trading partner. Thus the setup time for adding a new customer/vendor is measured in months-- almost useless for internet commerce. I think XML and in particular XSC can potentially solve this problem. I've been overloaded and haven't had time to comment, before, but I'd like to offer some suggestions that I think are important. There seems to be lots of hype on data formatting, as if the main problem to be solved is parsing records into data elements. From my experience in exchanging data, a competent perl hacker can easily encode or decode most record formats. The top 2 problems are: 1. The fields (elements) are undefined or vague. 2. The code values for enumerated types are inaccessable and/or undocumented. I routinely deal with databases where the maintainers of the data have no idea what certain fields mean. The usual way to find definitions is to look at data values and figure out how it's used. The other big problem is that in many cases the enumerated types are undefined. There may be a vague reference, or sometimes you need to order an expensive paper document from Switzerland. XML has a serious problem (inherited from SGML) in that the DTD has syntax only, and does not have a means (other than little used comments) to define semantics. Dealing with the syntax of data records is insignificant and trivial in comparison to dealing with the semantics. The most important part of XSC is the ability to add the documentation sections to the DTD elements. The biggest need is simple access to precise definitions of data elements. That's something that XSC can do that cannot be done with SGML. I will make some suggestions for the XSC spec in this area in other emails. Another crucial part is the ability to make external references to code values and thier documentation. Very often element values reference a separate standard or some implied standard, and are otherwise undocumented. For example, the Spatial Data Transfer Standard is broken. The coordinate coding system is defined using an enumerated value, and in the case of state-plane, it references a paper-based NIST standard which has been withdrawn, with the mailing address of NIST given as the reference. I'm sure there are data files floating around somewhere on the net, but it's very difficult to find. If there were an XSC for STDS, it's crucial that enumerated external types reference network accessable definitions. Take "city, state, zip" (zip=US postal code). It's easy to find a list of states, and if there were an external XML reference, then a general purpose XML parser/checker could validate a element. However, the USGS, Census, USPS, and NIST databases of city names all disagree slightly. The NIST database is the best one, and I sent back a page full of errors just for the city names in California. USPS changes zip codes regularly, without publically accessable definitions. (They sell copyrighted databases to junk mailers. You download more data in graphics off thier website to find out you need to buy a lesser amount of data which you may not be able to make public.) Zip changes of course, invalidate Census, USGS, and NIST databases, as well as lots of others that reference city or zip codes. With the contents of distributed databases linked by the net, it's crucial to link definitions and documentation. XSC provides that. One interesting aspect is that X12 is designed for mainframe-mainframe communication only, i.e. the message formats are undecodable except by experts (looks just like modem noise.) However, most messages are either prepared and/or processed manually, e.g. an EDI translator is used just to format a message or print a message. Under the EDI model there is no possibility of human-machine interaction-- you either fax paper documents and retype or use fully automated coded messaging. There's no concept like an ordinary email message that's both human and machine readable. The X12 structure was developed for use with networks which charged by the KB, e.g. a company might pay $12K/yr for less data than $6/mo email service. Though xml or a pretty-printed format (e.g. like RFC822 headers) is larger than X12 coding, when xml is compressed with gzip, it's probably smaller. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sun Jul 19 01:58:50 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:02:58 2004 Subject: XSchema Spec - Element Declarations (Section 2.2), Draft 5 In-Reply-To: <199807182133.QAA23870@rgate2.ricochet.net> References: Message-ID: <3.0.1.16.19980719005905.2c8f23d6@pop3.demon.co.uk> At 13:54 18/07/98 -0800, Carl Hage wrote: > >> The XSC:Root attribute provides authoring tools with a guide for which >> elements are likely root elements for documents. > >The semantics of the enumerated values is undefined. (A 1 word definition is >not suitable for a standard.) Clearly you have some specific ideas in mind. >There must be an unambiguous definition of the semantics, so developers who >create tools have a predictable behavior, and authors have guidelines as to >which choice is appropriate. Otherwise the attribute should be removed. Thanks Carl, I think we would be flattered to think that XSchema was a 'standard' :-). I appreciate the emphasis on documenting semantics (and behavior). This is an area where I have often suggested that we need more help from the XML specs. However in this case I suspect there is no behavior involved with this attribute - it's merely a guide as to whether an author would be advised to use a particular element as a Root. In many domains this will come down to ontological perceptions - for example, I would hesitate to recommend that authors of CML documents should take *my* choices of Root as the field is so new. In this case I suspect it is a rather fuzzy guide to newcomers saying - "Suggest you start here" or "suggest you don't". I suppose it is conceivable that a machine could provide useful navigation of the XSchema starting at "recommended" and not starting at "unlikely". P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Sun Jul 19 03:46:01 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:02:58 2004 Subject: Javadoc comments or equivalent in XSchema In-Reply-To: <3.0.1.16.19980718083115.2d27c740@pop3.demon.co.uk> from "Peter Murray-Rust" at Jul 18, 98 08:31:15 am Message-ID: <199807180137.VAA04876@locke.ccil.org> Peter Murray-Rust scripsit: > I think the idea of 'inheritance' in documents is substantially different > from that in software. There are already ideas of 'inheritance' or scoping > in the xml:lang attribute and also in attributes in XLink. This is very > intimately connected with namespaces and I'd wait for the next draft of > that before doing too much in this area. [By all means go ahead and > experiment, but be warned that this is a tough area!] XML-Data inheritance is different from the sense of "inheritance" in "inherited attributes". An element A inherits from another element B iff: 1) it is said to do so; 2) every attribute in B exists also in A, and with a compatible attribute type; 3) the required content of B is a subset of the required content of A. -- 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 Sun Jul 19 12:12:08 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:58 2004 Subject: Javadoc comments or equivalent in XSchema Message-ID: <199807190958.LAA25515@berlin.dvs1.tu-darmstadt.de> > I think the remaining one might be useful (or possibly already discussed > here). I have been using some JavaDoc-like comments in my XML-Data > definitions to automatically generate HTML documentation for the document > content. I have had my XML-Data to DTD converter modified to produce the > HTML documentation at the same time as it builds the DTD. > > I haven't been making a distinction between regular comments and processed > comments and have only been using @see and @example formulations. Between > minimal comments and information in the schema, it is able to do a > reasonably good job documenting how to use the schema. > > Has any body else been doing anything in this area? XSchema does something similar. Most elements contain an optional Doc element which, in turn, contains a subset of HTML: John Cowan's Itsy Bitsy Teeny Weeny Simple Hypertext (IBTWSH) format ( http://www.ccil.org/~cowan/XML/ibtwsh.dtd ) See section 2.6.1 of the spec (http://members.aol.com/simonstl/xschema/spec/xscspec2p6v3.htm) -- 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 carl at chage.com Sun Jul 19 21:05:43 1998 From: carl at chage.com (Carl Hage) Date: Mon Jun 7 17:02:58 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 5 In-Reply-To: Message-ID: <199807191906.OAA13734@rgate2.ricochet.net> > Date: Sat, 18 Jul 98 15:02:57 UT > From: "Simon St.Laurent" > Name NMTOKEN #REQUIRED > Element NMTOKEN #IMPLIED > id ID #IMPLIED > Type (CData | > ID | > IDRef | > IDRefs | > Entity | > Entities | > Nmtoken | > Nmtokens | > Notation | > Enumerated) "CData" > Required (Yes | No) "No" > Fixed (Yes | No) "No" > Enumeration NMTOKENS #IMPLIED > AttValue CDATA #IMPLIED> Moving the multiple element choice into the Type attribute was a big improvement. Without this, any software processing the AttDef would have to scan all the elements and rederive an enum type. It's a real pain to model "What is the type of the attribute" as the existence of one of a set of attributes, and wouldn't fit how the attribute would be extended. However, moving + into a token string creates a severe problem. It's impossible to add information associated with each code value, for example documentation on the semantics for each. Also, it may be common to import enumeration values defined within an external standard, e.g. by using xml links. To correct the problem, simply add back in, e.g. Though it's not as important for AttValue to be an element, I think for improved extensibility and the ability to attach documentation, should be restored, with Doc? added, e.g. It would also be better to rename this, say to: which has the possiblility of analogous use in specifying element values. (XML data has a nice feature in using common parts to describe values for attributes and elements.) It may be important to associate other information (including xml links) with the NMTOKEN used for the DefaultValue. You are almost hosed (need to pervert extentions to the AttDef) if the value is not supplied in a separate element. What happened to NotationValue? Since it's a reference within the document, it's not necessary to add documentation, but it seems better to represent a list as elements rather than space separated names in a string. You should probably use: for I believe, the IDREF must match an ID attribute and be unique across the ID attributes in all elements in the document. That means this is not the notation Name, which isn't ID. Tbus it probably should be a NMTOKEN. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Jul 20 09:39:21 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:02:58 2004 Subject: Last day to submit XML DevCon proposals Message-ID: Please note >>>>> Reply-to: bosak@eng.sun.com Subject: Last day to submit XML DevCon proposals Executive summary: If you are working on anything to do with XML, XLL, XSL, or DSSSL, here's your opportunity to share the technical details with an audience that will understand what you're up to. For further information, see http://www.lists.ic.ac.uk/hypermail/xml-dev/9807/0105.html Today was last day to send me a proposal by the official deadline. I meant to send this reminder yesterday, but somewhere in the process of changing my xml-dev subscription to the digest form, I've lost the ability to post to the list and am asking Henry Rzepa to do it for me. Given that this reminder is a day late, I will extend the deadline a day if you send me email indicating your interest in submitting a proposal. Jon 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 h.rzepa at ic.ac.uk Mon Jul 20 09:49:39 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:02:58 2004 Subject: No subject Message-ID: CALL FOR PRESENTATIONS: XML DEVELOPERS' CONFERENCE 1998.08.20-21 A two-day technical conference for XML, XSL, and XLL developers will be held Thursday and Friday, August 20 and 21, in Montreal, Canada. Cosponsored by the Graphic Communications Association (GCA) and the Organization for the Advancement of Structured Information Standards (OASIS), the Developers' Conference will immediately follow the GCA Metastructures 1998 Conference in the same location, Le Centre Sheraton in Montreal. See http://www.gca.org/conf/meta98/ for registration and other conference details. The XML Developers' Conference extends the highly successful series of "XML Developers' Days" that began in Montreal last year in conjunction with the GCA HyTime Conference and was repeated in Seattle this March in conjunction with the GCA XML Conference. In response to the overwhelming number of submissions at the March event and the requests of previous attendees, the conference has been expanded from one day to two to allow for more presentations, and the time allotted for each speaker has been extended from 30 minutes to 45 minutes to allow for more questions. Like the previous events, however, this UnConference(tm) resists the bigger-is-better trend of recent years and maintains the concept of a single-track event featuring just the very best presentations from the cream of XML geekdom. In other words, this is a conference by developers, for developers. Expect really interesting presentations on fairly deep subjects in a locale noted for its French-Canadian culture, great food, and low prices. If you come wearing a suit we won't actually turn you away, but we don't need your business so badly that we're willing to lower the level of discourse. CALL FOR PRESENTATIONS If you are engaged in the construction of any software that works with XML -- converters, parsers, servers, browsers, editors, or XML-based vertical applications -- here is your chance to share your work with an audience that can understand and appreciate it. Since hypertext linking and stylesheet-based rendering are part of the larger XML picture, developers of tools that support XLL, XSL, or DSSSL are invited to show their latest offerings as well. While not primarily oriented toward industry-specific XML-based markup languages (CML, OFX, etc.), the conference is open to a certain number of presentations on specific languages and applications whose features are of special interest to developers and on related efforts such as RDF and XML-Data that may have a significant impact on the future of XML. Vendors of commercial tools can participate, but the presentations must be confined to the technical aspects of X*L products currently in development. Table space will be made available for the distribution of product announcements and commercial literature. Note that presenters get into the conference free. RULES FOR SUBMISSIONS No formal papers in advance at the UnConference(tm)! As in the previous two events, we want the very latest reports on work in progress. So instead of asking months ahead of time for stale papers submitted in someone's word processing format, we're asking right now -- a mere six weeks before the conference -- for just a few long paragraphs (300-500 words) submitted electronically in primitive HTML (version 2.0 or earlier). You have a little less than a fortnight to get your submission in; all proposals for presentations MUST be received by midnight on Sunday, July 19, 1998. It's OK if some details of your project are still not firm, but you must be careful to indicate those areas in your submission along with their current status and your expectations for their status at the time of the conference. Remember, this is for software developers; just observe the same general rules that you would follow in annotating code in progress. The important thing is that you give enough information for us to decide which presentations to include and to tell other attendees what to expect. The requirement that you submit the description of your presentation in HTML is so that it can go directly on the conference web page as soon as the schedule has been determined. The requirement for primitive HTML is so that your submission can be read without mechanical intervention and also so that it can be read from the conference web site by blind people. Submissions in some godawful generated HTML format with gratuitous tables, one-pixel GIFs, or embedded nbsp's will either be summarily thrown out or thought very badly of, depending on the mood of the reviewer. Since the conference program will be formed simply by concatenating the accepted proposals and putting the file up on the web, please write your submission in a way that will work in that context. Veiled threats, offers of cash, and other language attempting to influence the selection process should be put in a separate cover note rather than in the description of your proposed presentation. RULES FOR PRESENTATIONS Bowing to vociferous demands from previous audiences, we are adding an additional requirement this time that the presentations themselves be given in some kind of format less ephemeral than handwritten notes clutched in one's sweaty palm. While appropriately geeky, this medium is less than satisfactory in answering requests for copies. Please be prepared in the event that your submission is accepted to come to the conference with something that can be displayed on a screen and distributed electronically afterward. Any reasonably common format from ASCII on up to XML with an XSL stylesheet (or sideways to PowerPoint or PDF) is acceptable as long as it can be made available right after the conference in a form that can be downloaded from the conference web site. Note that the presentation itself is not due until the moment that you deliver it. SUBMITTING PROPOSALS Send all submissions by July 19 at midnight California time to Jon Bosak (bosak@eng.sun.com). Please allow a couple of days for acknowledgement of your submission before asking what happened to it. Sending your submission in much before the deadline won't really help your chances, so take the time to write the clearest description that you can. The conference schedule will be announced Monday, July 27. ====================================================================== Jon Bosak, Online Information Technology Architect, Sun Microsystems 901 San Antonio Road, MPK17-101, Palo Alto, California 94043 If a man look sharply and attentively, he shall see Fortune; for though she be blind, yet she is not invisible. -- Francis Bacon 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 david at megginson.com Mon Jul 20 13:36:50 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:02:58 2004 Subject: [Q] How should SAX support Namespaces? Message-ID: <199807201132.HAA00572@unready.megginson.com> How should SAX support namespaces? I can think of three options: 1. Simply ignore them, and require the XML application to do the work (all of the necessary information is passed on by SAX). 2. Use the current interface, but allow namespace-aware SAX processors to prepend namespace URIs to element type and attribute names, as in startElement("urn:www.megginson.com:doc", ...) endElement("urn:www.megginson.com:doc", ...) 3. Revised org.xml.sax.AttributeList and org.xml.sax.DocumentHandler to include the namespace as a separate (possibly-null) argument: startElement("urn:www.megginson.com", "doc", ...) endElement("urn:www.megginson.com", "doc", ...) Given that many major XML-based standards (RDF, XSL, etc.) plan to use namespaces, it probably doesn't make sense to offload the work to the application as implied by #1, so the best choices would be #2 or #3. I would be very interested in hearing opinions, especially (but not exclusively) from people who have implemented SAX on either the parser or the application side. 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 M.H.Kay at eng.icl.co.uk Mon Jul 20 14:13:17 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:02:58 2004 Subject: [Q] How should SAX support Namespaces? Message-ID: <007101bdb3d8$1dd443c0$1e09e391@mhklaptop.bra01.icl.co.uk> -----Original Message----- From: David Megginson To: XML Developers' List Date: 20 July 1998 12:38 Subject: [Q] How should SAX support Namespaces? >How should SAX support namespaces? I can think of three options: >3. Revised org.xml.sax.AttributeList and org.xml.sax.DocumentHandler > to include the namespace as a separate (possibly-null) argument: > My vote is definitely for (3), though (1) needs to be an option for compatibility. But rather than pass through the URN of the namespace in each call, I would pass an integer identifying it within the set of namespaces used in the document, with a separate function to map that to a URN. I guess people will also want to know the prefix used. Although the prefix is theoretically arbitrary, there are likely to be many conventional prefixes in use and applications may want to leave the prefix unchanged in an output document. 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 Daniel.Brickley at bristol.ac.uk Mon Jul 20 14:34:43 1998 From: Daniel.Brickley at bristol.ac.uk (Dan Brickley) Date: Mon Jun 7 17:02:59 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: <007101bdb3d8$1dd443c0$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: On Mon, 20 Jul 1998, Michael Kay wrote: > >How should SAX support namespaces? I can think of three > options: > I guess people will also want to know the prefix used. > Although the prefix is theoretically arbitrary, there are > likely to be many conventional prefixes in use and > applications may want to leave the prefix unchanged in an > output document. Yes. It's also likely that some people will be interested in using namespace prefixes within the values of attributes. So the prefix<->URI mapping needs to be accessible if is to be intelligible, ie if the "ABC" in "ABC:someNameHere" is to be hooked up to a URI. 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 larsga at ifi.uio.no Mon Jul 20 14:48:28 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:02:59 2004 Subject: XCatalog proposal draft 0.1 Message-ID: <3.0.1.32.19980720144546.00732a34@ifi.uio.no> * John Cowan > >They come in two syntaxes: >one which is a subset of Socat syntax, and one which is an >XML document instance. I have to agree with the others speakers on this: - SO Catalogs should be supported for backward compatibility - XCatalogs are to be preferred over SO Catalogs, since they limit the number of syntaxes one has to learn Also, implementing XML catalog support is much easier than SO Catalog support. I have now implemented support both for SO Catalogs and the XML version of XCatalogs in xmlproc 0.50, which I released earlier today. The support is still rather experimental, and does not handle entry conflict resolution correctly. Once support for SO Catalogs was in place XCatalogs required just 20-30 lines. :-) > A small nit: ^ should be HRef, of course. >4. DTD > >The DTD for the XML instance syntax is (where an XCatalog element >is the root): What is the public identifier of this DTD? > Version CDATA #FIXED "1.0"> Should this perhaps be 0.1? >In the XML instance syntax, any #PCDATA content is considered comment, Smart! Definitely a good idea! >For uniformity below, the Map, Delegate, Extend, and Base elements >are referred to as "entries". Any particular reason why Document and Remap (SYSTEM in SO Catalogs) have been left out? Also, what about the more controversial parts of SO Catalogs such as ENTITY, NOTATION and DOCTYPE? I haven't made up my own mind about these yet, but it would be nice to hear some other opinions on this. (Hmmmm. Section 6 seems to have been omitted. :-) As for section 7 I find the explanation a bit cumbersome. Perhaps the algorithm could be generalized by using a priority system between entry types and individual entries? Also, have you verified that this section is 100% compatible with SO Catalogs? IMHO, it should be, so that one can implement a general catalog engine that is independent of the syntax. If the search algorithms do not match 100% this will be much more difficult, and anyway I can't see any reason to have different algorithms. IMHO the spec should also explicitly note that the search algorithms are the same. >If both syntaxes are supported, should Delegate and Extend entries >be allowed to refer from one syntax to another, or should Socat >catalogs refer only to other Socat catalogs and ditto for XML >instance catalogs? I think a catalog should only be allowed to refer to catalogs using the same syntax, unless we can standardize some means of detecting the catalog format prior to parsing the catalog. (File names, MIME-types etc.) If XCatalog implementations must support SO Catalogs IMHO XCatalogs should be allowed to refer to SO Catalogs, but not vice versa. Another thing: it might be a good idea to standardize environment variables and Java properties that can be used to point to the site socatalog/XCatalog, so that all parsers can use these (if they are present). I'd call the environment variables SOCATALOG and XCATALOG, and the Java properties xml.socatalog and xml.xcatalog. Overall, great effort! Keep going! --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Mon Jul 20 15:04:14 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:02:59 2004 Subject: [Q] How should SAX support Namespaces? Message-ID: <199807201246.OAA29128@berlin.dvs1.tu-darmstadt.de> Michael Kay wrote: > My vote is definitely for (3), though (1) needs to be an > option for compatibility. > > But rather than pass through the URN of the namespace in > each call, I would pass an integer identifying it within the > set of namespaces used in the document, with a separate > function to map that to a URN. > > I guess people will also want to know the prefix used. > Although the prefix is theoretically arbitrary, there are > likely to be many conventional prefixes in use and > applications may want to leave the prefix unchanged in an > output document. I strongly agree (3 with 1 for compatibility). In addition to the two niceties Michael suggests, I would like the parser also to parse the namespace PIs. Not only does this save all applications from writing the same code, parser writers probably already have low-level functions they can adapt/use for this purpose. The parser would use a separate callback (not processingInstruction) to return the namespace information. -- 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 Mon Jul 20 15:57:19 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:02:59 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: David Megginson's message of "Mon, 20 Jul 1998 07:32:24 -0400" References: <199807201132.HAA00572@unready.megginson.com> Message-ID: David> David Megginson => In article <199807201132.HAA00572@unready.megginson.com>, David => wrote: David> How should SAX support namespaces? I can think of three David> options: I'd like to add a fourth: define namespace support as a layer above SAX, which can interface with any SAX parser, and produce output similar to that of SAX with additional information. Then this "namespace library" can do one of your proposed actions: David> 1. Simply ignore them, and require the XML application to do David> the work (all of the necessary information is passed on by David> SAX). David> David> 2. Use the current interface, but allow namespace-aware SAX David> processors to prepend namespace URIs to element type and David> attribute names, as in David> David> startElement("urn:www.megginson.com:doc", ...) David> endElement("urn:www.megginson.com:doc", ...) David> David> 3. Revised org.xml.sax.AttributeList and org.xml.sax.DocumentHandler David> to include the namespace as a separate (possibly-null) argument: David> David> startElement("urn:www.megginson.com", "doc", ...) David> endElement("urn:www.megginson.com", "doc", ...) 4. Apply an application-specified re-mapping to the names. So the above could be initialised with ns_processor.setPrefix("urn:www.megginson.com", "davids-ns"); and have its document handler called with startElement("davids-ns:doc", ...) endElement("davids-ns:doc", ...) I don't particularly like (2) above, since it means that different SAX parsers may return different values for the same document. I do feel that namespace handling is orthogonal to syntactic parsing of XML, and that SAX itself should confine itself to the latter. I'm not sure whether namespace processing should happen between SAX and the application (layered approach) or separately "at the side" of the application (application developers' utility class). -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Mon Jul 20 16:49:03 1998 From: jtauber at jtauber.com (James K. Tauber) Date: Mon Jun 7 17:02:59 2004 Subject: Repository for XML Software at xmlsoftware.com Message-ID: <000601bdb3ed$8a25dc40$ea6118cb@caleb> As some of you may have noticed, I am about to re-release the software list that was on jtauber.com at xmlsoftware.com As the site has a high-speed link and the space I have is hardly going to be taken up by the list of software, I am more than willing to host (or mirror) the actual software itself for any developers that would find that useful. Please feel free to contact me if this interests you. James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From tbray at textuality.com Mon Jul 20 17:04:40 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:02:59 2004 Subject: [Q] How should SAX support Namespaces? Message-ID: <3.0.32.19980720080329.00bedeb0@pop.intergate.bc.ca> At 07:32 AM 7/20/98 -0400, David Megginson wrote: >3. Revised org.xml.sax.AttributeList and org.xml.sax.DocumentHandler > to include the namespace as a separate (possibly-null) argument: > > startElement("urn:www.megginson.com", "doc", ...) > endElement("urn:www.megginson.com", "doc", ...) I'd go for #3. -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 Patrice.Bonhomme at loria.fr Mon Jul 20 19:27:38 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:03:00 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: Your message of "Mon, 20 Jul 1998 07:32:24 EDT." <199807201132.HAA00572@unready.megginson.com> Message-ID: <199807201726.TAA08065@chimay.loria.fr> david@megginson.com said: ] 3. Revised org.xml.sax.AttributeList and org.xml.sax.DocumentHandler ] to include the namespace as a separate (possibly-null) argument: ] startElement("urn:www.megginson.com", "doc", ...) ] endElement("urn:www.megginson.com", "doc", ...) As i am developping an XML Parser in Java, my vote is for number 3. Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide * Projet Aquarelle : http://aqua.inria.fr ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jul 20 20:39:59 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:00 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: <00bf01bdb425$c58eed70$577670c6@endymion.eps.inso.com> References: <3.0.32.19980720080329.00bedeb0@pop.intergate.bc.ca> <00bf01bdb425$c58eed70$577670c6@endymion.eps.inso.com> Message-ID: <199807201835.OAA00256@unready.megginson.com> Gavin Thomas Nicol writes: > > At 07:32 AM 7/20/98 -0400, David Megginson wrote: > > >3. Revised org.xml.sax.AttributeList and org.xml.sax.DocumentHandler > > > to include the namespace as a separate (possibly-null) argument: > > > > > > startElement("urn:www.megginson.com", "doc", ...) > > > endElement("urn:www.megginson.com", "doc", ...) > > > > I'd go for #3. -Tim > > I'd prefer seperate events: > enterNamespace(String prefix, String urn); > leaveNamespace(String prefix, String urn); The problem is that you wouldn't be able to express something like the following (assume that the namespaces associated with "DOCBOOK:" and "LC:" are properly declared): [...] All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jul 20 21:11:16 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:00 2004 Subject: Namespaces on Attribute Names In-Reply-To: <199807201854.LAA23791@mehitabel.eng.sun.com> References: <199807201854.LAA23791@mehitabel.eng.sun.com> Message-ID: <199807201906.PAA00379@unready.megginson.com> Murray Altheim writes: > This of course required that I add a namespace variable to my class def. > for Element. I have not yet added any support for namespaces on attributes, > as I can't understand the rationale. Can't understand, or don't agree with? I have to admit that I have been uncomfortable with the idea myself. In any case, I'll offer myself as a victim to your pseudo-Socratic feigned ignorance, and suggest that namespaces on attributes are meant to represent a kind of implicit multiple inheritance, where the derived class is never explicitly named. Compare the following (the CRTC is the Canadian government's big-brother media supervisor -- if anyone wants to get me started on the CRTC, send private correspondence): XML Excerpt ----------- [...] Conceptual Equivalent in C++ ---------------------------- class LC { public: String &getRefNo (); }; class CRTC { public: String &getRating (); }; class Doc { public: String &getId (); [...] }; // This class is implicit. class MyDoc : public Doc, public LC, public CRTC { [...] } All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Mon Jul 20 22:43:14 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:00 2004 Subject: [Q] How should SAX support Namespaces? Message-ID: <009901bdb41d$cdc25c00$2ee044c6@arcot-main> David, Welcome back. >How should SAX support namespaces? I can think of three options: #3 is the obvious choice for me. In my own little experimental version, I also added following method to the DocumentHandler interface: void namespace (String ns, String src, String prefix); I added the above method because it is annoying for SAX clients to parse the namespace PI data into three attributes. Since parsers already have the code, why not leverage it? BTW: DOM spec update is out everyone. Free-DOM will follow soon (tonight or tommorrow). Best, Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jul 20 23:10:28 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:00 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: <007101bdb3d8$1dd443c0$1e09e391@mhklaptop.bra01.icl.co.uk> References: <007101bdb3d8$1dd443c0$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <199807202105.RAA00873@unready.megginson.com> Michael Kay writes: > But rather than pass through the URN of the namespace in > each call, I would pass an integer identifying it within the > set of namespaces used in the document, with a separate > function to map that to a URN. That will work as long as all namespaces are global (an approach which I personally prefer); however, given that locally-scoped namespaces may come in in the future, it would be nice to make SAX more robust and not to assume that all namespaces will be known at the start of the parse. > I guess people will also want to know the prefix used. > Although the prefix is theoretically arbitrary, there are > likely to be many conventional prefixes in use and > applications may want to leave the prefix unchanged in an > output document. I think that this might better be handled by having the application map URIs back to standard prefixes; that way, it won't matter if the source document used "XsL:" "xsl:" "xml-style-language:", etc. -- your output documents can always have what you consider to be standard (i.e. "XSL:"). Of course, if you choose not to use namespace processing (perhaps by choosing a SAX driver that doesn't support it), then you should see the prefixes. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Mon Jul 20 23:26:53 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:00 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: References: <007101bdb3d8$1dd443c0$1e09e391@mhklaptop.bra01.icl.co.uk> Message-ID: <199807202122.RAA00937@unready.megginson.com> Dan Brickley writes: > Yes. It's also likely that some people will be interested in using > namespace prefixes within the values of attributes. So the prefix<->URI > mapping needs to be accessible if is to > be intelligible, ie if the "ABC" in "ABC:someNameHere" is to be hooked up > to a URI. This is a good argument for making namespace declarations available. Should this go in a new handler type, NamespaceHandler? All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Mon Jul 20 23:33:20 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:00 2004 Subject: XCatalog proposal draft 0.1 In-Reply-To: <3.0.1.32.19980720144546.00732a34@ifi.uio.no> Message-ID: <3.0.1.16.19980720215607.36bfb746@pop3.demon.co.uk> At 14:45 20/07/98 +0200, Lars Marius Garshol wrote: >Overall, great effort! Keep going! Agreed! I have just been doing some work with SGML (sic) tools and finding that many of them take the existence of catalogs for granted. Indeed, I think that quite a lot of SGML-experienced people automatically assume some sort of catalog-like machinery when discussing how things will work in XML. Of course the XML 1.0 spec itself has no reference to catalogs and assumes that there is some mechanism for resolving (F)PIs - catalogs are probably the most likely one. 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 Mon Jul 20 23:33:54 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:00 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: <199807201132.HAA00572@unready.megginson.com> Message-ID: <3.0.1.16.19980720223336.2c7fd7c6@pop3.demon.co.uk> At 07:32 20/07/98 -0400, David Megginson wrote: >How should SAX support namespaces? I can think of three options: I am really pleased this subject has been raised because I think that it's critical to solve it at the SAX level. I have been waiting for syntactic guidance until the next Namespace draft is released, but playing with the abstract ideas in JUMBO2. So far it's been going quite well. I have layered this on top of SAX and have created two classes: Namespace UniversalName Every namespace generating event (a PI in the 1998May revision) can generate a Namespace. The event has to be checked for uniqueness of prefix (but no uniqueness of ns). These Namespaces can be retrieved by prefix from an ElementName. The ElementNames generate a UniversalName which for convenience inside the program I hold as nsString+SEPARATOR+localName. (The spec suggest an ordered pair - if we can find a SEPARATOR which is guaranteed not to occur in a URN it just makes it a bit easier (this is DavidM's #2 but with something other than COLON). [It never sees the light of day, anyway]. The Universal name is the thing which should be independent of document instance syntax. I use it primarily for mapping to Java classes and - in the absence of the rest of the world agreeing on how to do this - I have temporised with a PI of the form: where localPart (with initial capitalises letter) replaces %s. Thus CML:Molecule is mapped to jumbo.cml.MoleculeNode. When a common mechanism is agreed this PI can be disabled. The problem I face is with other specs (especially XPointer). These will have to be revised to fit namespaces, since I think relying on a prefix in a given document may be very dangerous. Thus I'd like to be able to search for in a document using XPointer but cannot rely on the 'CML'. [I know that some people say XPointer shouldn't be used for such 'searches' but my will is weak.] The XPointer spec will have to read something like: descendant(2,%universalName{[http://xml-cml%SEPARATOR]?Molecule}) where the [...]? means optional and the %universalName operator means 'use the UniversalName (which may or may not have a prefix according to what the document author decided). This will then cater for a document like: ... This might appear perverse but all three elements types can 'belong to the CML DTD'. [I am not invoking scoping.] In a multiauthor document I think it's quite possible that we shall see:

, and all referring to the HTML paragraph element. I also pass over the rather hairy problem of validating DTDs. I wonder whether namespace-aware DTD software has to add defaults on the basis of Universal names and not element types. Thus: ]> ... What attributes does the element have?? By tackling this at the SAX level we have a really wonderful opportunity to help ensure that ambiguities are as few as possible. I suspect that some exciting areas will arise - this is new territory! FWIW I am very pleased with what can be done with namespaces :-) P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Tue Jul 21 08:18:54 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:01 2004 Subject: A different comment syntax question In-Reply-To: <199807171619.JAA00164@orpheus.cs.sfu.ca> Message-ID: <199807210622.AA01768@murata.apsdc.ksp.fujixerox.co.jp> Rob Cameron wrote: > > No, I don't think it is equivalent. Proof: Agree. I should have been careful when I reviewed the XML PR ... I compared the two set with an automaton toolkit called Grail. (http://www.csd.uwo.ca/research/grail/download.html) Here is the result. 1. Set T: (Char* - (Char* '--' Char*)) D:\grail\binaries\486>retofm | fmdeterm | fmmin | fmcment | fmrenum > amt.txt DOS/4GW Protected Mode Run-time Version 1.95 Copyright (c) Rational Systems, Inc. 1990-1993 (a+b)*aa(a+b)* ^Z (Note: "a" represents "-" and "b" represents everything else.) D:\grail\binaries\486>type amt.txt (START) |- 0 2 a 2 2 b 2 0 a 1 0 b 0 1 a 2 1 b 0 0 -| (FINAL) 1 -| (FINAL) 2. Set X: ((Char - '-') | ('-' (Char - '-')))* D:\grail\binaries\486>retofm | fmdeterm | fmmin | fmrenum > amx.txt DOS/4GW Protected Mode Run-time Version 1.95 Copyright (c) Rational Systems, Inc. 1990-1993 (b+ab)* ^Z D:\grail\binaries\486>type amx.txt (START) |- 0 0 a 1 0 b 0 1 b 0 0 -| (FINAL) 3. Does set T include set X? D:\grail\binaries\486>fmcment amt.txt | fmcross amx.txt | fmdeterm | fmmin (The empty automaton) Yes 4. Does set X include set T? D:\grail\binaries\486>fmcment amx.txt | fmcross amt.txt | fmdeterm | fmmin (START) |- 1 1 b 1 0 b 1 1 a 0 0 -| (FINAL) No! Makoto Fuji Xerox Information Systems Tel: +81-44-812-7230 Fax: +81-44-812-7231 E-mail: murata@apsdc.ksp.fujixerox.co.jp xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From murata at apsdc.ksp.fujixerox.co.jp Tue Jul 21 08:49:17 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:01 2004 Subject: A different comment syntax question In-Reply-To: <199807171616.MAA25755@ruby.ora.com> Message-ID: <199807210652.AA01771@murata.apsdc.ksp.fujixerox.co.jp> Chris Maden wrote: > > Correct. The production reflects the SGML reality that -- ends a > comment. In SGML terms: A readable version is as below: Comment ::= '' This is idential to Comment ::= '' Again, I did the comparison with Grail. 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 M.H.Kay at eng.icl.co.uk Tue Jul 21 12:13:57 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:03:02 2004 Subject: [Q] How should SAX support Namespaces? Message-ID: <003501bdb490$a5cb5b20$1e09e391@mhklaptop.bra01.icl.co.uk> >David> How should SAX support namespaces? I can think of three >David> options: > >I'd like to add a fourth: define namespace support as a layer above >SAX... I think there is merit in this; given that XML Namespace is a separate standard layered on top of XML 1.0, and that it is perfectly legitimate to conform to XML 1.0 without conforming to Namespace. It makes sense to reflect the same structure in the API. In practice it would probably amount to much the same thing, the user would have the choice of giving the parser either a DocumentHandler with the current interface, or a NamespaceAwareDocumentHandler with a new enhanced interface. Mike Kay xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Tue Jul 21 14:19:22 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:02 2004 Subject: Free-DOM Updated Message-ID: <001201bdb4a0$95620d00$2ee044c6@arcot-main> Free-DOM has been updated. The Free-DOM page is at: http://www.docuverse.com/personal/freedom/index.html This version supports the latest version of the DOM spec which can be found at: http://www.w3.org/TR/1998/WD-DOM-19980720/ The purpose of this early release is to encourage "hands-on" play with the latest DOM spec. A "safer and faster" version will be released in two weeks for calmer crowd. Don Park xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jul 21 16:00:07 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:02 2004 Subject: SAX and Namespaces In-Reply-To: <35B3EFE7.36ACC145@Eng.Sun.COM> References: <35B3EFE7.36ACC145@Eng.Sun.COM> Message-ID: <199807211355.JAA00253@unready.megginson.com> David Brownell writes: > > David> 1. Simply ignore them, and require the XML application to do > > David> the work (all of the necessary information is passed on by > > David> SAX). > > Actually, not it isn't. SAX doesn't say where the DTD got parsed, so > layers (library, application) over SAX can't enforce the rule that > all namespace PIs must occur before the DTD. The W3C confidentiality rules won't allow me to answer this point right now. > The really sticky bit is that namespaces effictively modify the grammar > of XML so that only some names may be qualified (no entities/notations). > That effectively precludes any layered implementation over SAX, since > some entity declarations would need to be rejected during parsing (as > WF errors: SAX fatalError callbacks). As far as I understand, there is no intention to forbid colons in these names; rather, their meaning is unspecified, and they remain deprecated (as they are in the XML 1.0 spec). All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Jul 21 18:08:45 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:02 2004 Subject: [Q] How should SAX support Namespaces? References: <007101bdb3d8$1dd443c0$1e09e391@mhklaptop.bra01.icl.co.uk> <199807202105.RAA00873@unready.megginson.com> Message-ID: <35B4BD95.EA552ECF@mecomnet.de> David Megginson wrote: > > That will work as long as all namespaces are global (an approach which > I personally prefer); however, given that locally-scoped namespaces > may come in in the future, it would be nice to make SAX more robust > and not to assume that all namespaces will be known at the start of > the parse. this won't matter, since the uri is always global. so long as you offer the implement the option which you refer to below in the parser, the dynamic context of the application itself is managed distinct from that of the document, and distinct from that of any eventual dynamic context within the document. this "application specified" prefix should be that which is "passed through the interface". not the uri. > > I think that this might better be handled by having the application > map URIs back to standard prefixes; the parser should do this. > that way, it won't matter if the > source document used "XsL:" "xsl:" "xml-style-language:", etc. -- your > output documents can always have what you consider to be standard > (i.e. "XSL:"). > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Jul 21 18:31:38 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:02 2004 Subject: [Q] How should SAX support Namespaces? References: <3.0.1.16.19980720223336.2c7fd7c6@pop3.demon.co.uk> Message-ID: <35B4C2F5.E6109C07@mecomnet.de> Peter Murray-Rust wrote: > ... > The ElementNames generate a UniversalName which for > convenience inside the program I hold as nsString+SEPARATOR+localName. this is better managed as namespace : (nsString x universalName*) universalName : (namespace x localName) these are the "symbols" which i have alluded to in the past. the representation saves a lot on references to properties of the namespace itself. you also don't need the separator. you operate directly on universal names. it also saves you from the fate which you describe below. > (The > spec suggest an ordered pair - if we can find a SEPARATOR which is > guaranteed not to occur in a URN it just makes it a bit easier (this is > DavidM's #2 but with something other than COLON). [It never sees the light > of day, anyway]. > ... > The problem I face is with other specs (especially XPointer). These will > have to be revised to fit namespaces, since I think relying on a prefix in > a given document may be very dangerous. Thus I'd like to be able to search > for in a document using XPointer but cannot rely on the > 'CML'. [I know that some people say XPointer shouldn't be used for such > 'searches' but my will is weak.] The XPointer spec will have to read > something like: > descendant(2,%universalName{[http://xml-cml%SEPARATOR]?Molecule}) this problem is inherent in the string representation of universal names. it's one of the reason what the representation is a bad idea. if one manages universal names as symbols, the problem does not exist. the process which interns the xpointer maps the name token in the descendant clause to the same symbol to which the parser mapped the token decoded from a document. the comparisons are then pointer quality. neither the uri, nor the respective prefixes matter to the application. > where the [...]? means optional and the %universalName operator means 'use > the UniversalName (which may or may not have a prefix according to what the > document author decided). This will then cater for a document like: > > > > > > ... > > > > This might appear perverse but all three elements types can 'belong to the > CML DTD'. [I am not invoking scoping.] In a multiauthor document I think > it's quite possible that we shall see: >

, and all referring to the HTML paragraph element. > > I also pass over the rather hairy problem of validating DTDs. what do universal names change about validation? > > I wonder whether namespace-aware DTD software has to add defaults on the > basis of Universal names and not element types. Thus: > > > > > ]> > > ... > > > What attributes does the element have?? if you've used symbols rather than strings, the symbol "ChemML:Molecule" is the same as the symbol "CML:Molecule", since you've specified that the are in the same namespace. > > By tackling this at the SAX level we have a really wonderful opportunity to > help ensure that ambiguities are as few as possible. I suspect that some > exciting areas will arise - this is new territory! > yes, i agree. 1 : do it right once for at least tags and attribute names; + 1 : expose the interface to applications for use with attributes values and other tokens ------------- = the immense benefit of saving people a lot of trouble. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 21 19:06:08 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:03:02 2004 Subject: Free-DOM Updated Message-ID: <000701bdb4ca$3494c380$1e09e391@mhklaptop.bra01.icl.co.uk> >Free-DOM has been updated. I've updated SAXON to use the new Free-DOM (but not yet issued it). 2 minor points: - perhaps Freedom() should have a default constructor - I think for an Element with no attributes, element.getAttributes() should return a NamedNodeMap with getSize()=0; it actually returns null. Cheers, 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 James.Anderson at mecomnet.de Tue Jul 21 19:25:48 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:02 2004 Subject: Namespaces on Attribute Names References: <199807201854.LAA23791@mehitabel.eng.sun.com> <199807201906.PAA00379@unready.megginson.com> Message-ID: <35B4CFAC.60A43445@mecomnet.de> the suggested interpretation of qualified attribute names conflates two things (inheritance and namespaces). these are better left distinct - at least on the conceptual level on which i understood the response to have been situated. David Megginson wrote: > ... > XML Excerpt > ----------- > > > [...] > > > ... > > // This class is implicit. > class MyDoc : public Doc, public LC, public CRTC > { > [...] > } do i understand the suggestion correctly, to specify that the presence of an attribute from a given namespace denotes a dynamic subtype relation between the containing element and an element with the same name as the prefix used for the namespace (the correctness of applying 'LC.getRefNo' to the element). aren't there alternative ways to expresss that? ways which would be just as expressive, though less terse, but which would also allow permit other denotations and which don't lead to the such quandries as the following. if i follow your c++ example back to xml, i understand it to imply, for example, that the possible declaration applies to any element in which the attribute is present, but doesn't apply when the attribute is not. !? is this the kind of thing mr murray-rust is always alluding to when he mentions the "rather hairy problems of validating dtds" in the presence of qualified names? bye, xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jul 21 19:42:30 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:03 2004 Subject: Namespaces on Attribute Names In-Reply-To: <35B4CFAC.60A43445@mecomnet.de> References: <199807201854.LAA23791@mehitabel.eng.sun.com> <199807201906.PAA00379@unready.megginson.com> <35B4CFAC.60A43445@mecomnet.de> Message-ID: <199807211737.NAA00385@unready.megginson.com> james anderson writes: > the suggested interpretation of qualified attribute names conflates > two things (inheritance and namespaces). these are better left > distinct - at least on the conceptual level on which i understood > the response to have been situated. Please take my posting as descriptive rather than prescriptive: I'm attempting to supply an explicit conceptual framework for something that never properly had one, but am not promoting that framework as a good solution. > do i understand the suggestion correctly, to specify that the > presence of an attribute from a given namespace denotes a dynamic > subtype relation between the containing element and an element with > the same name as the prefix used for the namespace (the correctness > of applying 'LC.getRefNo' to the element). No, I wouldn't go that far, mainly because namespaces don't have elements or attributes; they just have names. I'd suggest instead that the attribute from a given namespace implies a subtype relationship between the current element and an unnamed element type that includes the qualified attribute. > aren't there alternative ways to expresss that? ways which would be > just as expressive, though less terse, but which would also allow > permit other denotations and which don't lead to the such quandries > as the following. (That's probably a rhetorical question.) Yes, architectural forms handle this situation much more smoothly by explicitly naming the supertype, though AF's, too, have their warts in other areas. > if i follow your c++ example back to xml, i understand it to imply, for > example, that the possible declaration > > > > applies to any element in which the attribute is present, but doesn't apply > when the attribute is not. !? Namespaces and DTDs are two different kinds of things: a DTD specifies what an author is allowed to include in a specific document, and what defaulting for attribute values, etc., should be used. A namespace simply guarantees that a name is globally unique, whatever that name happens to be used for. > is this the kind of thing mr murray-rust is always alluding to when > he mentions the "rather hairy problems of validating dtds" in the > presence of qualified names? There's not really a problem from that perspective: a DTD can/will restrict the particular uses of namespaces in a document, as in the following example: The problem with DTDs will come if namespaces include some kind of defaulting or local scoping mechanism -- at that point, writing a DTD for an XML document will become extremely difficult. 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 anders at rcs.urz.tu-dresden.de Tue Jul 21 19:49:59 1998 From: anders at rcs.urz.tu-dresden.de (Andrea Anders) Date: Mon Jun 7 17:03:03 2004 Subject: XML, HTML or SGML Message-ID: Hi, I want to create a learning environment for the internet based on SGML-Files. But SGML is unhandily, I think. (I use DynaWeb.) The learning environment should include a thesaurus, glossary, question & answers (interactively), control of learning progress, aids of navigation and orientation, make bookmarks, make annotations, searching for words. Furthermore it should contain case studies, schedule, email, mailinglists etc. I prefer XML, but you have much more experiences in electronic publishing of XML-, HTML- and SGML-documents. Which document format is the best for each component you think? A problem is I think that XML-documents can't be viewed via www-browser. MSIE 5.0 is not able to handle true XML, isn`t it? Thanks for help. Andrea xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 21 20:36:59 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:04 2004 Subject: XML, HTML or SGML In-Reply-To: Message-ID: <3.0.1.16.19980721193636.2be71efa@pop3.demon.co.uk> At 19:49 21/07/98 +0200, Andrea Anders wrote: >Hi, > >I want to create a learning environment for the internet Excellent! This is a really important area and one where there is a huge amount of scope. based on >SGML-Files. But SGML is unhandily, I think. (I use DynaWeb.) > >The learning environment should include a thesaurus, glossary, question & >answers (interactively), control of learning progress, aids of navigation and >orientation, make bookmarks, make annotations, searching for words. >Furthermore it should contain case studies, schedule, email, mailinglists >etc. I would strongly recommend XML - at least that is what I am going to use myself :-). here are some areas I know about: - we have implemented a robust scalable glossary/thesaurus tool (the Virtual Hyperglossary) at http://www.vhg.co.uk. This is based on XML (and its friends like XLink) and is designed to support any vertical sector (we already have projects in hand). It also supports multilinguality. It is based on ISO12620 so that by careful choice of dataCategorys you can create glossaries, dictionaries, thesauri, etc. We have used it on glossaries up to about 12000 terms with many levels of hierarchy. These can be handled by my (free) XML browser JUMBO if you have a reasonable amount of memory. The true power of the hyperglossary, however, is that it is designed to support multiple distributed glossaries, specifically through XLink (when the ink is dry on that spec). - Dan Brickley and colleagues (see XML-DEV a few months ago and probably www.sil.org) have developed a Tutorial Markup Language which should manage you multiple choice questions. - James Schoening and colleagues (through the P1484 project) are working on terminology for distance education and will be using XML. We - at the VSMS Nottingham - are developing XML tools for managing student information (including online submission and monitoring of work). There are doubtless lots of other projects at an early stage. > >I prefer XML, but you have much more experiences in electronic publishing >of XML-, HTML- and SGML-documents. Which document format is the best for >each component you think? > >A problem is I think that XML-documents can't be viewed via www-browser. >MSIE 5.0 is not able to handle true XML, isn`t it? I am told it does - MS are members of the W3C and have been actively supportive of XML. But it's very early days for the major browser manufacturers. HTH P. > >Thanks for help. > >Andrea > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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 frachel at BeaconSoftware.com Tue Jul 21 20:49:07 1998 From: frachel at BeaconSoftware.com (Frank Rachel) Date: Mon Jun 7 17:03:04 2004 Subject: C/C++ Parser/Tokenizer Message-ID: <91ECE593A11ED211B41D00C04F85A24502D38D@edison.beaconsoftware.com> I am looking for C or C++ code that I can incorporate in a program to simply walk through an XML file, and give me the Tag name and its associated value. For example: Frank etc.. I am looking for something that I can basically do while ( !end_of_xml_file() ) { get_tag_and_value ( tagname, value ); } Obviously, it wont be as simple as that, but I think you can grasp what I am looking for.. We're going to be getting a XML file and simple need to extract all the data, and map it to our own internal stuff.. So after I get the tag and value, I would do something like: switch ( tagname ) { case 'first' : strcpy ( my_struct.first_name, value, length ); break; } etc.. Any help would be greatly appreciated. I need it in C/C++ because it has to be callable from a C program, and be able to be compiled on multiple platforms.. Thanks, Frank Rachel xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From James.Anderson at mecomnet.de Tue Jul 21 20:51:35 1998 From: James.Anderson at mecomnet.de (james anderson) Date: Mon Jun 7 17:03:04 2004 Subject: DTDs and namespaces (was Re: Namespaces on Attribute Names References: <199807201854.LAA23791@mehitabel.eng.sun.com> <199807201906.PAA00379@unready.megginson.com> <35B4CFAC.60A43445@mecomnet.de> <199807211737.NAA00385@unready.megginson.com> Message-ID: <35B4E38E.95147809@mecomnet.de> David Megginson wrote: > > james anderson writes: > ... > > do i understand the suggestion correctly, to specify that the > > presence of an attribute from a given namespace denotes a dynamic > > subtype relation between the containing element and an element with > > the same name as the prefix used for the namespace (the correctness > > of applying 'LC.getRefNo' to the element). > > No, I wouldn't go that far, mainly because namespaces don't have > elements or attributes; they just have names. > ah!! music to my ears.... > I'd suggest instead that the attribute from a given namespace implies > a subtype relationship between the current element and an unnamed > element type that includes the qualified attribute. > but then, i'm not sure this is any better. if it's "unnamed" then all that has been accomplished is that, by virtue of changing the prefix between the tag name and the attribute name, you're permitting attributes in addition to those declared in an attlist. why encumber namespaces with this? > [skipping merrily over the rhetoric] > > Namespaces and DTDs are two different kinds of things: a DTD specifies > what an author is allowed to include in a specific document, and what > defaulting for attribute values, etc., should be used. A namespace > simply guarantees that a name is globally unique, whatever that name > happens to be used for. with which i agree, and which is why i am skeptical of saying that the presence of particular prefixes implies the pertinence of "unnamed" element types. > > ... > > The problem with DTDs will come if namespaces include some kind of > defaulting or local scoping mechanism -- at that point, writing a DTD > for an XML document will become extremely difficult. here we get to something substantive. with the proper storage model for universal names and the proper encoding semantics, i have yet to see a case where there is a problem. if the universal names are taken to denote symbols , then the prefixes (or the lack thereof in the case of implicit qualification through lexical or dynamic prefix scope) do (does) not matter. (please see my earlier posts in this thread as well as my responses to MURATA Makoto under the thread "attributes with intent (and namespaces)" ca. 03.07.) no, i do not claim it could be implemented to the benefit of the DPH. yes, it could be done with SAX. bye, xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From RKoehler at qpass.com Tue Jul 21 21:33:34 1998 From: RKoehler at qpass.com (Rich Koehler) Date: Mon Jun 7 17:03:04 2004 Subject: C/C++ Parser/Tokenizer Message-ID: Sounds like a job for the MSXML in C++ parser. I had a similar need for it. Check out the sample code: awful though it is, it does walk an XML document. http://www.microsoft.com/xml/parser/cparser.asp Rich xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 21 21:54:29 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:04 2004 Subject: C/C++ Parser/Tokenizer Message-ID: <3.0.32.19980721125201.00c40b20@207.34.179.21> At 12:30 PM 7/21/98 -0700, Rich Koehler wrote: > >Sounds like a job for the MSXML in C++ parser. I had a similar need for it. >Check out the sample code: awful though it is, it does walk an XML document. >http://www.microsoft.com/xml/parser/cparser.asp Or for expat at http://www.jclark.com/xml - the code is not at all awful, and it does what you need too. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Don.Schaefer at usa.xerox.com Tue Jul 21 22:59:22 1998 From: Don.Schaefer at usa.xerox.com (Schaefer, Don) Date: Mon Jun 7 17:03:04 2004 Subject: C/C++ Parser/Tokenizer Message-ID: <67E29010AC4BD111955E00805F0DBA3178E217@station10.roch875.mc.xerox.com> The latest expat has a sample that gets you well on your well on your way.... It sorta does what you have asked for. With a little modification.... don. ---------- From: Tim Bray[SMTP:tbray@textuality.com] Reply To: Tim Bray Sent: Tuesday, July 21, 1998 3:53 PM To: Rich Koehler; 'Frank Rachel'; xml-dev@ic.ac.uk Subject: RE: C/C++ Parser/Tokenizer At 12:30 PM 7/21/98 -0700, Rich Koehler wrote: > >Sounds like a job for the MSXML in C++ parser. I had a similar need for it. >Check out the sample code: awful though it is, it does walk an XML document. >http://www.microsoft.com/xml/parser/cparser.asp Or for expat at http://www.jclark.com/xml - the code is not at all awful, and it does what you need too. -T. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From sblackbu at erols.com Wed Jul 22 03:06:09 1998 From: sblackbu at erols.com (Samuel R. Blackburn) Date: Mon Jun 7 17:03:05 2004 Subject: C/C++ Parser/Tokenizer Message-ID: <001801bdb50c$ccd184c0$432e0318@cc221812-a.hwrd1.md.home.com> If you want source code, take a look at the XML classes in the freeware Win32 Foundation Classes (WFC) library. It is a non-validating parser. http://ourworld.compuserve.com/homepages/sam_blackburn/wfc.htm HTH, Sam -----Original Message----- From: Frank Rachel To: xml-dev@ic.ac.uk Date: Tuesday, July 21, 1998 7:31 PM Subject: C/C++ Parser/Tokenizer >I am looking for C or C++ code that I can incorporate in a program to >simply walk through an XML file, and give me the Tag name and its >associated value. > >For example: > > > Frank > > >etc.. > >I am looking for something that I can basically do > >while ( !end_of_xml_file() ) >{ > get_tag_and_value ( tagname, value ); >} > >Obviously, it wont be as simple as that, but I think you can grasp what >I am looking for.. We're going to be getting a XML file and simple need >to extract all the data, and map it to our own internal stuff.. > >So after I get the tag and value, I would do something like: > >switch ( tagname ) >{ > case 'first' : > strcpy ( my_struct.first_name, value, length ); > break; >} > >etc.. > >Any help would be greatly appreciated. I need it in C/C++ because it has >to be callable from a C program, and be able to be compiled on multiple >platforms.. > >Thanks, > >Frank Rachel > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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 rbourret at dvs1.informatik.tu-darmstadt.de Wed Jul 22 10:05:40 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:05 2004 Subject: XSchema: unparsed entities Message-ID: <199807220800.KAA12081@berlin.dvs1.tu-darmstadt.de> At the risk of becoming flame bait, I'd like to ask again why we removed unparsed entities from XSchema. On the one hand, unparsed entities exist for purely physical reasons -- you can't easily stored binary data in a text (XML) file -- and therefore don't pass our XSchema-describes-logical-structures-only test. On the other hand, an unparsed entity is a very close cousin to a PCDATA-only Element with a NOTATION attribute. In both cases, a separate application processes the data and the only real difference seems to be whether the XML parser first parses that data; that the unparsed entity data is stored separately is really a red herring. Thus, the unparsed entity becomes a special type of element (logical structure) for holding unparseable data. One other difference I'd like to point out is that, with the exception of the "escape character" entities (lt, gt, amp, quot, and apos), I don't think you can construct an XML file with parsed entities that you cannot construct without them. This is not true of unparsed entities. Not only would an UnparsedEntity element rectify this problem, it would also solve the validation problem pointed out by John Cowan with respect to ENTITY attributes: we can't validate their value without unparsed entity declarations. -- 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 Patrice.Bonhomme at loria.fr Wed Jul 22 10:12:21 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:03:05 2004 Subject: SAX questions Message-ID: <199807220811.KAA15181@chimay.loria.fr> I have developped an XML Parser in Java and a tree based API which works fine. I have implemented the whole XML 1.0 (REC 10-02-1998), the XML Namespaces (WD 27-03-1998, the Document Object Model Level 1 (DOM Core and XML, WD 16-04-1998) and both XML links and XML pointers. I'd like now providing and event based API. I am considering the SAX API for developping a SAX driver to my XML parser. I've got already an XMLFactory (an interface with a default implementation) that constructs my XML objects and i've got a few questions: 1/ For instance, the construction of the tree is supporting by the parser (with some insertLast(...)). Do i need to transfer the tree construction within the "default XML handler" ? 2/ What about CDATA sections, XML declaration, and validation processus ? 3/ If i understand the event-based philosophy, an XML parser do not need to know something about DOM objects (no "new Element()", "new Comment()" called within the code of the parser !) ? 4/ Is there a kind of "blue print" for developping an event-based XML parser ? Thanks, Pat. PS: Informations about my XML parser are available at http://www.loria.fr/projets/XSilfide/EN/sxp/ -- ============================================================== 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 SimonStL at classic.msn.com Wed Jul 22 15:21:10 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:05 2004 Subject: Xschema - Printable Specification Message-ID: Many thanks to Jack Bolles for creating a single-document version of the latest versions of the XSchema spec. http://users.homeaccount.com/~jbolles/XschemaSpecLong.htm It isn't final yet - there are still some questions being hashed out - but if you'd like to take a look at the spec as a single piece, it's now available. (It makes a lot more sense that way, actually!) I'll be putting up a link soon at http://purl.oclc.org/NET/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 rbourret at dvs1.informatik.tu-darmstadt.de Wed Jul 22 17:37:59 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:05 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 5 Message-ID: <199807221532.RAA17792@berlin.dvs1.tu-darmstadt.de> Carl Hage wrote: > However, moving + into a token string creates a severe > problem. It's impossible to add information associated with each code value, > for example documentation on the semantics for each. Also, it may be common > to import enumeration values defined within an external standard, e.g. by > using xml links. > > To correct the problem, simply add back in, e.g. > I agree, although for a different reason. I've just gotten to writing this part of the code and have to admit that having to parse something the parser can parse for me makes me very grumpy indeed. Note that the EnumerationValue element is used by both enumerated attributes and notation 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 richard at cogsci.ed.ac.uk Wed Jul 22 17:53:42 1998 From: richard at cogsci.ed.ac.uk (Richard Tobin) Date: Mon Jun 7 17:03:05 2004 Subject: C/C++ Parser/Tokenizer In-Reply-To: Frank Rachel's message of Tue, 21 Jul 1998 14:50:46 -0400 Message-ID: <199807221553.QAA22036@stevenson.cogsci.ed.ac.uk> > I am looking for C or C++ code that I can incorporate in a program to > simply walk through an XML file, and give me the Tag name and its > associated value. The LT-XML system is suitable for this. You can find it at http://www.ltg.ed.ac.uk/software/xml/index.html It's free for non-commercial use. -- 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 SimonStL at classic.msn.com Wed Jul 22 18:07:13 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:06 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 5 Message-ID: Carl Hage writes: > To correct the problem, simply add back in, e.g. > Ron Bourret writes: >I agree, although for a different reason. I've just gotten to writing >this part of the code and have to admit that having to parse >something the parser can parse for me makes me very grumpy indeed. >Note that the EnumerationValue element is used by both enumerated >attributes and notation attributes. I have no objections to this; it seems to return some of the flexibility and documentability we lost by moving to the attributes model, without bringing back too much verbosity. Anyone disagree? 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 larsga at ifi.uio.no Wed Jul 22 18:09:32 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:06 2004 Subject: Xschema comments Message-ID: <3.0.1.32.19980722180549.0073364c@ifi.uio.no> I've just read the XSchema spec for the first time and have some minor comments: - 2.3.5: Perhaps the reference content model should be called element content model instead? That's what it is and the Element GI is free since element declarations are called ElementDecl. In the very last paragraph there is a typo: OneOrMore should be ZeroOrMore. - 2.3.6: "The XSchema processor should ignore any frequency attributes in the Ref element." Perhaps it would be better to require it to give a warning, since quite a few people are bound to try this and will be confused when the content model is silently accepted, but still doesn't work like they expected. - 2.4.3: The thorny issue of entity references in attribute default values does not seem to be dealt with in any way. Perhaps this should be explicitly disallowed, since XSchemas do not provide any means for entity declaration? If not, should entity references of the standard kind be regarded as parameter entity references in DTDs, while &entref;-style references be considered entity references in the entity replacement text? In the latter case, how would these entities be defined? Although the standard interpretations of XML constructs may make this a non-issue I think it would be a good idea to spell out the XSchema policy on this to avoid confusion. - 3.0: Simple typo in second paragraph: "...the 18 May 1998 "Namespaces in XML" Working Draft and is will change ..." ^^ Apart from these nits the XSchema spec looks good to me, although more features would of course be desirable. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Wed Jul 22 18:16:04 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:06 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: <199807201132.HAA00572@unready.megginson.com> Message-ID: <3.0.1.32.19980722181350.00738498@ifi.uio.no> * David Megginson | | 3. Revised org.xml.sax.AttributeList and org.xml.sax.DocumentHandler | to include the namespace as a separate (possibly-null) argument: | | startElement("urn:www.megginson.com", "doc", ...) | endElement("urn:www.megginson.com", "doc", ...) I think this is the way to go, but perhaps it would be better to use an object that encapsulates all the information about a namespace and then pass that object as the first parameter instead? Something like this: public interface Namespace { String getURI(); String getPrefix(); String getSchemaURL(); String toString(); // Convenience alias for getURI() } If we require the same Namespace object to be passed for every occurrence of a construct in that Namespace this is also efficient, both in terms of parameter construction and namespace comparison. Implementations will have to map the namespace prefix to an object anyway, the only difference will be the type of said object. I also agree with Ron that there should be a namespace declaration callback. Supporting alternative 1 for backward compatibility seems difficult to me. --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jul 22 22:44:47 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:06 2004 Subject: SAX questions In-Reply-To: <199807220811.KAA15181@chimay.loria.fr> References: <199807220811.KAA15181@chimay.loria.fr> Message-ID: <199807222045.QAA02326@unready.megginson.com> Patrice Bonhomme writes: > 1/ For instance, the construction of the tree is supporting by the > parser (with some insertLast(...)). Do i need to transfer the tree > construction within the "default XML handler" ? SAX can work as an iterator over a tree, but it is suboptimal: a good iterator would return each tree node. For my MSXML SAX driver, I explicitly disabled tree construction, since the greatest advantage of an event-based (or streaming) API is the light resource usage. > 2/ What about CDATA sections, XML declaration, and validation > processus ? CDATA sections and the XML declaration may both be included in a level-two SAX, aimed at authoring tools, but they are not relevant for the down-level processing tasks (such as formatting or database import) which were SAX's initial target. The user chooses validation or non-validation implicitly through the selection of a SAX driver; SAX itself has no facility for turning validation on or off, though it does allow an application to distinguish validation errors from well-formedness errors (and to ignore validation errors if desired). > 3/ If i understand the event-based philosophy, an XML parser do not > need to know something about DOM objects (no "new Element()", "new > Comment()" called within the code of the parser !) ? The level-one SAX does not report comments. If you are using FREE-DOM, you can let FREE-DOM take care of node creation; if you are building your own DOM using SAX, then you should create nodes inside the handlers. > 4/ Is there a kind of "blue print" for developping an event-based > XML parser ? Not specifically, but if you have access to a copy of DESIGN PATTERNS (Gamma, Helm, Johnson, and Vlissides) take a look at the Visitor pattern on page 331. More usefully, many of the existing XML parsers come with source code, so dive in! All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Thu Jul 23 02:24:50 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:06 2004 Subject: [Announce] Online XML Analysis Tool Message-ID: Announcing HXA - Hubick's XML Analyzer. HXA is a production based online XML parser/analysis tool in Java. It uses HXP, a Java XML parser I am writing. HXA allows one to examine the production hierarchy for any character in an XML document or document fragment. You can try out the very beta release at: http://www.hubick.com/software/HXA/ Feedback is appreciated. Thanks. --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Thu Jul 23 12:09:43 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:06 2004 Subject: SAX questions Message-ID: <3.0.1.32.19980723120736.006f13dc@ifi.uio.no> * Patrice Bonhomme | | [...] I couldn't understand questions 1 & 2, so I haven't answered them. | 3/ If i understand the event-based philosophy, an XML parser do not | need to know something about DOM objects (no "new Element()", "new | Comment()" called within the code of the parser !) ? That's right. A sensible way to deal with this might be to take a layered approach and give the parser just a simple SAX-like event interface with callbacks for all the different events. Then, you might make a special client to the event interface that uses the event callbacks to build a DOM tree. Your event interface would probably have more events than SAX, so a SAX driver would probably use another special event client that only echoed some of the events to the SAX handlers. -- "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 rajnishb at gsslco.co.in Fri Jul 24 08:59:46 1998 From: rajnishb at gsslco.co.in (Rajnish Bharti) Date: Mon Jun 7 17:03:06 2004 Subject: Microsoft's C++ based XML Parser Message-ID: <01bdb71f$9b1d2690$130310ac@dionysus.pune.gsslco.co.in> Hi !! I, was going thru the code for parsing an XML file as suggested by Microsoft. The site is http://www.microsoft.com/msdn/sdk/inetsdk/help/itt/xml/overview/Sample_1.htm #Sample_1 I, came across 3 header files viz. dispex.h mshtml.h msxml.h which I, could not locate anywhere. however the DLL's for the same are present on my system. Is there any way out so that I, can compile the source on my machine ?? Are these header files or their corresponding .idl files present anywhere on the Internet ? Thanx, in advance . ~Rajnish xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From grove at infotek.no Fri Jul 24 10:56:00 1998 From: grove at infotek.no (Geir Ove) Date: Mon Jun 7 17:03:07 2004 Subject: Announce: xmlarch.py - An XML architectural forms processor written in Python Message-ID: <199807240903.LAA07068@mail.infotek.no> xmlarch.py: An XML architectural forms processor written in Python Version: 0.10 Author: Geir Ove Grønmo Email: grove@infotek.no Released: July 24th 1998 Homepage: http://www.infotek.no/~grove/software/xmlarch/xmlarch.html --- What is xmlarch.py? The xmlarch.py module contains an XML architectural forms processor written in Python. It allows you to process XML architectural forms using any parser that uses the SAX interfaces. The module allow you to process several architectures in one parse-pass. Architectural document events for an architecture can even be broadcasted to multiple DocumentHandlers. The XML architecture processor uses the SAX DocumentHandler interface which means that you can register the architecture handler (ArchDocHandler) with any SAX 1.0 compliant parser. No meta-DTDs are currently read by xmlarch.py, but a DTD parser will be used when one is avaliable. Note that this is a very early release and that a lot of things may be missing. But; it's free! All kinds of feedback is valuable for the further development of xmlarch.py. Enjoy! Geir Ove Grønmo -- ================== Geir Ove Grønmo ================== | STEP Infotek as, Gjerdrumsvei 12, 0486 Oslo, Norway | | grove@infotek.no http://www.infotek.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 peter at ursus.demon.co.uk Fri Jul 24 12:30:53 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:07 2004 Subject: Announce: xmlarch.py - An XML architectural forms processor written in Python In-Reply-To: <199807240903.LAA07068@mail.infotek.no> Message-ID: <3.0.1.16.19980724113018.37f7e12e@pop3.demon.co.uk> At 11:03 24/07/98 +0200, Geir Ove wrote: > >xmlarch.py: An XML architectural forms processor written in Python Excellent news! [...] > >Note that this is a very early release and that a lot of things may be >missing. But; it's free! > >All kinds of feedback is valuable for the further development of xmlarch.py. > [You may already have done this :-)]. I haven't looked at the distribution, but if you or collaborators can find time to put some examples and tutorial material together I am sure it would be much appreciated. One of the big problems with AFs is getting the message across and showing what they can do. 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 grove at infotek.no Fri Jul 24 13:01:26 1998 From: grove at infotek.no (Geir Ove Gronmo) Date: Mon Jun 7 17:03:07 2004 Subject: Announce: xmlarch.py - An XML architectural forms processor written in Python In-Reply-To: <3.0.1.16.19980724113018.37f7e12e@pop3.demon.co.uk> References: <199807240903.LAA07068@mail.infotek.no> Message-ID: <3.0.2.32.19980724125132.011e87f4@mail.infotek.no> At 11:30 24.07.98, Peter Murray-Rust wrote: >[You may already have done this :-)]. I haven't looked at the distribution, >but if you or collaborators can find time to put some examples and tutorial >material together I am sure it would be much appreciated. One of the big >problems with AFs is getting the message across and showing what they can do. There are some some test material in the xmlarch.py distribution, but no general introduction to XML/SGML architectures. There are some references to resources at the xmlarch homepage ( http://www.infotek.no/~grove/software/xmlarch/xmlarch.html ) though. I would like to point you to David Megginson's excellent XAF page. There you will find introductions for both document designers and software developers. See: http://www.megginson.com/XAF/index.html Eliot Kimber has also written an introduction called 'A Tutorial Introduction to SGML Architectures': http://www.isogen.com/papers/archintro.html See also The SGML/XML Web Page's links on 'Architectural Forms and SGML/XML Architectures': http://www.sil.org/sgml/topics.html#archForms For more formal descriptions see the Architectural Form Definition Requirements [AFDR]: http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.html and Geir O. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From north at Synopsys.COM Fri Jul 24 16:22:22 1998 From: north at Synopsys.COM (Simon North) Date: Mon Jun 7 17:03:08 2004 Subject: XML Notepad Message-ID: <199807241423.QAA06885@goofy.gr05.synopsys.com> Just in case you all missed it (I haven't seen an announcement anywhere): XML Notepad Beta 1, July 22, 1998 Microsoftr XML Notepad is a simple prototyping application for HTML authors and developers that enables the rapid building and editing of small sets of XML-based data. With XML Notepad, developers can quickly create XML prototypes in an iterative fashion, using familiar metaphors. http://www.microsoft.com/xml/notepad/intro.asp On another tack. Is anyone else going to the Microsoft Internet Platforms & Technologies Summit in Seattle on Monday? 3 days of details on IE5, WFC and XML. Should be good. Unless I'm mistaken, the NDA only covers IE5 code but I will check the small print and, time permitting, I will mail as full a report as I can. Simon North north@synopsys.com sintac@xs4all.nl PGP Fingerprint 97FA 6A6C 1136 A66A 431D 8454 9C16 F677 A4C8 9CE2 "Presenting XML", "HTML4 Unleashed, PRE", "Dynamic Web Publishing Unleashed", "Teach Yourself XML in 21 Days" (October 1998) So much stupidity ... so few comets ... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From szpak at well.com Fri Jul 24 17:04:51 1998 From: szpak at well.com (Mark Szpakowski) Date: Mon Jun 7 17:03:08 2004 Subject: XML Notepad In-Reply-To: <199807241423.QAA06885@goofy.gr05.synopsys.com> Message-ID: <199807241504.IAA19293@smtp.well.com> At 04:24 PM 7/24/98 +0001, Simon North wrote: > XML Notepad Beta 1, July 22, 1998 Unfortunately doesn't support namespaces... :-( - Mark __________________________________ Mark Szpakowski Systems Architect Knowledge Navigators International Halifax, Nova Scotia, Canada szpak@well.com mark.szpakowski@learningengine.com Voice 902/422-1577 Fax 902/422-4964 __________________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Fri Jul 24 17:21:55 1998 From: jackpark at thinkalong.com (Jack Park) Date: Mon Jun 7 17:03:08 2004 Subject: Announce: xmlarch.py - An XML architectural forms processor written in Python In-Reply-To: <3.0.2.32.19980724125132.011e87f4@mail.infotek.no> References: <3.0.1.16.19980724113018.37f7e12e@pop3.demon.co.uk> <199807240903.LAA07068@mail.infotek.no> Message-ID: <199807241521.IAA06492@mail.cwia.com> Interesting coincidence: some XML stuff in Python, and this announcement of JPython. Thought you all might be interested. Jack Park Further Information Contact Jim Hugunin Lead Developer for JPython (617) 621-7152 hugunin@python.org http://www.python.org/jpython JPYTHON-1.0 PROVIDES A POWERFUL COMPANION TO JAVA Supports Embedded Scripting, Interactive Experimentation, and Rapid Application Development Reston, VA -- The Corporation for National Research Initiatives has announced the release of JPython-1.0. JPython is a freely available implementation of the high-level, dynamic, object-oriented language Python -- integrated seamlessly with the Java(TM) platform and certified as 100% Pure Java(TM). "CNRI is gratified with the positive response to the beta releases of JPython. We think it is the perfect complement to Java," said Albert Vezza, vice president of CNRI. JPython is especially well suited for embedded scripting, interactive experimentation, prototyping applications, and building any system where programmer productivity is a primary concern. Its rich integration with Java allows programmers to freely mix JPython and Java code without giving up any of the advantages of either language. "JPython is to Java and JavaBeans what Visual Basic(TM) is to C++ and Microsoft(TM) COM(TM) objects," said Nathan Sharp of Phoenix Integration. "The seamless integration easily makes JPython the most powerful scripting language for Java around." JPython's integration with Java draws on the strengths of the Java platform. JPython code can easily access any existing Java libraries and JavaBeans. The Java virtual machine allows JPython to statically compile Python source code to Java bytecodes that will run anywhere that Java does. Through Java's support for dynamic class loading, JPython can dynamically compile Python code to allow interactive use while still achieving the performance of a true compiler. Others are noticing and taking advantage of the power JPython provides to Java developers: "Using JPython, we have complete access to our Java-based system software without writing new interfaces, hooks or wrappers," said Ken Swisz, Cougar Software Manager at KLA-Tencor Corp. "This gives our users all the power we can possibly provide at a relatively low investment in effort for us. The advantage in using JPython over other choices is tremendous. The language itself is well designed, and its object-oriented nature makes it a natural fit for Java. I have been recommending it to other organizations in the company for their use as a scripting language." "The first generation of our CASE tool used Tcl as its integrated scripting language," said Dan Snider, president of Object Domain Systems Inc. "In developing Object Domain 2.0, we decided to instead use JPython. The transition was primarily motivated by the desire for an Object-Oriented scripting language, Python's cleaner syntax, and JPython's seamless integration with Object Domain's Java-based framework." "By providing easy access to the rich Java graphics APIs, JPython is clearly the number one choice for developers of GUI applications," said Norman Shelley of Motorola Corp. Guido van Rossum created the Python language in the early 1990s, and it has been used successfully in many interesting software projects since then. Steve Kirsch, the chairman of Infoseek Corp., describes his experiences with the language: "Over the past 30 years, I've written code in every major programming language. Python is my favorite programming language by a wide margin. It's an elegant, well-designed language that can be learned in a few hours. In addition, the code is easy to read and large systems are easy to maintain. There is simply no faster way to develop applications. A skilled Python programmer can, on average, crank out applications five times faster than a programmer in more traditional languages." JPython completely implements the Python language in 100% Pure Java, and is freely available in both source and binary form. In order to implement Python's Perl5-compatible regular expressions, JPython includes the outstanding OROMatcher(TM) regular expression engine developed by Original Reusable Objects(TM) at http://www.oroinc.com. By agreement, this regular expression engine is only distributed in binary form. JPython can be found at http://www.python.org/jpython. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 24 17:47:56 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:08 2004 Subject: Namespaces (was Re: XML Notepad) In-Reply-To: <199807241504.IAA19293@smtp.well.com> References: <199807241423.QAA06885@goofy.gr05.synopsys.com> Message-ID: <3.0.1.16.19980724164440.427f10ba@pop3.demon.co.uk> At 12:04 24/07/98 -0300, Mark Szpakowski wrote: >At 04:24 PM 7/24/98 +0001, Simon North wrote: >> XML Notepad Beta 1, July 22, 1998 > >Unfortunately doesn't support namespaces... :-( I sympathise. The formal position is that there is no REC or PR for namespaces in XML. If you read the rubric on WDs you will see that WDs can be obsoleted at any time. Therefore anyone writing software to support a WD has to bear this in mind and presumably the author(s) of this software did... and decided not to include namespaces. I am sure that there are many members of XML-DEV who wish to incorporate namespaces into their software and documents. I have been hacking the latest namespace draft into jumbo.xml.SAX - i.e. making it minimally namespace-aware. I have to plan for what I have done to be made obsolete. I am therefore hoping that there will be some clarification on namespaces from the W3C RSN. When that happens I shall probably junk the JUMBO code and hope that we can move to adding namespaces to SAX as rapidly as possible. 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 RKoehler at qpass.com Fri Jul 24 18:18:59 1998 From: RKoehler at qpass.com (Rich Koehler) Date: Mon Jun 7 17:03:08 2004 Subject: Microsoft's C++ based XML Parser Message-ID: > I, came across 3 header files viz. > dispex.h > mshtml.h > msxml.h > which I, could not locate anywhere Rajnish, Those are included in Microsoft's Internet SDK. Rich xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 24 20:51:50 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:08 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 6 Message-ID: Following is the latest draft of Section 2.4, Attribute Declarations. This section appears to be the magnet for the most criticism. The XSC:EnumerationValue element is back, and can be used for both enumerated types and notation enumerations. (Thanks to Carl Hage and Ron Bourret for feedback on this one.) I haven't taken up Carl's other suggestion, that the default value be given its own element. I can see where it _might_ be worth documenting, but I'm not sure it's worth the inconvenience. As always, I'm open to convincing. As always, a prettier HTML version of this will be posted shortly at http://purl.oclc.org/NET/xschema. Simon St.Laurent Dynamic HTML: A Primer / XML: A Primer / Cookies 2.4 Attribute Declarations 2.4.1 Overview Attribute declarations are made with XSC:AttDef elements. XSC:AttDef elements may be nested inside of XSC:ElementDecl element declarations or linked to element. The type of an attribute is defined with an attribute, as is a declaration of whether or not it is required and a possible default value. Values for enumerated types are provided with subelements. In XSchema 1.0, an attribute declaration (XSC:AttDef element) may be nested within the element declaration (XSC:ElementDecl element) for the element to which the attribute belongs. If the XSC:AttDef element appears nested inside an XSC:ElementDecl element, the Element attribute must be ignored. If the XSC:AttDef element appears nested under the XSC:XSchema element, the Element attribute may contain a name token corresponding to the Name attribute of the element to which this attribute applies. If the Element attribute is missing, that XSC:AttDef declaration applies to all elements within the declaration's parent XSC:XSchema element and any child XSC:XSchema elements. The Name attribute of the XSC:AttDef element provides the name by which the attribute will be identified. Attribute names must be unique within the element in which they are declared. A nested declaration is shown below. ...additionalElementInformation... This declares an element with the name Species that has an attribute named status. If the status attribute was declared outside of the Species element declaration, the declarations would appear as shown below. ...additionalElementInformation... ... Merely naming an attribute may be adequate. Attribute declarations may identify types and provide information about whether the attribute is required. By default, attributes will be assumed to contain character data (CData), not be required, and have no default value. This information is declared using additional attributes. The simplest attribute declaration possible identifies an attribute as containing character data (CData) and allows the attribute to be optional, as shown below. Applications may also use the id attribute to provide unique identifiers for attribute declarations using values that are unique within the XSchema. 2.4.2 Attribute Types XSchema 1.0 provides equivalents for all of the XML 1.0 DTD attribute types. All of them are declared using attribute values within the XSC:AttDef element. The CData attribute type is one of the most common, permitting an attribute to contain character data as defined by the XML 1.0 specification. If the Species element were to contain an attribute providing the Latin name of the species, the declaration could look like the following. (The Type attribute could actually be omitted in this case, as CData is the default type.) ...additionalElementInformation... This attribute would then be available for use in instances of the Species element: ...additionalContent... The ID attribute type is used to uniquely identify elements in a document for application processing. IDRef and IDRefs attribute types are used to refer to a single ID value in the same document or multiple ID values in the same document, separated by whitespace, respectively. These attribute declarations must be used with the same constraints as apply to ID, IDREF, and IDREFS attribute types in XML 1.0. The Entity and Entities attribute types identify the names of unparsed entities. The use of these attribute types must be made with the same constraints as apply to the ENTITY and ENTITIES attribute types in XML 1.0. If a document is checked directly against an XSchema without a conversion to a DTD, information regarding unparsed entities must be available from the parser for these attribute types to be meaningful. The Nmtoken and Nmtokens attribute types are used to declare attributes that must contain information conforming to the Nmtoken and Nmtokens productions in XML 1.0. The Notation and Enumerated attribute types are more complex, requiring Enumeration subelements to identify their possible content. These two declarations use similar syntax, but the allowed values of Notation declarations must match the Notations declared elsewhere in the XSchema document. If the status attribute of the Species element were to allow the values of extinct, endangered, protected, and non-threatened, an appropriate enumerated type declaration would look like: ...additionalElementInformation... A Species element created conforming to this declaration might look like: ...additionalContentAboutDodos... 2.4.3 Attribute Defaults XSchema requires attribute declarations to provide information about the default value of a given attribute. XSchema provides for the four cases supported by XML 1.0: #REQUIRED, #IMPLIED, #FIXED AttValue, and AttValue, though they are expressed as choices between required and not required and fixed or not fixed, with an optional default value. There may be only one default value declaration per attribute. Required attributes (identified in XML 1.0 by #REQUIRED) are identified by assigning the value "Yes" to the Required attribute of an XSC:AttDef element. For instance, if the Latin attribute described above was required by the Species element, the XSC:AttDef element would contain a Required attribute with a value of "Yes": ...additionalElementInformation... Optional attributes (identified in XML 1.0 by #IMPLIED) are identified assigning the value "No" to the Required attribute of an XSC:AttDef element and not assigning a value to the AttValue attribute. Implied indicates that there is no default value provided, and also that no value is required. If the Latin attribute is optional, the XSC:AttDef element would contain a "No" value for the Required attribute. (Note that this is the default status and the Required declaration does not need to be made explicitly.) ...additionalElementInformation... Fixed attributes (identified in XML 1.0 by #FIXED AttValue) are identified through the use of the Fixed attribute in combination with the AttValue attribute, which must contain the fixed value for the attribute. Attributes declared using fixed value cannot declare a different value for that attribute. Fixed effectively hard codes attribute values into particular elements. If the Fixed attribute has a value of "Yes", the AttValue attribute must be present. A Fixed value without an AttValue must be treated as an error. For example, to declare a planet attribute for the Species element, a Fixed attribute given the value of "Yes" would identify the fixed nature of the attribute and the AttValue attribute would provide the value. ...additionalElementInformation... Attributes may also be provided with a default value that may be overridden by other declarations. These default values are identified through the use of the AttValue attribute. The status attribute of species elements described above would be an appropriate target for such a default value, especially if most species being described fell into a particular category: ...additionalElementInformation... Any default (required, fixed, etc.) may be used with any attribute type, though default values should always correspond to acceptable values for the attribute type. 2.4.4 Combinations of Types, Defaults, and Default Values This notation also permits the declaration of certain attributes (IDs with defaults, for instance) that are prohibited by the standard XML 1.0 DTD syntax. Developers who use these combinations should test that their documents will behave as expected in DTD-only environments as well as XSchema environments. Additional processing of document instances may be necessary to produce normalized-for-DTD use documents if they included such attributes as default values. The attribute type should always be considered more important than its default values in XSchema to DTD conversion. The table below summarizes the possible combinations of XSchema attribute defaults and their XML 1.0 DTD equivalents. Required Fixed AttValue XML 1.0 Value Yes Yes This does not occur in XML. It means that the instance file must include the value and the value must be the fixed value. At best this enforces duplication. Yes Yes -- error Yes No This does not occur in XML. It means that the instance file must include a value and the default happens to be whatever is given with AttValue. This should be treated as simply AttValue for maximum compatibility. Yes No -- #REQUIRED No Yes #FIXED No Yes -- error No No AttValue No No -- #IMPLIED xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 24 22:40:50 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:08 2004 Subject: SAX and namespaces: an implementation Message-ID: <35B8F13E.BDADD14E@locke.ccil.org> I have developed a SAX driver that implements namespace processing. The current version does not do validation of the namespace constraints (namespace PIs can appear anywhere, unknown prefixes are left alone, etc. etc.) The efficiency is not all it could be, as I have primarily been concerned with proof of concept. All the code shares the SAX non-license. Here are the details: Three new classes are involved: org.xml.sax.ParserFilter, org.xml.sax.helpers.PseudoAttributeList, and org.xml.sax.helpers.NamespaceFilter. (I want this to be a standard part of the SAX package, but if David objects I'll change the package names to org.ccil.cowan.sax.) ParserFilter is a subinterface of Parser, which adds the method "setParser(Parser parser)" to specify the underlying parser. Semantically, ParserFilters look like Parsers but rely on some other Parser to do the dirty work. They can be chained. (XAF is a ParserFilter in effect, and perhaps could be modified to implement this interface.) PseudoAttributeList is an implementation of AttributeList that knows how to set itself up from the "data" portion of a PI. I split it out because there probably will be other PIs which are made to look like they contain attribute lists. No entity references are processed within the pseudo-attribute values; processing character references is a reasonable enhancement. (XAF does this too, but not in a distinguishable way.) NamespaceFilter is a ParserFilter that does namespace processing. To use it, create an instance of the real parser, create a NamespaceFilter instance, and use setParser to link the two. Then any SAX application which registers as a DocumentHandler with the NamespaceFilter instance will receive element names, attribute names, and PI targets mapped from the "prefix:local" form to the form "URI + dagger (\u2020) + local". Unknown prefixes are currently left alone rather than reporting an error. If you don't want to process this format, call "registerPrefix" specifying a namespace URI and a prefix your application prefers, and document prefixes will be mapped to application prefixes instead of URIs. (This works only if the document prefix has been properly declared with a namespace declaration and an exactly matching URI, of course.) The colon delimiter is left in place in that case, unless the application prefix is the null string. A public method "universalName" allows you to invoke the mapping mechanism yourself for attribute values or the like. There are also two utility (static) methods to split up a universal name into its URI and local-part. I think this pretty much does everything that people on the list said they wanted (except namespace-rules validation), and without burdening SAX parsers or requiring SAX applications to choose between ns-aware parsers and ns-unaware ones. Instead, it is *applications* which are ns-aware or not, and handle their needs by using NamespaceFilter or not. 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 cowan at locke.ccil.org Fri Jul 24 22:49:19 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:08 2004 Subject: General apology to several mailing lists Message-ID: <35B8F335.4C0A476C@locke.ccil.org> It seems that almost all of my outbound mail for the last week (everything except what I send from home, which is very little) has fallen into a black hole. I have retransmitted everything, using a different SMTP server. My apologies for sending so much all at once. Also, my apologies to those of you who will get this more than once (but it does give a nice conspectus of my current interests if you look at the headers). Also, if any of the old messages reappear at some future time, my further apologies, and I have no control over the errant server. -- 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 Jul 24 23:24:29 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:09 2004 Subject: XCatalog proposal draft 0.1 References: <3.0.1.32.19980720144546.00732a34@ifi.uio.no> Message-ID: <35B8F052.707F0C52@locke.ccil.org> Lars Marius Garshol scripsit: > I have to agree with the others speakers on this: > - SO Catalogs should be supported for backward compatibility > - XCatalogs are to be preferred over SO Catalogs, since they > limit the number of syntaxes one has to learn I agree too, but didn't want to prejudice the opinions of the XML-DEVers. > I have now implemented support both for SO Catalogs and the XML > version of XCatalogs in xmlproc 0.50, which I released earlier > today. The support is still rather experimental, and does not > handle entry conflict resolution correctly. I propose something one week, rough consensus emerges the next week, and working code a week or two later: such is the Internet freeware development community. Peace, it's wonderful! > Once support for SO Catalogs was in place XCatalogs required > just 20-30 lines. :-) > > > > > A small nit: ^ should be HRef, of course. I disclaim all efforts to set capitalization standards. Personally, I like all-uppercase element names and all-lowercase attribute names. > >4. DTD > > > >The DTD for the XML instance syntax is (where an XCatalog element > >is the root): > > What is the public identifier of this DTD? Make one up. I would lean towards something like "-//XML-DEV Mailing List//DTD XCatalog 1.0//EN > > Version CDATA #FIXED "1.0"> > > Should this perhaps be 0.1? The *draft* number is 0.1, but the standard will be 1.0 when it is a standard. > >In the XML instance syntax, any #PCDATA content is considered comment, > > Smart! Definitely a good idea! Thanks. > >For uniformity below, the Map, Delegate, Extend, and Base elements > >are referred to as "entries". > > Any particular reason why Document and Remap (SYSTEM in SO Catalogs) > have been left out? DOCUMENT is very likely not a problem, and I wouldn't object to it too much in the draft, but it's really separate and distinct from the idea of XCatalogs as enablers for public IDs. (To its credit, OASIS TR 9401:1997 admits there are two separate issues.) As for SYSTEM: it is laid down in the XML spec that system IDs are URIs, so remapping them here is inappropriate: URI interpreters have their own conventions for remapping. (It's easy to write a trivial HTTP server that does nothing but redirect, and there are several public ones in operation, such as http://purl.oclc.org .) > Also, what about the more controversial parts of > SO Catalogs such as ENTITY, NOTATION and DOCTYPE? I haven't made up > my own mind about these yet, but it would be nice to hear some other > opinions on this. A (validating) XML parser that respects any of these is out of compliance with XML 1.0, so I ignore them. Their effect (loosening the bindings between XML objects and external objects) can be achieved by making the corresponding declarations in the DTD or instance refer to public IDs in some catalog. DTDDECL does the same thing as PUBLIC in an XML context, and I thought of supporting it for backward compatibility, but I realized that backward compatibility is pointless, since DTDs are almost always either XML or SGML and rarely both. So we might just as well treat XML DTDs just like all other external entities, using PUBLIC. > (Hmmmm. Section 6 seems to have been omitted. :-) Yes, it used to be Example, and then I remembered that some people like their examples up front. > As for section 7 I find the explanation a bit cumbersome. Perhaps > the algorithm could be generalized by using a priority system between > entry types and individual entries? Feel free to come up with a better explanation. Section 7 as written is a direct description of the obvious algorithm, and anything that works "as if" this algorithm were being used is certainly going to be compliant. > Also, have you verified that this section is 100% compatible with > SO Catalogs? IMHO, it should be, so that one can implement a general > catalog engine that is independent of the syntax. There are a few problems. XCatalogs as specified are case-sensitive whereas OASIS TR 9401:1997 is not, but all actual catalog examples use uppercase only AFAIK. Also, I have imposed a slightly more restrictive comment syntax, requiring whitespace both before and after all comments, except comments at BOF or EOF. This too seems to conform to actual practice. (Note that the formal grammar of TR 9401:1997 is *not* authoritative about comments: 8879 is.) > If the search > algorithms do not match 100% this will be much more difficult, and > anyway I can't see any reason to have different algorithms. Nor can I. > IMHO > the spec should also explicitly note that the search algorithms are > the same. Good idea. > >If both syntaxes are supported, should Delegate and Extend entries > >be allowed to refer from one syntax to another, or should Socat > >catalogs refer only to other Socat catalogs and ditto for XML > >instance catalogs? > > I think a catalog should only be allowed to refer to catalogs using > the same syntax, unless we can standardize some means of detecting > the catalog format prior to parsing the catalog. (File names, > MIME-types etc.) If XCatalog implementations must support SO Catalogs > IMHO XCatalogs should be allowed to refer to SO Catalogs, but not vice > versa. Is auto-detection really so hard? (If it goes "plop, plop" it could be a frog or a ripple, but the frequency of a frog is too high to think about, as is the rest mass of a ripple.) Anyway, what about the Master Catalog? By your rules it would have to be both a Socat (when it is referred to by Extend) and an instance catalog (when it refers to other catalogs via Delegate). > Another thing: it might be a good idea to standardize environment > variables and Java properties that can be used to point to the site > socatalog/XCatalog, so that all parsers can use these (if they are > present). > > I'd call the environment variables SOCATALOG and XCATALOG, and the > Java properties xml.socatalog and xml.xcatalog. I would rather have just one variable/property, allow multiple entries in it, (the "system-dependent list of URIs" mentioned in clause 7) and make the catalog parser worry about syntax. But I am not averse to standardizing names. -- 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 Jul 24 23:25:06 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:09 2004 Subject: [Q] How should SAX support Namespaces? References: <199807201132.HAA00572@unready.megginson.com> Message-ID: <35B8F05B.7ABBD816@locke.ccil.org> Toby Speight scripsit: > David> How should SAX support namespaces? I can think of three > David> options: > > I'd like to add a fourth: define namespace support as a layer above > SAX, which can interface with any SAX parser, and produce output > similar to that of SAX with additional information. Then this > "namespace library" can do one of your proposed actions: I absolutely agree with this. In fact, I think that this simple species of namespace support should be provided as part of the SAX helper library, so that everyone has it readily available. That way, SAX-compliant XML parsers can just do XML and leave namespaces up to common code. > David> 1. Simply ignore them, and require the XML application to do > David> the work (all of the necessary information is passed on by > David> SAX). This corresponds to not using a helper class at all. > David> 2. Use the current interface, but allow namespace-aware SAX > David> processors to prepend namespace URIs to element type and > David> attribute names, as in > David> startElement("urn:www.megginson.com:doc", ...) > David> endElement("urn:www.megginson.com:doc", ...) This corresponds to a helper class that is itself a SAX-compliant parser. Just initialize it with the object representing some other (real) parser, and it decodes namespace PIs and alters the startElement, endElement etc. calls. I must point out, however, that since ":" is valid in URIs it should *not* be used as the separator between URIs and Names, and instead some character not valid in either should be used. Since we are in a Java/Unicode context, I propose '\u2020' DAGGER as the separator: both Arial Sans Unicode and Bitstream Cyberbit have glyphs for it, which assists debugging. > David> 3. Revised org.xml.sax.AttributeList and org.xml.sax.DocumentHandler > David> to include the namespace as a separate (possibly-null) argument: > David> > David> startElement("urn:www.megginson.com", "doc", ...) > David> endElement("urn:www.megginson.com", "doc", ...) And this would be a helper class that exports an interface related to, but different from, the SAX 1.0 interface. > 4. Apply an application-specified re-mapping to the names. So the > above could be initialised with > ns_processor.setPrefix("urn:www.megginson.com", "davids-ns"); > and have its document handler called with > startElement("davids-ns:doc", ...) > endElement("davids-ns:doc", ...) This would be another helper class, also a SAX 1.0 compliant parser. > I don't particularly like (2) above, since it means that different SAX > parsers may return different values for the same document. I don't understand this comment. > I do feel that namespace handling is orthogonal to syntactic parsing > of XML, and that SAX itself should confine itself to the latter. I'm > not sure whether namespace processing should happen between SAX and > the application (layered approach) or separately "at the side" of the > application (application developers' utility class). Layered, layered, says I. Option #2's class would be IMHO the most useful, since you can plug it into an existing SAX-using application with zero changes to the interface, and just start testing for names like "http://purl.oclc.org/NET/xschema\u2020XSchema". -- 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 Jul 24 23:26:20 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:09 2004 Subject: Further thoughts on XCatalogs Message-ID: <35B8F063.87CED0CA@locke.ccil.org> Sorry that I can't (due to network problems) post my XCatalog drafts to my Web site just at present. I have had two new thoughts: If XCatalogs don't have to have a specific root element like "XCatalog", then it would be possible to incorporate them into random XML documents, so that any document could serve as an XCatalog as long as it had (empty) elements with the right names. Since instance-syntax catalogs have to be fully parsed with an XML parser anyway, this is easily enough done. This requires that XCatalog elements have a namespace of their own, of course, which is surely a good idea anyhow. -- 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 Jul 24 23:29:26 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:09 2004 Subject: [Q] How should SAX support Namespaces? References: <3.0.1.16.19980720223336.2c7fd7c6@pop3.demon.co.uk> Message-ID: <35B8F09B.3D3B9ACF@locke.ccil.org> Peter Murray-Rust wrote: > [I]f we can find a SEPARATOR which is > guaranteed not to occur in a URN it just makes it a bit easier (this is > DavidM's #2 but with something other than COLON). [It never sees the light > of day, anyway]. Dagger! \U2020! Dagger! > java="jumbo.cml.%sNode"> > where localPart (with initial capitalises letter) replaces %s. Thus > CML:Molecule is mapped to jumbo.cml.MoleculeNode. When a common mechanism > is agreed this PI can be disabled. The trouble here IMHO is that this mapping is app-specific, not really document-specific. You will want to load various Java classes depending on what you want to *do* to a particular element: edit it, render it, translate its content into HTML, ... > The problem I face is with other specs (especially XPointer). These will > have to be revised to fit namespaces, since I think relying on a prefix in > a given document may be very dangerous. Thus I'd like to be able to search > for in a document using XPointer but cannot rely on the > 'CML'. [I know that some people say XPointer shouldn't be used for such > 'searches' but my will is weak.] I think you are over-generalizing. The point of namespace PIs is to let you realize that my FOO:BAR is your BAZ:BAR, because my FOO prefix has the same namespace URI as your BAZ prefix. So your document can refer to some element of mine as BAZ:BAR, and a proper XLL engine will actually return FOO:BAR. There is no need, IMHO, to handle the case that you insist on finding literally "BAZ:BAR" as an element name. > I wonder whether namespace-aware DTD software has to add defaults on the > basis of Universal names and not element types. Thus: > > > > > ]> > > ... > > > What attributes does the element have?? None! DTD processing is SGML-compatible and namespace-blind. To DTD-based software, CML:Molecule and ChemML:Molecule are as different as A and \U0391 (GREEK CAPITAL LETTER ALPHA). -- 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 Jul 24 23:29:39 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:09 2004 Subject: XSchema Spec - Attribute Declarations (Section 2.4), Draft 5 References: <199807221532.RAA17792@berlin.dvs1.tu-darmstadt.de> Message-ID: <35B8F0E4.E7FF2B48@locke.ccil.org> Ron Bourret wrote: > I agree, although for a different reason. I've just gotten to writing this part > of the code and have to admit that having to parse something the parser can > parse for me makes me very grumpy indeed. Note that the EnumerationValue > element is used by both enumerated attributes and notation attributes. I also agree. Indeed, it was the asymmetry between NOTATION/enumeration and the other eight types (which require no ancillary data) that made Ron & I agree to move them to elements in the first place. One has to work harder than necessary either way. But the main principle of XML back-ends is that all parsing should be done by the parser! There should be no second-level parsers that have to decipher some embedded syntax. (This means that I deprecate ENTITIES, NMTOKENS, and IDREFS.) -- 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 Jul 24 23:29:36 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:09 2004 Subject: XSchema: unparsed entities References: <199807220800.KAA12081@berlin.dvs1.tu-darmstadt.de> Message-ID: <35B8F0D7.DB30960A@locke.ccil.org> Ron Bourret scripsit: > One other difference I'd like to point out is that, with the exception of the > "escape character" entities (lt, gt, amp, quot, and apos), I don't think you can > construct an XML file with parsed entities that you cannot construct without > them. Actually, they too can be "compiled out" by clever use of character references: see the table in clause 4.6 of XML 1.0. > This is not true of unparsed entities. Not only would an UnparsedEntity > element rectify this problem, it would also solve the validation problem pointed > out by John Cowan with respect to ENTITY attributes: we can't validate their > value without unparsed entity declarations. Okay, I'm convinced. (Note also that SAX supports them.) How 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 peter at ursus.demon.co.uk Sat Jul 25 00:52:53 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:11 2004 Subject: XCatalog proposal draft 0.1 In-Reply-To: <35B8F052.707F0C52@locke.ccil.org> References: <3.0.1.32.19980720144546.00732a34@ifi.uio.no> Message-ID: <3.0.1.16.19980724233604.289f3a2e@pop3.demon.co.uk> At 16:36 24/07/98 -0400, John Cowan wrote: >Lars Marius Garshol scripsit: > >> I have to agree with the others speakers on this: >> - SO Catalogs should be supported for backward compatibility >> - XCatalogs are to be preferred over SO Catalogs, since they >> limit the number of syntaxes one has to learn > >I agree too, but didn't want to prejudice the opinions of the >XML-DEVers. But you are allowed to lead gently... :-) > >> I have now implemented support both for SO Catalogs and the XML >> version of XCatalogs in xmlproc 0.50, which I released earlier >> today. The support is still rather experimental, and does not >> handle entry conflict resolution correctly. > >I propose something one week, rough consensus emerges the next >week, and working code a week or two later: such is the Internet >freeware development community. Peace, it's wonderful! I totally agree. And so long as everyone is prepared for the inevitable times when things don't go as hoped for - not failures, but experiments - it's a tremendous experience. Mind you, Hofstadter's law still applies. > [... Hofstadter's frog snipped ...] P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Jul 25 00:52:58 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:11 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: <35B8F09B.3D3B9ACF@locke.ccil.org> References: <3.0.1.16.19980720223336.2c7fd7c6@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980724234551.2f8f3a2c@pop3.demon.co.uk> At 16:37 24/07/98 -0400, John Cowan wrote: >Peter Murray-Rust wrote: > >> [I]f we can find a SEPARATOR which is >> guaranteed not to occur in a URN it just makes it a bit easier (this is >> DavidM's #2 but with something other than COLON). [It never sees the light >> of day, anyway]. > >Dagger! \U2020! Dagger! > >> > java="jumbo.cml.%sNode"> >> where localPart (with initial capitalises letter) replaces %s. Thus >> CML:Molecule is mapped to jumbo.cml.MoleculeNode. When a common mechanism >> is agreed this PI can be disabled. > >The trouble here IMHO is that this mapping is app-specific, not really >document-specific. You will want to load various Java classes >depending on what you want to *do* to a particular element: >edit it, render it, translate its content into HTML, ... I fully agree. This was just a first pass to illustrate some of the concerns for namespace processing. As I have said before I'd love to get consensus on a series of possible behaviours/functions that one might map elements to. At present I have one main function - JComponent XNode.getDisplayComponent() which returns a component for embedding into a SwingSet environment. But I'm also trying to devise validate(), processRecursively(), etc. I am not sure that these are naturally going to arise elsewhere.. [...PMR namespace concerns snipped...] IT was probably not a good idea to raise concerns of this sort and we should wait for enlightenment from the W3C. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Jul 25 00:53:01 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:11 2004 Subject: SAX and namespaces: an implementation In-Reply-To: <35B8F13E.BDADD14E@locke.ccil.org> Message-ID: <3.0.1.16.19980724234939.2eff2b42@pop3.demon.co.uk> At 16:40 24/07/98 -0400, John Cowan wrote: [... an exciting description of a namespace-aware SAX implementation...] > >Three new classes are involved: org.xml.sax.ParserFilter, >org.xml.sax.helpers.PseudoAttributeList, and >org.xml.sax.helpers.NamespaceFilter. (I want this to be >a standard part of the SAX package, but if David objects >I'll change the package names to org.ccil.cowan.sax.) I'll let David answer this but I am sure we can manage the same communal approach as has been so successful so far. >I think this pretty much does everything that people on the list >said they wanted (except namespace-rules validation), and without >burdening SAX parsers or requiring SAX applications to choose >between ns-aware parsers and ns-unaware ones. Instead, >it is *applications* which are ns-aware or not, and handle their >needs by using NamespaceFilter or not. This sounds very promising. Let's hope it maps easily onto the next draft. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Jul 25 16:00:09 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:11 2004 Subject: XCatalog proposal draft 0.1 [From Murray Altheim] Message-ID: <3.0.1.16.19980725143902.36ef6566@pop3.demon.co.uk> > >Date: Fri, 24 Jul 1998 15:27:30 -0700 (PDT) >From: Murray Altheim >Subject: Re: XCatalog proposal draft 0.1 >To: cowan@locke.ccil.org >Cc: xml-dev@ic.ac.uk >Mime-Version: 1.0 >Content-MD5: O2iZwUR+crikepw8yyr+gA== > >John Cowan writes: >> Lars Marius Garshol scripsit: >> >> > I have now implemented support both for SO Catalogs and the XML >> > version of XCatalogs in xmlproc 0.50, which I released earlier >> > today. The support is still rather experimental, and does not >> > handle entry conflict resolution correctly. >> >> I propose something one week, rough consensus emerges the next >> week, and working code a week or two later: such is the Internet >> freeware development community. Peace, it's wonderful! > >John, this is no criticism of the proposal itself, but 'rough consensus' >requires that you have participation. Because this mailing list is not >part of any recognized standards activity, there is no procedural method >for creating standards, nor is there any obligation for either comment >or recognition of anything that occurs on this list from its participants. > >> > Once support for SO Catalogs was in place XCatalogs required >> > just 20-30 lines. :-) >> > >> > > >> > >> > A small nit: ^ should be HRef, of course. >> >> I disclaim all efforts to set capitalization standards. Personally, >> I like all-uppercase element names and all-lowercase attribute names. > >I'm not sure that 'HRef' is any preferable 'Href'. Both have precedent. >If it came to a vote, I'd probably go with the camelcase of 'HRef', but >so long as there is consistency, I don't care particularly. I think the >proposal as posted is fine, although I'd change 'PublicID' to 'PublicId' >for the same nit reasons you used 'HRef'. 'Identifier' is one word, and >that fits in with the camelcase usage everywhere else in the XML spec. > >> The *draft* number is 0.1, but the standard will be 1.0 when it is >> a standard. > >Again, discussion of standardization and version numbers is rather out >of place, unless I'm mistaken and this has already been proposed to a >standards body. If so, my apologies. Note that even W3C does not produce >'standards' (but rather 'recommendations'), as they are not a standards >body, rather an industry consortium. > >[...] >> > Also, what about the more controversial parts of >> > SO Catalogs such as ENTITY, NOTATION and DOCTYPE? I haven't made up >> > my own mind about these yet, but it would be nice to hear some other >> > opinions on this. >> >> A (validating) XML parser that respects any of these is out of compliance with >> XML 1.0, so I ignore them. Their effect (loosening the bindings >> between XML objects and external objects) can be achieved by making >> the corresponding declarations in the DTD or instance refer >> to public IDs in some catalog. > >An XML 1.0 parser that does anything at all with catalogs is going beyond >the spec, but is not out of compliance. The question was open. I would >recommend any declaration that allows for a publicId should allow for >catalog resolution. Because the XCatalog proposal follows Socats, you >should simply rely on the features of Socats as appropriate to XML and >not concern yourself with existing implementation support. IOW, you can >rely on whatever showing up in a final draft of the Socat proposal as >being the expected set of resolution features. All of this in the end >will need to be hashed over by a lot of people. I would suspect that >if ENTITY and NOTATION are in 9401, they should be XCatalog, otherwise >transformation from a Socat format to XCatalog would result in loss of >information. > >I'd suggest adding: > > Notation ::= "NOTATION" WS Name WS SystemLiteral > > Entity ::= "ENTITY" WS Name WS SystemLiteral > >or at least discussing things with the Socat editors to garner what will >be in the final. (Last I heard this was still in progress.) > >As for searching, it would be better if you simply referenced the Socat >spec as much as possible. Behaviour should be identical as much as possible. >As regards name resolution, I'm not aware that XML should be substantially >different than SGML. If the features exist, it should be the same, IMO. > >> DTDDECL does the same thing as PUBLIC in an XML context, and I thought >> of supporting it for backward compatibility, but I realized that >> backward compatibility is pointless, since DTDs are almost always >> either XML or SGML and rarely both. So we might just as well treat XML >> DTDs just like all other external entities, using PUBLIC. > >You might note that James Clark has removed support for DTDDECL in SP. I'm >guessing he might know about this than you or I, and possibly DTDDECL will >be removed from Socats. Just a guess. > >[...] >> > Also, have you verified that this section is 100% compatible with >> > SO Catalogs? IMHO, it should be, so that one can implement a general >> > catalog engine that is independent of the syntax. > >This was the point I made in a previous paragraph. > >> There are a few problems. XCatalogs as specified are case-sensitive >> whereas OASIS TR 9401:1997 is not, but all actual catalog examples >> use uppercase only AFAIK. Also, I have imposed a slightly more >> restrictive comment syntax, requiring whitespace both before and >> after all comments, except comments at BOF or EOF. This too >> seems to conform to actual practice. (Note that the formal grammar >> of TR 9401:1997 is *not* authoritative about comments: 8879 is.) >[comments on search algorythms elided...] > >Remember that catalog support, the individual specs for URIs, URNs, URLs, >etc. are outside of the scope of XML. The only part of XCatalogs that >should be case sensitive is the markup syntax itself. Catalog content >is like any other XML attribute content -- free of restraints other than >those imposed by whatever attribute type is declared. Case is not >part of this for CDATA. > >> > >If both syntaxes are supported, should Delegate and Extend entries >> > >be allowed to refer from one syntax to another, or should Socat >> > >catalogs refer only to other Socat catalogs and ditto for XML >> > >instance catalogs? > >If in the end there is XML catalog support for both syntaxes, I would >assume that a catalog parser would import a catalog into an application, >and its internal representation would be independent of the source format. >Restrictions as stated above are unnecessary and overly stringent, and >in practice would make life rather more difficult for catalog admins. > >> > Another thing: it might be a good idea to standardize environment >> > variables and Java properties that can be used to point to the site >> > socatalog/XCatalog, so that all parsers can use these (if they are >> > present). >> > >> > I'd call the environment variables SOCATALOG and XCATALOG, and the >> > Java properties xml.socatalog and xml.xcatalog. > >This seems out of scope for a catalog proposal. > >Last week I modified the catalog support on my parser to allow for >export of an XML version mirroring the draft. It was not much extra >work. Here are some comments. > >> 1. Introduction >> >> XCatalogs are Web resources (anything from local files on up) >> which contain mappings from public identifiers to system identifiers, >> plus references to other XCatalogs. They come in two syntaxes: >> one which is a subset of Socat syntax, and one which is an >> XML document instance. > >If this is to go ahead as a formal proposal, I surmise you will be >including definitions (eg., 'Socat', etc.) and a list of resources. > >> 2. Example >> >> Here's an example XCatalog in both syntaxes, for those who learn >> best from examples: >> >> -- catalog for "-//John Cowan" public IDs -- >> BASE "http://www.ccil.org/~cowan/" >[...] >> >> catalog for "-//John Cowan" public IDs >> > >Why in your example is the original comment rendered as element >content? Was this intentional? In my implementation, I merely >used XML comments, as '-- text --' translates to '' >in XML. > >> Other ::= Name (WS Name)? (WS SystemLiteral)* > >I'm looking over the 9401 TR and noting that you're mirroring the syntax >of most of that document. I understand the rationale in not supporting >some of the more arcane or inapplicable features therein, but I'm not sure >that the expression for 'Other' entries will suffice. Given that catalogs are >often (in practice) delimited by line breaks, and 'Other' allows for optional >Names and SystemLiterals, how will a Socat-to-XCatalog parser/translator know >it has reached the end of a an 'Other' entry given that it is undefined? > >I do think that catalog support in XML is important. Very important here >at Sun. And I do think your proposal is a very good first slice at what >we might need for XML. I would suggest bringing this before a real >standards body such as the IETF or persuading someone to push it as a >work item for the XML WG. I looked at the XML WG Briefing Package and >note that it is not an work item currently. > >A note from you just came in: >> I have had two new thoughts: If XCatalogs don't have to have a >> specific root element like "XCatalog", then it would be possible >> to incorporate them into random XML documents, so that any document >> could serve as an XCatalog as long as it had (empty) elements with >> the right names. Since instance-syntax catalogs have to be fully >> parsed with an XML parser anyway, this is easily enough done. >> >> This requires that XCatalog elements have a namespace of their own, of >> course, which is surely a good idea anyhow. > >Remember that catalog files currently enjoy support only insofar as they >are 'standardized' within the industry. If someone wants to use the >current Socat syntax in their own custom way, this obviously would have >no wider use than their proprietary software. This requires no modication >to the Socat spec, and I would strongly urge that the XCatalog proposal >not be polluted with featuritis. If someone wants to use an XCatalog >element in their own application, there would be no required change to >the XCatalog spec, and indeed, to do so would require implementors to >support this feature. > >---- > >I hope these comments have been helpful. Written hastily, so note that I >haven't spent any time editing for diplomacy or spelling. Just as an 'if >I were you' aside, I'd remove the version number, write it up as an IETF >Internet Draft and post it. If I saw this as an IETF Internet Draft, I'd >be happy to post a notice to XML-SIG (and I think I could get Jon to >post it to the WG) so you'd at least get the attention of those >interested so they could comment on this in the IETF. As part of a >discussion on XML-DEV, it has the same priority for me (and probably >others) as the XSchema proposal: a good, necessary feature, but not part >of an extended activity that I can justify easily to my boss given it >has no product. > >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 dgd at cs.bu.edu Sat Jul 25 19:20:59 1998 From: dgd at cs.bu.edu (David G. Durand) Date: Mon Jun 7 17:03:11 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: <35B8F09B.3D3B9ACF@locke.ccil.org> References: <3.0.1.16.19980720223336.2c7fd7c6@pop3.demon.co.uk> Message-ID: At 8:37 PM -0000 7/24/98, John Cowan wrote: >I think you are over-generalizing. The point of namespace PIs is >to let you realize that my FOO:BAR is your BAZ:BAR, because my FOO prefix >has the same namespace URI as your BAZ prefix. So your document can >refer to some element of mine as BAZ:BAR, and a proper XLL engine >will actually return FOO:BAR. There is no need, IMHO, to handle >the case that you insist on finding literally "BAZ:BAR" as an >element name. It is not at all clear that XLL will work that way. It's designed to work for XML 1.0 not necessarily XML 1.0 + namespaces. I'd be surprised If namespace processing for linking is not at least optional (layered) in that same way that namespaces are purported to be. Of course, the XLL draft is not that recent, and the official XLL workgroup has not yet been constituted. What this really means is that _no_ assumptions can be made about whether XLL will be able to search by namespace-qualified names. It is _much_ more likely that search by actual element ID _will_ be allowed however. There is also talk of separating out a "real" query language since Xpointer is inadequate as a general query langauge; if that took place, namespace support might end up in queries but not xpointers. This would even make a kind of sense, since Xpointers are about rbust addressing in a _known_ document, and queries are about searching across _unknown_ documents. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://www.dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Sat Jul 25 21:29:13 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:11 2004 Subject: Publishing on XML-DEV (was Re: XCatalog proposal draft 0.1 [From Murray Altheim]) In-Reply-To: <3.0.1.16.19980725143902.36ef6566@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980725202504.29d7d11c@pop3.demon.co.uk> At 14:39 25/07/98, [Murray Altheim] wrote: [...] >>> I propose something one week, rough consensus emerges the next >>> week, and working code a week or two later: such is the Internet >>> freeware development community. Peace, it's wonderful! >> >>John, this is no criticism of the proposal itself, but 'rough consensus' >>requires that you have participation. Because this mailing list is not >>part of any recognized standards activity, there is no procedural method >>for creating standards, nor is there any obligation for either comment >>or recognition of anything that occurs on this list from its participants. Over the last few days I have been thinking about whether there should be a mechanism for the formal 'publishing' ideas and implementations from XML-DEV. There should be an element of peer-review - either by individuals, learned orgs or by 'open acclamation'. In my view, one of the most obvious forms of approval is that specs, papers, code, etc. are actually used - SAX falls into this category. It would, of course, be possible to use existing organs (anything from W3 to IETF drafts to CompSci journals) but Henry and I are keen on developing new forms of publishing. [In our own field (molecular and biological software) there are few good places for the rapid publication of widely used molecular software or specifications. Most publication tends to be considerably 'after the event' and is often not for informing people but to create a formal record - usually for 'academic currency'.] Ideas welcome. P. [wrt. Murray's comments on XCatalogs] I would support the idea of an IETF draft in this instance. (Henry and I have been through this procedure :-). In general, I'd suggest that there was an initial suggestion - possibly a draft - on XML-DEV and that from that an IETF draft emerged. Although XML-DEV has no formal standing with IETF (or anyone else) I think that the ability to point to hypermailed discussion would show that the draft had potential value and had been worked over. 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 lisarein at finetuning.com Sun Jul 26 05:12:38 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:03:11 2004 Subject: base 64 encoding References: <3.0.1.16.19980725202504.29d7d11c@pop3.demon.co.uk> Message-ID: <35BAA6C9.3AD3345@finetuning.com> Hey does anyone have the link handy for the RFC that covers base64 encoding? i need to list it as a reference for a story i'm doing. Have looked high and low for that sucker! Help! Thanks in advance, lisa rein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From carl at chage.com Sun Jul 26 05:36:16 1998 From: carl at chage.com (Carl Hage) Date: Mon Jun 7 17:03:12 2004 Subject: Javadoc comments or equivalent in XSchema In-Reply-To: <000101bdb217$3162ea80$6bf7490c@curtathome> Message-ID: <199807260336.WAA15921@rgate2.ricochet.net> > From: "Curt Arnold" > Date: Sat, 18 Jul 1998 01:42:10 -0500 > I have been using some JavaDoc-like comments in my XML-Data > definitions to automatically generate HTML documentation for the document > content. I have had my XML-Data to DTD converter modified to produce the > HTML documentation at the same time as it builds the DTD. > > Has any body else been doing anything in this area? Yes, I've done something very similar, where I use a single file containing data that defines the schema/DTD, and includes documentation in addition to the declarations used by software. Actually, I'm not using xml (xml-data) to hold the definitions, but an equivalent ASCII format more suitable for hand editing and human reading (somwhat like RFC822 headers which can be trivially reformatted into ...). The single data file is used to 1. Create the DTD and/or other definitions used by database software, defining element types/fields. 2. Create a formatted HTML file which serves as documentation on the schema. 3. Create an alternate form for documentation as 'help' containing instructions for data preparers. The generated help files contain href names for links in forms, etc. 4. Create WWW forms used for data entry and edits. Forms can show examples for fields as a guide for entry. 5. Create javascript help (or helpfile links), so instructions appear in a help window frame when clicking in a field. Unlike other approaches, all documentation and definitions specific to a schema/DTD are complete in this single source. There ares no separate (non-extracted) documentation files, misc notes in SGML comments, missing documentation, etc. common with other approaches. For enumerated data types, the schema definition data file contains the values with documentation or else references enumerated values externally (with documentation). These definitions define the contents of a pull-down select list or radio/checkbox list in a form with brief definitions/instructions or links or javascript-based help. With many other database definitions, the enumerated values are often undefined and/or undocumented. > I haven't been making a distinction between regular comments and processed > comments and have only been using @see and @example formulations. Between > minimal comments and information in the schema, it is able to do a > reasonably good job documenting how to use the schema. As with javadoc, the documentation associated with a DTD shouldn't be a bunch of arbitrary HTML (IBTWSH) pages. The documentation for an element, etc. is specific kinds of text that is assembled into various kinds of documentation, not something normally read in isolation. Javadoc uses the @ notation to identify the semantics of the documentation text so it can format the content appropriately, including href links and names. In XML, of course, would be used to mark the semantics of the documentation. In order to synthesize nicely readable HTML documentation and all the other kinds of extracted documentation such as that mentioned above, there needs to be a set of documentation elements defined. Failure to define an appropriate set of tags means that it won't be possible to create reasonable variants on types of documentation. The in xml-data is an example of the kind of semantic oriented (vs presentation) tags needed, and also an example of what is severly wrong with EDI and other typical database documentation-- incomplete inadequate documentation. The examples of the xml-data are not really descriptions, but a few words more aptly called "title". Appropriate documentation requires much more than a few words. I would be willing to write up a proposal for a set of elements useful in documentation, though it will have to be a week from now. Without thinking about it, the kinds of documentation elements I've used are something like: A short (one line) descriptive title Description: The title is a short description associated with a name or token, typically 1 line, which provides a more complete phrase than the single word name. The title might appear with the name in a table of contents, short summary reference, or 1 line comments found with declarations in source code. The title should be an alternative for the name or token not a duplicate. If no title other than the original name exists, it should be omitted rather than reentering the element or attribute name. <Prompt> An human-oriented phrase serving as an alternative for a name Description: The name used for elements, attributes, and tokens often contains abbreviations or other short notation that makes it more suited to use in software systems. A prompt provides an alternative for use in forms, questionnaires, or other presentations of the data used by humans. Language specific alternatives for the name can be supplied using the prompt. <Example> A sample data value illustrating the form and content Description: An example serves as a simple means to illustrate the meaning of an elelemt or attribute, showing how data might be formatted and the appropriate content. The example might be included in documentation or on a data entry form. If more that one example is provided, the first one supplied should be the one selected when only a single example is shown, e.g. on a data entry form. <Instructions> Detailed documentation written as preparer instructions Description: The instructions form a detailed description and documentation for an element or attribute, but written in the narritive as might appear in help documentation or instrictions for filling out a form. This would typically suffice for documentation but is written in a style oriented for data preparars rather than programmers or readers. <Description> Detailed documentation defining an element or attribute Description: The description is a set of paragraphs providing a detailed definition and other documentation for an element or attribute. This could be used with the Instructions or as an alternative to Instructions. When used with Instructions, the Description should be used to provide more detail not normally of interest to data preparers, such as interpretation within database systems. If the documentation is short, for example a phrase or sentence, then the Title should be used instead of Description. -- Other tags such as the javadoc cross-referencing @ markers are also needed. There are other tags needed that I don't have time to mention here. You might have noticed some, e.g. with my use of "Title" and "Description" in the description above. ---- In contrast to tags marking the semantics of the parts of the documentation, use of certain presentation-oriented tags, e.g. <font> can cause serious problems. IBTWSH is a good basis, but I don't think all the tags in this set is appropriate for XSC documentation. Tags like <hr> should probably be banned. Tags like <big> and <small> should be banned. The usual use is something like "<big><b>Something</b></big><br>" because some author doesn't like the way Nescape spaces <h3>Something</h3>. The usual reason for <small> is to wrap everything, because some author thinks the font's are too big when view on his 21" monitor. --- I think the goodt way to understand the requirements for documentation would be to write the XSC standard/specification in itself. I don't mean simply encode the DTD as XSC xml, I mean something equivalent to the whole set of HTML pages (or the complete xml-data document) should be represneted as XSC xml containing Doc elements. By processing the XSC-XSC, the XSC document (something similar to the current one) would be extracted including the appendix containing the DTD. The usual case of a DTD plus some arbitrary side-file documentation means documentation is not reusable, not readily accessable, and often ambiguous or imcomplete. Specifying *complete* documentation within the xml-data or xml-xsc definition provides a single referenced file for the schema and in a reusable form. With distribiuted Internet applications based on the WWW, easy access and reuse of documentation (metadata) becomes more important. XSC documentation has the potential to solve this, but only if implemented properly. -------------------------------------------------------------------------- Carl Hage C. Hage Associates <mailto:carl@chage.com> Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 <http://www.chage.com/chage/> Sunnyvale, CA 94086 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Sun Jul 26 08:04:51 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:12 2004 Subject: base 64 encoding Message-ID: <006a01bdb85a$10ffd110$2ee044c6@arcot-main> BASE64 encoding is specified as part of the MIME spec (RFC 2045 or part 1 of 5). A copy of it can be find at: http://www.oac.uci.edu/indiv/ehood/MIME/2045/rfc2045.html It is a tad chewy in terms of readability though. If you write "Dummy's Guide to BASE64", I am sure it will be a best seller. Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From simpson at polaris.net Sun Jul 26 08:17:23 1998 From: simpson at polaris.net (John E. Simpson) Date: Mon Jun 7 17:03:12 2004 Subject: base 64 encoding In-Reply-To: <006a01bdb85a$10ffd110$2ee044c6@arcot-main> Message-ID: <3.0.3.32.19980726021602.0102f870@nexus.polaris.net> At 10:55 PM 7/25/98 -0700, Don Park wrote: >BASE64 encoding is specified as part of the MIME spec (RFC 2045 or part 1 of >5). A copy of it can be find at: > > http://www.oac.uci.edu/indiv/ehood/MIME/2045/rfc2045.html Particularly, look at Sec. 6.8. 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 peter at ursus.demon.co.uk Sun Jul 26 12:22:36 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:12 2004 Subject: Javadoc comments or equivalent in XSchema In-Reply-To: <199807260336.WAA15921@rgate2.ricochet.net> References: <000101bdb217$3162ea80$6bf7490c@curtathome> Message-ID: <3.0.1.16.19980726095616.78ff7c74@pop3.demon.co.uk> At 19:55 25/07/98 -0800, Carl Hage wrote: [... much useful stuff snipped...] I'm very much in agreement with the sort of thing that Carl has been doing/is_suggesting. A good 'schema' - whatever that evolves to - must have componentised documentation, behaviour, semantics (however you interpret that word) and so forth. I've been doing the same sort of thing with JUMBO, trying to get an XML-driven application (In my own case it is driven by a hyperglossary and some of those components can make useful documentation) > >As with javadoc, the documentation associated with a DTD shouldn't be a bunch >of arbitrary HTML (IBTWSH) pages. The documentation for an element, etc. is >specific kinds of text that is assembled into various kinds of documentation, >not something normally read in isolation. Javadoc uses the @ notation to >identify the semantics of the documentation text so it can format the content >appropriately, including href links and names. I think that IBTWSH was only ever meant to be a first step towards increasing the value of schemas. It is a necessary first step - attaching human-readable document to an XSC component in a way that is impossible with DTDs. My hope is that the current XSC project will prove the concept of schemas at the simplest level and this will provide a base to build on. Then, I think, we shall benefit from an open discussion about what the next set of components may be. Of course they may come from elsewhere (XML-data, RDF, XSL, etc.) but we may need to assemble other sets - I think it's too early to say. > >I would be willing to write up a proposal for a set of elements useful in >documentation, though it will have to be a week from now. Without thinking >about it, the kinds of documentation elements I've used are something like: [... snipped...] As with all these things, anyone who make a persuasive case, has the necessary e-charisma and is capable of putting in the effort has every chance of seeing a successful XML-DEV project get off the ground :-) P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Sun Jul 26 15:08:28 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:12 2004 Subject: Javadoc comments or equivalent in XSchema Message-ID: <UPMAIL17.199807261306430446@classic.msn.com> Peter Murray-Rust wrote: >I think that IBTWSH was only ever meant to be a first step towards >increasing the value of schemas. It is a necessary first step - attaching >human-readable document to an XSC component in a way that is impossible >with DTDs. > >My hope is that the current XSC project will prove the concept of schemas >at the simplest level and this will provide a base to build on. Then, I >think, we shall benefit from an open discussion about what the next set of >components may be. Of course they may come from elsewhere (XML-data, RDF, >XSL, etc.) but we may need to assemble other sets - I think it's too early >to say. I share those hopes quite completely, as well as the feeling that using HTML tags for the documentation is a first step, and a first step only. (This is a 1.0, after all, however good we'd like it to be.) Carl Hage: >I would be willing to write up a proposal for a set of elements useful in >documentation, though it will have to be a week from now. Without thinking >about it, the kinds of documentation elements I've used are something like: Peter: >As with all these things, anyone who make a persuasive case, has the >necessary e-charisma and is capable of putting in the effort has every >chance of seeing a successful XML-DEV project get off the ground :-) I'd welcome any proposals in this direction. Chris Maden has already suggested creating a set of XSchema-specific documentation elements in addition to the IBTWSH set. I'd also be willing to include someone else documentation suggestions in the proposal, as we did IBTWSH, if additional functionality is needed. These projects are a lot of work, but it's awfully rewarding to put up new drafts. Speaking of which, I have a bunch of questions for the group that we need to resolve to complete section 2.0 of the XSchema spec. Coming shortly! 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 Sun Jul 26 18:05:00 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:12 2004 Subject: XSchema Finalization - Element Declaration Containers (1) Message-ID: <UPMAIL17.199807261603190852@classic.msn.com> As the XSchema spec moves toward some semblance of completion (Section 2.0, the key section, anyway), we have a few key issues remaining for resolution. This finalization is not _final_ - it's the last stage before we stop development and let this section of the spec rest for a couple of weeks of final review. I'd like these issues cleared up first. 1. Element Declaration Containers Last week I received a private message suggesting that we add a content model container element and an attribute declaration container to the ElementDecl declaration. (Because it came in private correspondence, I've left off the author's name. The original author is very welcome to come forward.) The current declaration is: > <!ELEMENT XSC:ElementDecl (XSC:Doc?, XSC:More?, (XSC:Ref | XSC:Choice | > XSC:Seq | XSC:Empty | XSC:Any | XSC:PCData | XSC:Mixed), XSC:AttDef*)> The new declaration would be: > <!ELEMENT XSC:ElementDecl (XSC:Doc?, XSC:More?, XSC:Model, XSC:AttList)> > <!ELEMENT XSC:Model (XSC:Ref | XSC:Choice | XSC:Seq | XSC:Empty | > XSC:Any | XSC:PCData | XSC:Mixed)> > <!ELEMENT XSC:AttList (XSC:AttDef*)> There are pluses and minuses. I'd probably add XSC:Doc and XSC:More elements to the XSC:Model and XSC:AttList elements so that folks could provide documentation for the content model as a whole and the attribute list. On the other hand, it's an extra layer of declarations that would make a hand-coder like myself crazy. I'd like to hear what people think of this, so that we can close this by the end of the week. 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 Sun Jul 26 18:05:22 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:12 2004 Subject: XSchema Finalization - Attribute Default Value as Element? (2) Message-ID: <UPMAIL17.199807261603210696@classic.msn.com> Carl Hage proposed: >Though it's not as important for AttValue to be an element, I think for >improved extensibility and the ability to attach documentation, <AttValue> >should be restored, with Doc? added, e.g. > > <!ELEMENT XSC:AttDef (XSC:Doc?, XSC:More?, XSC:EnumerationValue*, > XSC:AttValue?)> > > <!ELEMENT XSC:AttValue Doc?> I'd add XSC:More as well, of course... Right now the AttValue is an attribute, not a subelement. This is handier for typing, but less convenient for documentation. Opinions? More to come... 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 Sun Jul 26 19:56:04 1998 From: tbray at textuality.com (Tim Bray) Date: Mon Jun 7 17:03:12 2004 Subject: XSchema Finalization - Element Declaration Containers (1) Message-ID: <3.0.32.19980726105531.00c137b0@207.34.179.21> At 03:31 PM 7/26/98 UT, Simon St.Laurent wrote: >As the XSchema spec moves toward some semblance of completion (Section 2.0, >the key section, anyway), we have a few key issues remaining for resolution. One thing that would be tremendously helpful for those of us watching this work at a distance would be a URL where we could go and get *all* of XSchema. I try to read it every couple of weeks just to stay in touch. -Tim xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From SimonStL at classic.msn.com Mon Jul 27 01:01:50 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:12 2004 Subject: Publishing on XML-DEV (was Re: XCatalog proposal draft 0.1 [From Murray Altheim]) Message-ID: <UPMAIL17.199807262300130021@classic.msn.com> Peter Murray-Rust quoted: >At 14:39 25/07/98, [Murray Altheim] wrote: >[...] >>> I propose something one week, rough consensus emerges the next >>> week, and working code a week or two later: such is the Internet >>> freeware development community. Peace, it's wonderful! >> >>John, this is no criticism of the proposal itself, but 'rough consensus' >>requires that you have participation. Because this mailing list is not >>part of any recognized standards activity, there is no procedural method >>for creating standards, nor is there any obligation for either comment >>or recognition of anything that occurs on this list from its participants. XML-Dev has been my introduction to standards without a net, and I have to say I've found the work here both exciting and useful. Standards bodies are useful organizations; among other things, they often let the people writing the standards collect a paycheck for the time they spend on the standards. It does make it (much) easier, but it's not required. There "is no procedural method for creating standards, nor is there any obligation for either comment or recognition of anything that occurs on this list from its participants." Precisely, and this is both the good and the bad. I don't get weird random comments on XSchema from people doing their homework who just skimmed through something because they had to. (I get some weird random comments, but at least they are from people who are interested in the first place.) Some of the best comments about XSchema have come from people who arrived late in the process, who read something at the beginning and only caught up a few weeks later, and people who think it's a genuinely bad idea in the first place. I watched the SAX process mostly as an interested bystander, and the success of that development process made it possible for me to consider using XML-Dev as a forum for creating XSchema. The roaring success of SAX (in my mind, at least) is a testament to what is possible when a community, rather than a committee, is involved in the standards-building process. While there is less focus, there is also more diversity; while there is a drive to keep momentum, there is less industry politics to drive standards in a particular direction. If XSchema has even a fraction of the success SAX has found, I'll be very happy. If it doesn't, I'll at least know we contributed to the discussion in a very open and inclusive setting. Peter writes: >Over the last few days I have been thinking about whether there should be a >mechanism for the formal 'publishing' ideas and implementations from >XML-DEV. There should be an element of peer-review - either by individuals, >learned orgs or by 'open acclamation'. In my view, one of the most obvious >forms of approval is that specs, papers, code, etc. are actually used - SAX >falls into this category. In the end, I think use is what really matters, and is the highest form of 'open acclamation.' XML-Dev is an excellent resource for peer review - many of the readers on this list are both capable of and interested in reviewing new ideas and specifications. XML-Dev's discussion process contributed to the usefulness of SAX, and I know XSchema has benefited from it as well. A formal publishing mechanism would be good; maybe an XML-Dev site of some kind? Peter writes re: XCatalogs >I would support the idea of an IETF >draft in this instance. (Henry and I have been through this procedure :-). >In general, I'd suggest that there was an initial suggestion - possibly a >draft - on XML-DEV and that from that an IETF draft emerged. Although >XML-DEV has no formal standing with IETF (or anyone else) I think that the >ability to point to hypermailed discussion would show that the draft had >potential value and had been worked over. I think taking these to the IETF would be a great idea. Has anyone considered doing the same (or submitting a note to the W3C) with SAX? 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 srn at techno.com Mon Jul 27 02:02:43 1998 From: srn at techno.com (Steven R. Newcomb) Date: Mon Jun 7 17:03:12 2004 Subject: Metastructures 1998 Message-ID: <199807270000.TAA06125@bruno.techno.com> The Tutorial and Conference programs for the GCA Metastructures 1998 Conference (Montreal, August 17-19) can be viewed at http://www.gca.org/conf/meta98/ Very briefly: August 17: Tutorials on Topic Maps, Architectural Forms, Formatting with DSSSL and XSL, HyTime, XLL/XLink, XML, SMIL, adaptive hypermedia tools, and groves. August 18-19: Metastructures 1998. Metastructures for product/process information interchange, queries, schemas, e-commerce, hypermedia, metadata, knowledge bases, web summaries, etc. will be discussed by 22 speakers from 7 countries. August 20-21: XML Developers' Conference. -Steve -- Steven R. Newcomb, President, TechnoTeacher, Inc. srn@techno.com http://www.techno.com ftp.techno.com voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137) fax +1 972 994 0087 (at ISOGEN: +1 214 953 3152) 3615 Tanner Lane Richardson, Texas 75082-2618 USA xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From mika.kekkonen at vtt.fi Mon Jul 27 10:32:10 1998 From: mika.kekkonen at vtt.fi (mika.kekkonen@vtt.fi) Date: Mon Jun 7 17:03:12 2004 Subject: IMB xml for java parser and printing entities Message-ID: <3.0.32.19980727112750.00915360@vttmail.vtt.fi> How I can print my xml document with ibm parser so that my enties are still in form &horse;. I have following horse.xml file: <?xml version="1.0"?> <!DOCTYPE MODULE SYSTEM "horse.dtd"> <MODULE> &horse; </MODULE> and horse.dtd is <!ELEMENT MODULE (#PCDATA)> <!ENTITY horse "horsepower"> My MyTest java class (code is from guide.html file which comes with parser documentation) is class MyTest { public static void main(String args[]) throws Exception { String filename = new String(args[0]); InputStream is = new FileInputStream(filename); TXDocument doc = new com.ibm.xml.parser.Parser(filename).readStream(is); String charset = "ISO-8859-1"; // MIME charset name String jencode = MIME2Java.convert(charset); PrintWriter pw = new PrintWriter(new OutputStreamWriter(System.out, jencode)); doc.setEncoding(charset); doc.print(pw, jencode); } } When I run MyTest class with file horse.xml I got following output: H:\java\classes>java MyTest horse.xml <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE MODULE SYSTEM "horse.dtd" > <MODULE> horsepower </MODULE> How can I have &horse; instead of horsepower in my output???? Thanks for any answers. Mika xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Mon Jul 27 11:18:33 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:12 2004 Subject: SAX and namespaces: an implementation Message-ID: <199807270916.LAA12055@berlin.dvs1.tu-darmstadt.de> > Three new classes are involved: org.xml.sax.ParserFilter, > org.xml.sax.helpers.PseudoAttributeList, and > org.xml.sax.helpers.NamespaceFilter. Is there a URL for this? I've got immediate uses for ParserFilter and PseudoAttributeList and possibly for NamespaceFilter. -- 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 tms at ansa.co.uk Mon Jul 27 12:02:43 1998 From: tms at ansa.co.uk (Toby Speight) Date: Mon Jun 7 17:03:12 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: John Cowan's message of "Fri, 24 Jul 1998 16:36:43 -0400" References: <199807201132.HAA00572@unready.megginson.com> <u7m18pqsz.fsf@delivery.ansa.co.uk> <35B8F05B.7ABBD816@locke.ccil.org> Message-ID: <ulnpffw4n.fsf@delivery.ansa.co.uk> Toby> Toby M. Speight <URL:mailto:tms@ansa.co.uk> David> David Megginson <URL:mailto:david@megginson.com> John> John Cowan <URL:mailto:cowan@locke.ccil.org> => In article <199807201132.HAA00572@unready.megginson.com>, David => wrote: David> 2. Use the current interface, but allow namespace-aware SAX David> processors to prepend namespace URIs to element type and David> attribute names, as in David> David> startElement("urn:www.megginson.com:doc", ...) David> endElement("urn:www.megginson.com:doc", ...) => In article <u7m18pqsz.fsf@delivery.ansa.co.uk>, Toby wrote: Toby> I don't particularly like (2) above, since it means that different Toby> SAX parsers may return different values for the same document. => In article <35B8F05B.7ABBD816@locke.ccil.org>, John wrote: John> I don't understand this comment. My worry is that if the new interface for namespace-processed elements is the same as that for SAX 1.0, then either kind of parser could be used in a given program. But the two types will not return the same information through the interface, even though there is no change to the function call. This violates the principle of interfaces and programming-to-contract. OTOH, if namespace processing is an extra layer slotted in, that has to be explicitly enabled with something like parser.setNamespaceProcessor(myNameHandler); or namespaceProcessor.setParser(myParser); then there is no change on the namespace-unaware application, and if a namespace-aware application is given a namespace-unaware parser, this will be discovered when it tries to enable namespace support. -- xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From kent at trl.ibm.co.jp Mon Jul 27 13:55:50 1998 From: kent at trl.ibm.co.jp (TAMURA Kent) Date: Mon Jun 7 17:03:12 2004 Subject: IMB xml for java parser and printing entities In-Reply-To: mika.kekkonen@vtt.fi's message of "Mon, 27 Jul 1998 11:27:59 +0300" <3.0.32.19980727112750.00915360@vttmail.vtt.fi> References: <3.0.32.19980727112750.00915360@vttmail.vtt.fi> Message-ID: <199807271153.UAA35467@ns.trl.ibm.com> > How I can print my xml document with ibm parser so that my enties are still > in form &horse;. I have following horse.xml file: : : > How can I have &horse; instead of horsepower in my output???? *Current* XML4J expands all entity references and removes information about them. A tree produced by Parser#readStream() never generates your entity referecens. To generate eneity references, add com.ibm.xml.parser.GeneralEntity instances to a tree and print it. -- TAMURA, Kent @ Tokyo Research Laboratory, IBM Japan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From larsga at ifi.uio.no Mon Jul 27 15:04:34 1998 From: larsga at ifi.uio.no (Lars Marius Garshol) Date: Mon Jun 7 17:03:12 2004 Subject: Conflict resolution in catalog files Message-ID: <3.0.1.32.19980727150208.007021f0@ifi.uio.no> I've now researched how conflict resolution works in SGML Open Catalogs and want to propose a new wording for the XCatalog proposal section 7 based on this. The CATALOG extension to the catalog file format means that TR 9401:1997 can't be followed directly, since it does not have this entry. Instead, the handling of multiple catalog files is based on the (extremely terse) description of how nsgmls handles this. This is the proposed wording: --- BEGIN PROPOSAL 7. Conflict resolution When more than one catalog entry applies to an entity, the conflict can be resolved by using the entry that is comes out first after the entries have been sorted in the order specified below. Entries are sorted by (in this order): 1) By catalog file, in the order the catalog files were processed 2) By the entry type (in this order): a) SYSTEM (Remap) b) PUBLIC (Map) c) DELEGATE (Delegate) 3) The order in which the entries appeared in the catalog file --- END PROPOSAL (NB: The SYSTEM/Remap entry is not present in the original proposal, but I think it should be included. The functionality it provides was part of what the PubIdResolver interface of SAX was supposed to enable.) The reason I propose this is that the new wording is more concise, and, I think, easier to understand. Another benefit is that this wording is compatible with both TR 9401:1997 and the way nsgmls handles conflict resolution. (Provided I understood James Clarks explanation correctly.) --Lars M. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jul 27 15:39:05 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:12 2004 Subject: Javadoc comments or equivalent in XSchema References: <199807260336.WAA15921@rgate2.ricochet.net> Message-ID: <35BC82DE.BC83B890@locke.ccil.org> Carl Hage wrote: > As with javadoc, the documentation associated with a DTD shouldn't be a bunch > of arbitrary HTML (IBTWSH) pages. And I'm all for that. The point of IBTWSH is to provide just enough support so that the non-predictable part of the documentation can exploit rich text too. Javadoc does this haphazard, not documenting which HTML tags are allowed and which will make a hash of the document structure. > The documentation for an element, etc. is > specific kinds of text that is assembled into various kinds of documentation, > not something normally read in isolation. Javadoc uses the @ notation to > identify the semantics of the documentation text so it can format the content > appropriately, including href links and names. The IBTWSH analog of the Javadoc "@xxx" is the non-HTML tag "XML", which has a content model of ANY, thus allowing random embedded stuff which a Javadoc-type processor will of course need to interpret and turn into smooth and flowing HTML. > In contrast to tags marking the semantics of the parts of the documentation, > use of certain presentation-oriented tags, e.g. <font> can cause serious > problems. IBTWSH no longer has FONT. > IBTWSH is a good basis, but I don't think all the tags in this set > is appropriate for XSC documentation. Tags like <hr> should probably be > banned. HR is not valid in XSchema documentation, because it is not part of the parameter entity "horiz.model". > Tags like <big> and <small> should be banned. The usual use is > something like "<big><b>Something</b></big><br>" because some author doesn't > like the way Nescape spaces <h3>Something</h3>. The usual reason for <small> > is to wrap everything, because some author thinks the fonts are too big when > view on his 21" monitor. Nevertheless, there is a valid use, namely to mark <big>important</big> and <small>unimportant</small> text respectively. The concept of "fine print" is really a structural one, like that of "emphatic text", and it's a pity that HTML 4.0 doesn't have a structural tag for it, but it doesn't and too late to complain now. -- 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 Jul 27 15:43:04 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:13 2004 Subject: XSchema Finalization - Element Declaration Containers (1) References: <UPMAIL17.199807261603190852@classic.msn.com> Message-ID: <35BC83D2.22B0DE4E@locke.ccil.org> Simon St.Laurent scripsit: > 1. Element Declaration Containers Openly I say now what privately I said before: I'm against it, > On the other hand, it's an extra layer of declarations that would make a > hand-coder like myself crazy. Just so. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maki at inac.co.jp Mon Jul 27 15:57:48 1998 From: maki at inac.co.jp (TAKAHASHI Masayoshi) Date: Mon Jun 7 17:03:13 2004 Subject: Expat for Japanese encodings Message-ID: <199807271357.WAA09986@mx.inac.co.jp> ** Expat for Japanese Encodings ** This is an UNOFFICIAL version of expat to handle Japanese encodings, Shift_JIS and EUC-JP. If you deal with XML document in Japanese with expat, please try to use and test it. URL is: http://www.inac.co.jp/~maki/xml/expat.html Thanks, TAKAHASHI Masayoshi (maki@inac.co.jp) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Mon Jul 27 16:39:07 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:13 2004 Subject: XCatalog proposal draft 0.1 References: <199807242227.PAA00967@mehitabel.eng.sun.com> Message-ID: <35BC90CC.4B3820F0@locke.ccil.org> Murray Altheim wrote: > John, this is no criticism of the proposal itself, but 'rough consensus' > requires that you have participation. Because this mailing list is not > part of any recognized standards activity, there is no procedural method > for creating standards, nor is there any obligation for either comment > or recognition of anything that occurs on this list from its participants. My remarks about "rough consensus and working code" in a week or two were meant as a mild satire on how long-drawn-out the IETF process (which purports to adhere to that meta-standard) has become. XML-Dev work, as Peter says, is standards development without a net, though whether he means a tennis net or an acrobat's net, he doesn't say. > > The *draft* number is 0.1, but the standard will be 1.0 when it is > > a standard. > > Again, discussion of standardization and version numbers is rather out > of place, unless I'm mistaken and this has already been proposed to a > standards body. If so, my apologies. It hasn't. But ehat is important about standards IMHO is not who promulgates them, but whether they gain wide acceptance. SAX is a paradigm in this respect. > An XML 1.0 parser that does anything at all with catalogs is going beyond > the spec, but is not out of compliance. The question was open. I would > recommend any declaration that allows for a publicId should allow for > catalog resolution. Yes, but limited to providing resolution of the PublicId into a SystemId. > Because the XCatalog proposal follows Socats, you > should simply rely on the features of Socats as appropriate to XML and > not concern yourself with existing implementation support. IOW, you can > rely on whatever showing up in a final draft of the Socat proposal as > being the expected set of resolution features. I'm sorry, but I don't follow these two sentences. Is 9401:1997 in imminent revision? > All of this in the end > will need to be hashed over by a lot of people. I would suspect that > if ENTITY and NOTATION are in 9401, they should be XCatalog, otherwise > transformation from a Socat format to XCatalog would result in loss of > information. > > I'd suggest adding: > > Notation ::= "NOTATION" WS Name WS SystemLiteral > > Entity ::= "ENTITY" WS Name WS SystemLiteral > > or at least discussing things with the Socat editors to garner what will > be in the final. (Last I heard this was still in progress.) This is a fundamental difference between XML and SGML. In XML, there is no natural concept of a "storage object identifier" other than a URI, and it is prescribed that SystemIds are URIs. There is no need to provide mechanisms to map URIs into other URIs within the XML world, because the URI world already has such mechanisms, like URN resolution and HTTP permanent redirection. Any such Notation and Entity declarations would override the fixed interpretation of XML SystemIds and DTD declarations, which seems to me unnecessary and unacceptable. > As for searching, it would be better if you simply referenced the Socat > spec as much as possible. Behaviour should be identical as much as possible. I believe that I have restated it. After all, by that token the XML spec could have just been: See ISO 8859 with the following exceptions and limitations (append James Clark's Note here). But it wasn't, and for good and sufficient reason. 9401 contains many features irrelevant to XML. > As regards name resolution, I'm not aware that XML should be substantially > different than SGML. If the features exist, it should be the same, IMO. XML has a different and more restrictive concept set. > > > Also, have you verified that this section is 100% compatible with > > > SO Catalogs? IMHO, it should be, so that one can implement a general > > > catalog engine that is independent of the syntax. > > This was the point I made in a previous paragraph. I *intend* the algorithm to be the same, and I *believe* it to be the same, modulo the issue of SystemIds vs. storage identifiers, but *verification*? The 9401 algorithm is by no means expressed in a formalism that would lend itself to verification, and IMHO it is not particularly clear even as prose. You ask more than can reasonably be provided. > > There are a few problems. XCatalogs as specified are case-sensitive > > whereas OASIS TR 9401:1997 is not, but all actual catalog examples > > use uppercase only AFAIK. Also, I have imposed a slightly more > > restrictive comment syntax, requiring whitespace both before and > > after all comments, except comments at BOF or EOF. This too > > seems to conform to actual practice. (Note that the formal grammar > > of TR 9401:1997 is *not* authoritative about comments: 8879 is.) > [comments on search algorythms elided...] > > Remember that catalog support, the individual specs for URIs, URNs, URLs, > etc. are outside of the scope of XML. The only part of XCatalogs that > should be case sensitive is the markup syntax itself. Catalog content > is like any other XML attribute content -- free of restraints other than > those imposed by whatever attribute type is declared. Case is not > part of this for CDATA. I'm talking about the Socat-compatible syntax. 9401 says that Socat keywords are case-blind, but XCatalog makes them case-sensitive and upper-case, in conformity with the usual XML rules for stuff taken directly from SGML. All examples of Socats known to me, including the examples in the spec, use upper-case keywords, so this seems a small incompatibility. > > 1. Introduction > > If this is to go ahead as a formal proposal, I surmise you will be > including definitions (eg., 'Socat', etc.) and a list of resources. Probably. > > 2. Example > > Why in your example is the original comment rendered as element > content? Was this intentional? In my implementation, I merely > used XML comments, as '-- text --' translates to '<!-- text -->' > in XML. Because XML processors are free to strip comments (clause 2.5), so that any application that wishes to process the documentation (for example, to pretty-print catalogs) may not be able to see documentation in the form of XML comments. A similar rationale applies to the XSC:Doc element. > > Other ::= Name (WS Name)? (WS SystemLiteral)* > > I'm looking over the 9401 TR and noting that you're mirroring the syntax > of most of that document. I understand the rationale in not supporting > some of the more arcane or inapplicable features therein, but I'm not sure > that the expression for 'Other' entries will suffice. Given that catalogs are > often (in practice) delimited by line breaks, If so, such software is noncompliant to 9401:1997. > and 'Other' allows for optional > Names and SystemLiterals, how will a Socat-to-XCatalog parser/translator know > it has reached the end of a an 'Other' entry given that it is undefined? Not so. See the 9401:1997 grammar, the rule named "other information". I am tracking this rule fairly exactly, modulo my marginally different treatment of comments. The Other rule says: a keyword (Name syntax), an optional subkeyword (Name syntax), and optional quoted strings. So the next non-quoted-string will be the beginning of the next entry. This is true for both my version and 9401's, and shows that 9401 was *designed* to allow Socat processors to skip information they do not understand. > Remember that catalog files currently enjoy support only insofar as they > are 'standardized' within the industry. If someone wants to use the > current Socat syntax in their own custom way, this obviously would have > no wider use than their proprietary software. This requires no modication > to the Socat spec, and I would strongly urge that the XCatalog proposal > not be polluted with featuritis. If someone wants to use an XCatalog > element in their own application, there would be no required change to > the XCatalog spec, and indeed, to do so would require implementors to > support this feature. The point is that the instance syntax currently requires a specific root element, XCatalog. I am proposing (in draft 0.2) that this be dropped, so that XCatalog instance recognition is done by searching a random document for the appropriate element GIs; any XML instance is an XCatalog iff it contains the right elements. (Or even if it doesn't; that just makes it an empty XCatalog.) > I'd remove the version number, write it up as an IETF > Internet Draft and post it. Which version number, the draft number, or the Version attribute of the XCatalog element (now on my hit list anyway)? > If I saw this as an IETF Internet Draft, I'd > be happy to post a notice to XML-SIG (and I think I could get Jon to > post it to the WG) so you'd at least get the attention of those > interested so they could comment on this in the IETF. I'll try to make this happen. > As part of a > discussion on XML-DEV, it has the same priority for me (and probably > others) as the XSchema proposal: a good, necessary feature, but not part > of an extended activity that I can justify easily to my boss given it > has no product. Point taken. -- 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 Jul 27 16:46:00 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:13 2004 Subject: SAX and namespaces: an implementation References: <199807270916.LAA12055@berlin.dvs1.tu-darmstadt.de> Message-ID: <35BC9288.9AF0F5F0@locke.ccil.org> Ron Bourret wrote: > > Three new classes are involved: org.xml.sax.ParserFilter, > > org.xml.sax.helpers.PseudoAttributeList, and > > org.xml.sax.helpers.NamespaceFilter. > > Is there a URL for this? I've got immediate uses for ParserFilter and > PseudoAttributeList and possibly for NamespaceFilter. Yes! The source code is now at http://www.ccil.org/~cowan/XML/ns.jar. It is *very* alpha code, which is why I am not even providing classfiles, since I don't want anybody to think that this is in any way ready-to-go. In particular, universal names are constructed each time on the fly and not memoized properly; also the javadoc comments are not all there yet. Please critique! -- 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 Mon Jul 27 16:51:07 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:03:13 2004 Subject: MIME spec roundup References: <006a01bdb85a$10ffd110$2ee044c6@arcot-main> Message-ID: <35BC9C04.F6BFCAE7@finetuning.com> Hi all! Thanks for all the great MIME/base64 encoding leads. I believe there were five in all and I've got them all on one page now for convenience -- let me know if I've missed anything...thanks! http://www.finetuning.com/mime.html And check out the story today on xml.com. see ya! lisa rein http://www.finetuning.com/collect.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 Mon Jul 27 16:57:58 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:13 2004 Subject: [Q] How should SAX support Namespaces? References: <199807201132.HAA00572@unready.megginson.com> <u7m18pqsz.fsf@delivery.ansa.co.uk> <35B8F05B.7ABBD816@locke.ccil.org> <ulnpffw4n.fsf@delivery.ansa.co.uk> Message-ID: <35BC9555.6163BEE1@locke.ccil.org> Toby Speight scripsit: > My worry is that if the new interface for namespace-processed elements > is the same as that for SAX 1.0, then either kind of parser could be > used in a given program. But the two types will not return the same > information through the interface, even though there is no change to > the function call. This violates the principle of interfaces and > programming-to-contract. Ah. In my current design, the namespace layer cannot *quite* be dropped in, because the setParser call (identical to your second example below) must be done somewhere. Once that is done, though, other modules need no changes and will get universal or application-specific names according to their needs. > OTOH, if namespace processing is an extra layer slotted in, that has > to be explicitly enabled with something like > > parser.setNamespaceProcessor(myNameHandler); > > or > > namespaceProcessor.setParser(myParser); > > then there is no change on the namespace-unaware application, and if a > namespace-aware application is given a namespace-unaware parser, this > will be discovered when it tries to enable namespace support. In effect, yes. In my model you can use any parser below the namespace layer (including in principle another namespace layer, though that is pointless; more realistically a layer of some other kind), and so parsers proper can remain ns-unaware. -- 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 Jul 27 17:57:10 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:13 2004 Subject: Conflict resolution in catalog files References: <3.0.1.32.19980727150208.007021f0@ifi.uio.no> Message-ID: <35BCA335.32204710@locke.ccil.org> Lars Marius Garshol wrote: > I've now researched how conflict resolution works in SGML Open > Catalogs and want to propose a new wording for the XCatalog proposal > section 7 based on this. I have no problem with this in principle. > The CATALOG extension to the catalog file > format means that TR 9401:1997 can't be followed directly, since it > does not have this entry. How's that? This is no extension: it is documented right in 9401:1997. (Unfortunately, there are neither clause numbers nor HTML anchors in that document, but search for the string "The CATALOG entry can be used".) > 7. Conflict resolution > > When more than one catalog entry applies to an entity, the conflict > can be resolved by using the entry that is comes out first after the > entries have been sorted in the order specified below. > > Entries are sorted by (in this order): > > 1) By catalog file, in the order the catalog files were processed > 2) By the entry type (in this order): > a) SYSTEM (Remap) > b) PUBLIC (Map) > c) DELEGATE (Delegate) > 3) The order in which the entries appeared in the catalog file AFAIK the only difference (modulo System) is that Maps are always processed before Delegates within a single catalog even if the Maps physically follow. This is probably a good rule. > (NB: The SYSTEM/Remap entry is not present in the original proposal, > but I think it should be included. The functionality it provides was > part of what the PubIdResolver interface of SAX was supposed to > enable.) I still have problems with this, as it violates referential transparency. It means that the processor of a document can change the content of the document based on a catalog entry, and independent of the author's declared intent. > The reason I propose this is that the new wording is more concise, > and, I think, easier to understand. I take your point, but it is incomplete, specifically in the matter of what to do when a Delegate entry is accepted: discard the rest of the current catalog *and* the entire queue, and start over. -- 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 mika.kekkonen at vtt.fi Mon Jul 27 17:59:28 1998 From: mika.kekkonen at vtt.fi (mika.kekkonen@vtt.fi) Date: Mon Jun 7 17:03:13 2004 Subject: IMB xml for java parser and printing entities Message-ID: <3.0.32.19980727185709.0095a100@vttmail.vtt.fi> At 20:53 27.7.1998 +0900, TAMURA Kent wrote: >> How I can print my xml document with ibm parser so that my enties are still >> in form &horse;. I have following horse.xml file: > : > : >> How can I have &horse; instead of horsepower in my output???? > >*Current* XML4J expands all entity references and removes >information about them. A tree produced by Parser#readStream() >never generates your entity referecens. > >To generate eneity references, add com.ibm.xml.parser.GeneralEntity >instances to a tree and print it. > How I can add com.ibm.xml.parser.GeneralReference (I suppose last word is Reference not Entity) instance to the tree? Should I use com.ibm.xml.parser.ReferenceHandler? It would be nice to see detailed instructions or sample code about this subject. Thanks for any answers. Mika >-- >TAMURA, Kent @ Tokyo Research Laboratory, IBM Japan > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 27 18:13:44 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:13 2004 Subject: SAX namespace implementation: please re-download Message-ID: <35BCA712.98F2F5C0@locke.ccil.org> I uploaded in ASCII mode by mistake (a problem with my FTP tool, which doesn't recognize "jar" as a binary extension). Please re-download from: http://www.ccil.org/~cowan/XML/ns.jar -- 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 Alice.Portillo at PSS.Boeing.com Mon Jul 27 20:19:44 1998 From: Alice.Portillo at PSS.Boeing.com (Portillo, Christina) Date: Mon Jun 7 17:03:13 2004 Subject: Naming Rules Message-ID: <F1B781B35CA8D011B10F00805FEA27F502236D6C@xch-rtn-01.ca.boeing.com> I need some clarification on the differences in the naming rules defined in the XML SGML Declaration and the Naming Rules defined in XML Part 1 Names and Tokens. My understanding of the XML SGML Declaration Naming Rules as defined in the Concrete Syntax are: Naming Rules Identifies the rules used to identify name character and name start characters. It also identifies case rules. Name Start XML accepts the NMSTRT default (any lower (97-122) or upper case (65-90) alpha character) but extends this to included character from all the other languages defined in ISO 10646. It has specifically defined which additional characters are valid to use as LCNMSTRT and UCNMSTRT characters by use of ENR NAMESTRT. NAMESTRT means that each character identified by the extended naming value has the same effect as a character appearing in both UCNMSTRT and LCNMSTRT. The XML SGML Declaration has defined the range of characters which have an upper and lower case. Within this set XML has defined the underscore and colon as being an additional NAMESTRT characters. Name Character XML accepts the NMCHAR default (any lower (97-122) or upper case (65-90) alpha character) but extends this to included character from all the other languages defined in ISO 10646. It has specifically defined which additional characters are valid to use as LCNMCHAR and UCNMCHAR characters by use of ENR NAMECHAR. NAMECHAR means that each character identified by the extended naming value (if any) has the same effect as a character appearing in both UCNMCHAR and LCNMCHAR. The XML SGML Declaration has defined the range of characters which have an upper and lower case. Within this set XML has defined the dash and full stop as being an additional NAMECHAR characters. The XML Part 1 Names and Tokens indicates the following: [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender [5] Name ::= (Letter | '_' | ':') (NameChar)* [6] Names ::= Name (S Name)* [7] Nmtoken ::= (NameChar)+ [8] Nmtokens ::= Nmtoken (S Nmtoken)* My understanding of the Name restricts the 1st character position to a letter or a underscore or colon which is in sync with the SGML Declaration. But the NameChar allows underscores and colons in the remaining character positions which is at variance with the naming rules defined by the SGML Declaration. Can you clarify this for me? Christina Portillo Product Definition and Image Technology The Boeing Company Phone: 425.237.3351 PO Box 3707 M/S 6H-AF Fax: 425.237.3428 Seattle, WA 98124-2207 christina.portillo@boeing.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Mon Jul 27 20:34:53 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:03:13 2004 Subject: Naming Rules In-Reply-To: <F1B781B35CA8D011B10F00805FEA27F502236D6C@xch-rtn-01.ca.boeing.com> (Alice.Portillo@PSS.Boeing.com) Message-ID: <199807271832.OAA19109@ruby.ora.com> [Christina Portillo] > I need some clarification on the differences in the naming rules > defined in the XML SGML Declaration and the Naming Rules defined in > XML Part 1 Names and Tokens. [...] > My understanding of the Name restricts the 1st character position to > a letter or a underscore or colon which is in sync with the SGML > Declaration. But the NameChar allows underscores and colons in the > remaining character positions which is at variance with the naming > rules defined by the SGML Declaration. > > Can you clarify this for me? Characters defined as NAMESTRT, LCNMSTRT, or UCNMSTRT are usable as name characters; that is, name start characters are a strict subset of name characters, and so definition as the former implies definition as the latter. The relevant productions from ISO 8879 are: [52] name character = name start character | Digit | LCNMCHAR | UCNMCHAR [53] name start character = LC Letter | UC Letter | LCNMSTRT | UCNMSTRT (See <URL:http://www.oreilly.com/people/staff/crism/sgmldefs.html>.) Note that this information is not necessary to understand the XML Recommendation; the name productions in REC-XML are correct as they stand. -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 Jul 27 20:59:23 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:13 2004 Subject: Naming Rules References: <F1B781B35CA8D011B10F00805FEA27F502236D6C@xch-rtn-01.ca.boeing.com> Message-ID: <35BCCDD1.A3936F0E@locke.ccil.org> Portillo, Christina wrote: > I need some clarification on the differences in the naming rules defined > in the XML SGML Declaration and the Naming Rules defined in XML Part 1 > Names and Tokens. It's important to understand that the SGML declaration for XML is not normative. In case of conflict, the XML specification rules. > My understanding of the Name restricts the 1st character position to a > letter or a underscore or colon which is in sync with the SGML > Declaration. But the NameChar allows underscores and colons in the > remaining character positions which is at variance with the naming rules > defined by the SGML Declaration. While I am not an SGML mavin, it seems clear that everything declared as a NAMESTRT character is also valid as a NAMECHAR character. The characters explicitly listed in NAMECHAR are the non-ASCII digits, combining marks, and modifier letters, plus the FULL STOP and HYPHEN-MINUS. -- 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 Jul 27 21:30:27 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:13 2004 Subject: XCatalog proposal draft 0.1 References: <199807271906.MAA05231@mehitabel.eng.sun.com> Message-ID: <35BCD513.F1CBE8D0@locke.ccil.org> Murray Altheim scripsit: > You speak of an XML world as if it existed as a fixed entity. No, but one part of it is fixed: the spec. > [I]f people wish to build > large systems based on XML, I'm suggesting we look at the reasons why 9401 > has its feature set and use this to inform our design. As far as I can see, the reason is that SGML doesn't give any definite meaning to SystemIds, and some kind of outside support is needed to map them to filenames or other things that programs understand. XML *does* define the meaning of SystemIds, by reference to various URI documentation. > There very well > may be a need for URI-to-URI mapping in some systems. I'm simply > advocating that before we attempt to 'standardize' XML catalog > resolution, we're going to need a lot more input, hence my suggestion > of an IETF Internet Draft. Right. Since both the Socat and the instance format are highly extensible (as explained in my earlier posting), there is no problem with standardizing only some features and adding others later. > As I stated in my earlier message, my posting is not meant to be critical > (other than bring up technical points) of the XCatalog proposal. I think > XML desperately needs catalog (ie., name resolution) support, both because > I am against hardwiring locations in documents, And I am afraid of preempting URN resolution mechanisms, because if you don't like hardwired URLs, then URNs are probably what you want. In utter truth, PublicIds are just another kind of URN, but they are already defined and URNs are not. I want to start creating a PublicId infrastructure analogous to the DNS infrastructure, but piggybacked on existing HTTP servers. A model implementation of a PublicId to SystemId resolver would go a long way to making such a thing easy for people to provide. Publish a few XML documents, add a few lines to the catalog. To my mind, local remapping facilities are secondary to that goal. In fact, in a regime of public catalogs, they would be downright undesirable: consider the effects of a catalog that remaps somebody else's URLs to your own site. That would subvert the current (moderately strong) assurance that "http://www.sun.com/..." *semper ubique et ab omnibus* refers to a page on Sun's web site. > and because without it, > XML may end up being simply an output format for existing SGML systems. I don't understand this point. There are surely already many XML formats that are by no means derived from SGML system output. > You seem critical of the work of standards bodies as being too slow. "Slow" and "too slow" are surely not synonymous. > I think that this might also be proposed as a work item for OASIS, and > I'll poke around to see if this might already be in anyone's neural fibre. Thank you. -- 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 dan at intervista.com Mon Jul 27 22:25:13 1998 From: dan at intervista.com (Dan Ancona) Date: Mon Jun 7 17:03:13 2004 Subject: [RFC] Whitepaper on Visual XML Message-ID: <3.0.32.19980727133326.009da4c0@mail.intervista.com> A draft of a whitepaper that I've written called "Visual XML: Authoring, Publishing and Viewing Structured Information" is now available on the VRML Consortium's website: http://www.vrml.org/WorkingGroups/dbwork/ancona/home.html I'm mostly thinking about the rendering of arbitrary XML files in VRML rather than HTML. I have some experience with SGML, but I'm definitely coming at this from the VRML side of things so I do have some unresolved issues regarding how this work might fit in with stylesheets, the DOM, XPointer & XLink, and XML's design goals in general. Any comments regarding those areas are especially welcome. I think the most interesting possibilities lie in what 3D rendering might mean for XLink, so if you're the type who likes to skip to the juicy parts (like me), you might want to check out that part first. :) And please feel free to forward this announcement to other lists as appropriate (it's just been posted on www-vrml, but that's it so far). Cheers, Dan __________________________________________________________ Dan Ancona "engage!" Tech Support, Evangelism and Cookery Intervista Software xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Mon Jul 27 22:26:39 1998 From: paul at arbortext.com (Paul Grosso) Date: Mon Jun 7 17:03:13 2004 Subject: XCatalog proposal draft 0.1 Message-ID: <98Jul27.161639edt.26892@thicket.arbortext.com> At 15:29 1998 07 27 -0400, John Cowan wrote: >Murray Altheim scripsit: >> You speak of an XML world as if it existed as a fixed entity. > >No, but one part of it is fixed: the spec. > >> [I]f people wish to build >> large systems based on XML, I'm suggesting we look at the reasons why 9401 >> has its feature set and use this to inform our design. > >As far as I can see, the reason is that SGML doesn't give any >definite meaning to SystemIds, and some kind of outside support >is needed to map them to filenames or other things that >programs understand. XML *does* define the meaning of SystemIds, >by reference to various URI documentation. System ids have been pretty obvious in most cases for decades. While it is true that 8879 allows system ids to be almost anything, all the SGML systems I've seen figure a regular looking system id is a file name, and that works fine. In fact, it wasn't until the third version of the SGML Open Catalog TR9401 that we added mapping of system ids. The real reason for the SGML Open Catalog was because 8879 did not define a way to map public ids into much of anything. And neither does 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 donpark at quake.net Tue Jul 28 00:17:56 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:14 2004 Subject: Fw: First Draft of XLF Spec Released Message-ID: <007501bdb9ab$27e83f00$2ee044c6@arcot-main> It seems that the XLF mailing list has been having problems distributing messages and responding to commands for a while. I did not realize this until today. Here is the announcement which I posted a two days ago. If you are a subscriber of XLF mailing list and have NOT received this message before, please let me know so I can figure out what the extent of the problem is. Also, I would be appreciate any suggestions regarding possible alternative solutions to our mailing list needs. Don Park CTO/Docuverse -----Original Message----- From: Don Park <donpark@quake.net> To: XLF List <xlf@cybercom.net> Date: Saturday, July 25, 1998 11:22 PM Subject: First Draft of XLF Spec Released >First draft of the XLF Spec is available for your review at >http://www.docuverse.com/xlf/NOTE-XLF-19980721-all.html The spec was built >out of messages from the XLF mailing list by Lisa and Gavin. Frankly, I am >amazed by their ability to create order out of chaos. > >Note that the XLF-HTTP section is missing from the spec. It will be filled >in initially by scavenging the ELF (Extended Log Format) spec. More potential > XLF-Core elements are being 'mined' by Lisa and Gavin from HTTP-NG and > XML-RPC variations. Principal Contributors section needs more work obviously > and will be filled in as the spec matures. > >Your suggestions, criticisms, and proposals are requested. > >Don Park >CTO/Docuverse > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dan at intervista.com Tue Jul 28 01:21:33 1998 From: dan at intervista.com (Dan Ancona) Date: Mon Jun 7 17:03:14 2004 Subject: [RFC] Whitepaper on Visual XML Message-ID: <3.0.32.19980727162935.00f9e300@mail.intervista.com> I've just been informed of the Visual XML name collision. There's no relation to the two other than they both have something to do with XML. Deep apologies to the Visual XML tool developers @ http://www.pierlou.com/visxml/ . I'll cook up a new name for my stuff & post it ASAP. (If a good name pops into someone's head, by all means send it to me. I'm terrible at naming stuff!) Dan At 01:33 PM 7/27/98 -0700, Dan Ancona wrote: >A draft of a whitepaper that I've written called "Visual XML: Authoring, >Publishing and Viewing Structured Information" is now available on the VRML >Consortium's website: > >http://www.vrml.org/WorkingGroups/dbwork/ancona/home.html > >I'm mostly thinking about the rendering of arbitrary XML files in VRML >rather than HTML. I have some experience with SGML, but I'm definitely >coming at this from the VRML side of things so I do have some unresolved >issues regarding how this work might fit in with stylesheets, the DOM, >XPointer & XLink, and XML's design goals in general. Any comments >regarding those areas are especially welcome. > >I think the most interesting possibilities lie in what 3D rendering might >mean for XLink, so if you're the type who likes to skip to the juicy parts >(like me), you might want to check out that part first. :) And please feel >free to forward this announcement to other lists as appropriate (it's just >been posted on www-vrml, but that's it so far). > >Cheers, >Dan > >__________________________________________________________ >Dan Ancona "engage!" >Tech Support, Evangelism and Cookery Intervista Software > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; >subscribe xml-dev-digest >List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > > > __________________________________________________________ Dan Ancona "engage!" Tech Support, Evangelism and Cookery Intervista Software xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Alice.Portillo at PSS.Boeing.com Tue Jul 28 02:01:49 1998 From: Alice.Portillo at PSS.Boeing.com (Portillo, Christina) Date: Mon Jun 7 17:03:14 2004 Subject: Naming Rules Message-ID: <F1B781B35CA8D011B10F00805FEA27F502236D6D@xch-rtn-01.ca.boeing.com> Reply to Chris Maden: Thank you for your excellent pointer to an online ISO 8879. It would be excellent if a similar thing could be done using the limitations and expansions to the tagging ruleset defined by XML. The question probably needs the more clarification in order for an answer to be put forth. dash=45 full-stop=46 colon=58 [A-Z]=65-90 underscore=95 [a-z]=97-122 In the XML SGML Declaration: NAMING LCNMSTRT "" UCNMSTRT "" NAMESTRT 58 95 192-214 216-246 248-305 308-318 321-328 .....snip..... LCNMCHAR "" UCNMCHAR "" NAMECHAR 45-46 183 720-721 768-837 864-865 903 1155-1158 ....snip.... NAMECASE GENERAL NO ENTITYNO The values for upper case A-Z and lower case a-z are not explicitly defined for NAMESTRT or NAMECHAR. I assume a default. The values for underscore and colon are not defined in NAMECHAR. I see nothing that would lead to assume a default for these values for NAMECHAR. As I see nothing that would lead me to assume a default for dash and period in NAMESTRT. The Extended Naming Rules (http://www.sil.org/sgml/wg8N1896rev.html) does not indicate the values for NAMECHAR and NAMESTRT are the same. In fact it appears to me, that the range or character must be specified or the characters are not an extended naming value for NAMECHAR or NAMESTRT. NAMESTRT means that each character identified by the extended naming value (if any) has the same effect as a character appearing in both UCNMSTRT and LCNMSTRT. NAMECHAR means that each character identified by the extended naming value (if any) has the same effect as a character appearing in both UCNMCHAR and LCNMCHAR. [189] naming rules = "NAMING", ps+, "LCNMSTRT", (ps+, extended naming value)+, ps+, "UCNMSTRT", (ps+, extended naming value)+, ps+, ("NAMESTRT", (ps+, extended naming value)+, ps+)?, "LCNMCHAR", (ps+, extended naming value)+, ps+, "UCNMCHAR", (ps+, extended naming value)+, ps+, ("NAMECHAR", (ps+, extended naming value)+, ps+)?, "NAMECASE", ps+, "GENERAL", ps+, ("NO"| "YES"), ps+, "ENTITY", ps+, ("NO"| "YES") [189.1] extended naming value = parameter literal | character number | character range [189.2] character range = character number, ps*, minus, ps*, character number Does this adequately detail the issue I am trying to resolve? Can you clarify this for me? Christina Portillo Product Definition and Image Technology The Boeing Company Phone: 425.237.3351 PO Box 3707 M/S 6H-AF Fax: 425.237.3428 Seattle, WA 98124-2207 christina.portillo@boeing.com > ---------- > From: Chris Maden[SMTP:crism@oreilly.com] > Reply To: Chris Maden > Sent: Monday, July 27, 1998 11:32 AM > To: xml-dev@ic.ac.uk > Subject: Re: Naming Rules > > [Christina Portillo] > > I need some clarification on the differences in the naming rules > > defined in the XML SGML Declaration and the Naming Rules defined in > > XML Part 1 Names and Tokens. > > [...] > > > My understanding of the Name restricts the 1st character position to > > a letter or a underscore or colon which is in sync with the SGML > > Declaration. But the NameChar allows underscores and colons in the > > remaining character positions which is at variance with the naming > > rules defined by the SGML Declaration. > > > > Can you clarify this for me? > > Characters defined as NAMESTRT, LCNMSTRT, or UCNMSTRT are usable as > name characters; that is, name start characters are a strict subset of > name characters, and so definition as the former implies definition as > the latter. > > The relevant productions from ISO 8879 are: > > [52] name character = > name start character | > Digit | > LCNMCHAR | > UCNMCHAR > > [53] name start character = > LC Letter | > UC Letter | > LCNMSTRT | > UCNMSTRT > > (See <URL:http://www.oreilly.com/people/staff/crism/sgmldefs.html>.) > > Note that this information is not necessary to understand the XML > Recommendation; the name productions in REC-XML are correct as they > stand. > > -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) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jubrown at earthlink.net Tue Jul 28 04:42:00 1998 From: jubrown at earthlink.net (Julie Brown) Date: Mon Jun 7 17:03:14 2004 Subject: (un)subscribe xml-dev Message-ID: <01BDB996.86307EC0@ip8.san-francisco23.ca.pub-ip.psi.net> (un)subscribe 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 murata at apsdc.ksp.fujixerox.co.jp Tue Jul 28 07:03:04 1998 From: murata at apsdc.ksp.fujixerox.co.jp (MURATA Makoto) Date: Mon Jun 7 17:03:14 2004 Subject: MIME spec roundup In-Reply-To: <35BC9C04.F6BFCAE7@finetuning.com> Message-ID: <199807280506.AA01832@murata.apsdc.ksp.fujixerox.co.jp> Lisa Rein wrote: > I believe there were five in all and I've got them all on one page now > for convenience -- let me know if I've missed anything...thanks! I think that RFC2376: XML Media types might be relevant. :-) 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 crism at oreilly.com Tue Jul 28 16:27:41 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:03:14 2004 Subject: Naming Rules In-Reply-To: <F1B781B35CA8D011B10F00805FEA27F502236D6D@xch-rtn-01.ca.boeing.com> (Alice.Portillo@PSS.Boeing.com) Message-ID: <199807281425.KAA18530@ruby.ora.com> Christina Portillo > Thank you for your excellent pointer to an online ISO 8879. It would > be excellent if a similar thing could be done using the limitations > and expansions to the tagging ruleset defined by XML. > > The question probably needs the more clarification in order for an > answer to be put forth. [...] > The values for upper case A-Z and lower case a-z are not explicitly > defined for NAMESTRT or NAMECHAR. I assume a default. You are confusing yourself. (1) The XML productions for naming are correct as written. (2) If you want to examine the SGML reasons behind the naming rules, you need to understand the name productions. [55] name = name start character, name character* [53] name start character = LC Letter | UC Letter | LCNMSTRT | UCNMSTRT So far, so good. But here's where you're getting tripped up: [52] name character = name start character | <== name character is a superset Digit | of name start character LCNMCHAR | UCNMCHAR As for A-Z defaults, etc., follow the hyperlinks in my on-line version of the productions. SGML is obtuse and complex, but its naming productions are fairly straightforward. -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 Tue Jul 28 16:38:15 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:15 2004 Subject: XCatalog proposal draft 0.1 References: <98Jul27.161639edt.26892@thicket.arbortext.com> Message-ID: <35BDE236.F1C31B16@locke.ccil.org> Paul Grosso scripsit: > System ids have been pretty obvious in most cases for decades. > While it is true that 8879 allows system ids to be almost anything, > all the SGML systems I've seen figure a regular looking system id > is a file name, and that works fine. In fact, it wasn't until > the third version of the SGML Open Catalog TR9401 that we added > mapping of system ids. But in XML *that doesn't work*, at least not in all cases. Systemids are URIs, and a systemid that looks like "foo.bar" is a relative URI, not necessarily a local file name. If you are processing a local file, it probably will be a local file name, but if you are processing a document fetched by HTTP, then it will be another document fetched from the same directory of the same server. This is why I believe systemid mapping is inappropriate for XML. When a document author provides a URI, he or she has a right to assume that the document processor will take that URI at face value. > The real reason for the SGML Open Catalog was because 8879 did not > define a way to map public ids into much of anything. And neither > does XML. Yes, and that's the property I want to keep. The four entry types Map (PUBLIC in Socat syntax), Catalog, Delegate, and Base provide what's needed for an infrastructure, analogous to DNS, to make public IDs truly *public*. -- 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 Jul 28 17:22:17 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:15 2004 Subject: XCatalog proposal draft 0.1 References: <199807272054.NAA05361@mehitabel.eng.sun.com> Message-ID: <35BDEC8B.BADD54EE@locke.ccil.org> Murray Altheim scripsit: > In order to be a legal URL (and hence a legal > URI), relative systemIds must be first qualified by a base URL. If I > follow the spec to the letter, relative URLs must make system assumptions > to obtain the base URL, which in some cases should be resolved via > catalog. Clause 3.3 of RFC 1808 says (in part): # If no base URL is embedded and the document is not encapsulated # within some other entity (e.g., the top level of a composite entity), # then, if a URL was used to retrieve the base document, that URL shall # be considered the base URL. So a systemid that is a relative URL is normally to be interpreted as relative to the URL of the document. This is only problematic in the case of the main document entity not having an URL (e.g. standard input). > I disagree with John's assertion that 'URNs are not defined'. I answered > Paul Prescod's similar statement showing that URN specs do exist [URN], Unfortunately, I can't dereference that URL. Is there a copy somewhere that is publicly accessible? > with IETF RFCs for syntax and resolution, as well as working > implementations. That vendors haven't yet implemented support is another > matter entirely. I grant you syntax. The only RFC'ed resolution protocol is an Experimental protocol, and the only two other relevant RFCs are requirements and principles. That hardly constitutes a robust infrastructure definition. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From M.H.Kay at eng.icl.co.uk Tue Jul 28 18:13:52 1998 From: M.H.Kay at eng.icl.co.uk (Michael Kay) Date: Mon Jun 7 17:03:15 2004 Subject: Fw: HyBrick Availability Announcement Message-ID: <003a01bdba43$17540780$1e09e391@mhklaptop.bra01.icl.co.uk> I forward the attached from my colleagues in Fujitsu - Mike Kay >>From: Ralph Ferris <ralph@fsc.fujitsu.com> >>Subject: HyBrick Availability Announcement >> >>All, >> >>"HyBrick", an SGML/XML browser developed by Fujitsu Laboratories, is now >>available free from http://collie.fujitsu.com/hybrick/. This version of >>"HyBrick" supports the use of DSSSL Scheme-based style sheets. Import of >>graphics using the "make external-graphic" procedure in the style sheet is >>supported. The "make link" procedure, which has been demonstrated in >earlier versions of HyBrick, is not supported in this release. Linking, >using XLink and XPointer, will be added in a later release. See the "Known >Issues List" for more information. >> >>A few small sample files are included with the distribution. They are >located in the directories Sample/sample1 and Sample/XML-sample. Go to one >of these directories and open the files with *.sgm and *.xml suffixes. >Ignore any files currently listed in the file pull-down menu. >> >>Questions and comments to hb-staff@mlserv.flab.fujitsu.co.jp >> >> >>Ralph E. Ferris >>Fujitsu Software Corporation >> >> >> >> > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From lutzenbe at informatik.tu-muenchen.de Tue Jul 28 18:35:34 1998 From: lutzenbe at informatik.tu-muenchen.de (Helmut Lutzenberger) Date: Mon Jun 7 17:03:15 2004 Subject: Model group ambiguities Message-ID: <yam7513.1338.139859752@hphalle0.informatik.tu-muenchen.de> Hi, I read something about model group ambiguities, saying things like: (item?, item) are ambiguous and are therefor not parseable by an XML-parser. My question is now; model groups are regular expressions and every regular expression is equal to a nondetermenistic automat and with Myhill-Nerode it is possible to build an determenistic automat equal to the nondetermenistic one. So I thing it should be possible for the XML-Parser to eliminate such ambiguities automatically, without too much trouble. Or am I wrong? -Helmut -- Helmut Lutz Lutzenberger Phone: +49-89-68 29 17 Email: lutzenbe@informatik.tu-muenchen.de xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Curt.Arnold at hyprotech.com Tue Jul 28 19:01:02 1998 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:03:15 2004 Subject: Objectives of Inheritance Message-ID: <E0z1D7M-0007MC-00@punch.ic.ac.uk> > First of all, I've been working with the January XML-Data DTD and > haven't had a chance to really get my mind around XSchema, so any XML > fragments in here will be XML-Data like instead of XSchema like. > > I've been building a fairly complex Schema using an XML-Data > definition converted to a DTD. I've been making extensive use of > inheritance, and have observed that I'm using inheritance to > accomplish three objectives. If XSchema provides or could provides > methods to readily accomplish these objectives, then we might be able > to sidestep poorly defined or difficult to implement constructs (For > example, I've avoided attempting to merge the child's content model > with the parent's content model) > > For the discussion, lets assume that I am building a Schema to contain > mathematical correlations. I have a generic CORRELATION element that > has CLASSID and CODE attributes to specify the COM or Java object that > implements the correlation, plus RANGE and PARAM elements that contain > the range that the correlation is valid and any parameters needed for > the implementation. I also want to define a POLYNOMIAL element that > is a specific type of CORRELATION that I anticipate that the > application would implement internally. > > Objective 1: Membership in a group > > The first objective is to define a group that contains CORRELATION and > any "derived" elements, so that I can use POLYNOMIAL anywhere that I > could use CORRELATION. This is roughly equivalent to being able to > cast a Polynomial class pointer down to a Correlation class pointer. > > Objective 2: Reusing content model > > The next objective is replicate all or part of the content model of > the parent. If CORRELATION allows a RANGE, then I would like it to be > natural for POLYNOMIAL to have a range. This (and the next) objective > are frequently accomplished in DTDs using parameter entities. > > Objective 3: Reusing attributes > > The next objective is replicate all or part of the attribute list of > the parent. If CORRELATION allows a NAME attribute, then I would like > it to be natural for POLYNOMIAL to have a NAME. > > Without really looking at what is in XSchema, it would seem that these > could be accomplished relatively simply. The following pseudo-XML > demonstrates what I was thinking. > > <SCHEMA> > <GROUP ID="CORR-DERIVED" NAME="CORRELATION and related elements"> > <ELEMENTTYPE ID="CORRELATION"> > <GROUP ID="CORR-CONTENT" OCCURS="OPTIONAL"> > <ELEMENTTYPE HREF="#RANGE" OCCURS="STAR"/> > <ELEMENTTYPE HREF="#PARAM" OCCURS="STAR"/> > </GROUP> > <!-- would be necessary to have some concept of > attribute group so you can replicate a whole > bunch of attributes --> > <ATTRIB-GROUP ID="CORR-ATTRIBS"> > <ATTRIBUTE ID="NAME"/> > <ATTRIBUTE ID="CLASSID"/> > <ATTRIBUTE ID="CODE"/> > <ATTRIBUTE ID="CODEBASE"/> > </ATTRIB-GROUP> > <ELEMENTTYPE> > > <ELEMENTTYPE ID="POLYNOMIAL"> > <!-- just borrow the content model of CORRELATION --> > <GROUP HREF="#CORR-CONTENT"/> > <!-- add a few new attributes to those defined by > CORRELATION --> > <ATTRIB-GROUP ID="POLY-ATTRIB"> > <ATTRIB-GROUP HREF="#CORR-ATTRIBS"/> > <ATTRIBUTE NAME="A"/> > <ATTRIBUTE NAME="B"/> > <ATTRIBUTE NAME="C"/> > </ATTRIB-GROUP> > </ELEMENTTYPE> > </GROUP> > > <ELEMENT ID="OTHER"> > <GROUP ID="OTHER-CONTENT"> > <GROUP HREF="#CORR-DERIVED"/> > </GROUP> > </ELEMENT> > </SCHEMA> > > Questions: > > Are there any objectives of inheritance that I overlooked? > > How readily does XSchema accomplish each of the objectives? > > Are there any minor enhancements to XSchema that would make these > objectives more achievable? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From daniela at cnet.com Tue Jul 28 19:30:55 1998 From: daniela at cnet.com (Daniel B. Austin) Date: Mon Jun 7 17:03:15 2004 Subject: Model group ambiguities Message-ID: <004301bdba4c$3eadcba0$7f53a2cc@cnet.com> Helmut, SGML content models can be reduced to deterministic forms in all cases, but the techniques for doing so can be difficult, and the effort involved extensive. While any SGML content model can be rewritten to conform to the XML specification, the result may be quite lengthy. A parser written to do this would be a complex undertaking. You can find information regarding SGML & XML content models here: http://www.cs.helsinki.fi/~kilpelai/C-1998-12.html . This paper by Pekka Kilpelainen at Helsinki U. is a rigorous explication of the mathematics involved. Regards, D- **************************************************************************** **** Daniel Austin, Director of Development, Creative Services, CNET daniela@cnet.com 415-395-7800 x1438 "To change the old into the new, and the shapes of things to come..." -----Original Message----- From: Helmut Lutzenberger <lutzenbe@informatik.tu-muenchen.de> To: <xml-dev@ic.ac.uk> Date: Tuesday, July 28, 1998 9:42 AM Subject: Model group ambiguities >Hi, > > I read something about model group ambiguities, saying things like: >(item?, item) are ambiguous and are therefor not parseable by an >XML-parser. > >My question is now; model groups are regular expressions and every >regular >expression is equal to a nondetermenistic automat and with >Myhill-Nerode it >is possible to build an determenistic automat equal to the >nondetermenistic >one. So I thing it should be possible for the XML-Parser to eliminate >such >ambiguities automatically, without too much trouble. Or am I wrong? > >-Helmut > >-- >Helmut Lutz Lutzenberger >Phone: +49-89-68 29 17 >Email: lutzenbe@informatik.tu-muenchen.de > > >xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk >Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ >To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; >(un)subscribe xml-dev >To subscribe 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 jtauber at jtauber.com Tue Jul 28 19:34:03 1998 From: jtauber at jtauber.com (James K. Tauber) Date: Mon Jun 7 17:03:15 2004 Subject: Model group ambiguities In-Reply-To: <yam7513.1338.139859752@hphalle0.informatik.tu-muenchen.de> Message-ID: <000301bdba4e$0443a780$e46118cb@caleb> > it > is possible to build an determenistic automat equal to the > nondetermenistic > one. So I thing it should be possible for the XML-Parser to eliminate > such > ambiguities automatically, without too much trouble. Or am I wrong? >From the spec: "Algorithms exist which allow many but not all non-deterministic content models to be reduced automatically to equivalent deterministic models; see Br?ggemann-Klein 1991" -- http://www.w3.org/TR/1998/REC-xml-19980210#determinism James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jtauber at jtauber.com Tue Jul 28 19:46:10 1998 From: jtauber at jtauber.com (James K. Tauber) Date: Mon Jun 7 17:03:15 2004 Subject: Model group ambiguities In-Reply-To: <004301bdba4c$3eadcba0$7f53a2cc@cnet.com> Message-ID: <000401bdba4f$a583c160$e46118cb@caleb> Daniel B. Austin: > SGML content models can be reduced to deterministic forms > in all cases, My understanding was that SGML content models have to be deterministic to start with in order to avoid problems with automatic reduction to DFAs because of and groups, etc. My automata theory is a bit rusty but check out Annex H of ISO 8879. James -- James Tauber / jtauber@jtauber.com http://www.jtauber.com/ Lecturer and Associate Researcher Electronic Commerce Network ( http://www.xmlinfo.com/ Curtin Business School ( http://www.xmlsoftware.com/ Perth, Western Australia ( http://www.schema.net/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Tue Jul 28 20:11:21 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:15 2004 Subject: Namespaces: prefixes vs. no prefixes Message-ID: <199807281806.UAA20761@berlin.dvs1.tu-darmstadt.de> This is undoubtedly a no-brainer, but it has just now occurred to me that the following two DTDs are almost certainly not the same. <!ELEMENT A (B+)> <!ELEMENT B (#PCDATA)> and <!ELEMENT FOO:A (FOO:B+)> <!ELEMENT FOO:B (#PCDATA)> Originally, I had thought that instances of the first case would be recognized by applications designed for the second -- that is, an application would have a "default" namespace) -- but now I am leaning the other way. The namespace spec does not describe how to compare names, so I am assuming that they are first resolved into fully qualified names and then compared stringwise. One of the consequences of this is that if namespace prefixes are used in a DTD, they must be used in both the instance file and in the application. (Of course, it is easy to imagine an application implementing a default namespace for backward compatibility, but this is outside the spec.) Could somebody confirm that these DTD are, in fact, different? -- 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 Jul 28 20:33:02 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:15 2004 Subject: Namespaces: prefixes vs. no prefixes References: <199807281806.UAA20761@berlin.dvs1.tu-darmstadt.de> Message-ID: <35BE1940.45F630C5@locke.ccil.org> Ron Bourret wrote: > This is undoubtedly a no-brainer, but it has just now occurred to me that the > following two DTDs are almost certainly not the same. > > <!ELEMENT A (B+)> > <!ELEMENT B (#PCDATA)> > > and > > <!ELEMENT FOO:A (FOO:B+)> > <!ELEMENT FOO:B (#PCDATA)> IMHO they are not, since the current namespace draft provides no way to declare the meaning of unprefixed element names. > One of the consequences of this is that if namespace prefixes are used in a DTD, > they must be used in both the instance file and in the application. "In the DTD iff in the instance" is certainly true. The application need not use them if it uses something similar to my namespace prefix remapper. Perhaps I should have an ability to declare a prefix to be attached to unprefixed names, but I don't really see the point of it. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 28 20:37:56 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:03:15 2004 Subject: Validating : error code vs. Exception ? Message-ID: <199807281836.UAA03319@chimay.loria.fr> <hi/> I am (always !) developing an XML Validating Parser in Java. I'm developing the Error management during the process of validation. I am a little unsure of the use of either returning an error code or throwing an Exception ? What about your opinions ? Thanks, Pat. -- ============================================================== bonhomme@loria.fr | Office : B.228 http://www.loria.fr/~bonhomme | Phone : 03 83 59 30 52 -------------------------------------------------------------- * Serveur Silfide : http://www.loria.fr/projets/Silfide * Projet Aquarelle : http://aqua.inria.fr ============================================================== xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Tue Jul 28 21:01:41 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:15 2004 Subject: Validating : error code vs. Exception ? In-Reply-To: <199807281836.UAA03319@chimay.loria.fr> References: <199807281836.UAA03319@chimay.loria.fr> Message-ID: <199807281901.PAA03856@unready.megginson.com> Patrice Bonhomme writes: > I am (always !) developing an XML Validating Parser in Java. I'm developing > the Error management during the process of validation. I am a little unsure of > the use of either returning an error code or throwing an Exception ? SAX leave the choice up the the application (user): the parser simply makes a callback to an error handler, and the error handler throws an exception if it wants to. All the best, David -- David Megginson david@megginson.com http://www.megginson.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 28 21:37:12 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:03:15 2004 Subject: VXML in one file References: <199807280506.AA01832@murata.apsdc.ksp.fujixerox.co.jp> Message-ID: <35BE3099.71387762@finetuning.com> at my coersion Dan has put the VXML white paper onto a single, easily printable page: http://www.ultrablue.com/dan/vxml/printable.html thanks dan! lisa rein xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 28 22:54:08 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:15 2004 Subject: Namespaces: prefixes vs. no prefixes In-Reply-To: <35BE1940.45F630C5@locke.ccil.org> References: <199807281806.UAA20761@berlin.dvs1.tu-darmstadt.de> Message-ID: <3.0.1.16.19980728212547.098719fc@pop3.demon.co.uk> At 14:32 28/07/98 -0400, John Cowan wrote: >Ron Bourret wrote: > >> This is undoubtedly a no-brainer, but it has just now occurred to me that the >> following two DTDs are almost certainly not the same. >> >> <!ELEMENT A (B+)> >> <!ELEMENT B (#PCDATA)> >> >> and >> >> <!ELEMENT FOO:A (FOO:B+)> >> <!ELEMENT FOO:B (#PCDATA)> > >IMHO they are not, since the current namespace draft provides no >way to declare the meaning of unprefixed element names. I'd recommend waiting for the next version of the namespace spec before analysing the 1998-05 draft too deeply. RSN, I believe. 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 Jul 28 22:54:11 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:15 2004 Subject: Objectives of Inheritance In-Reply-To: <E0z1D7M-0007MC-00@punch.ic.ac.uk> Message-ID: <3.0.1.16.19980728213753.1c0fd95e@pop3.demon.co.uk> At 10:35 28/07/98 -0600, Arnold, Curt wrote: >> >> I've been building a fairly complex Schema using an XML-Data >> definition converted to a DTD. I've been making extensive use of >> inheritance, and have observed that I'm using inheritance to >> accomplish three objectives. If XSchema provides or could provides >> methods to readily accomplish these objectives, then we might be able >> to sidestep poorly defined or difficult to implement constructs (For >> example, I've avoided attempting to merge the child's content model >> with the parent's content model) [... useful suggestion for inheritance snipped ...] >> >> How readily does XSchema accomplish each of the objectives? >> >> Are there any minor enhancements to XSchema that would make these >> objectives more achievable? I think this is a very important area and one that a lot of us are keen to get into. For example, at present I am implementing (part) of XML-data (or XML-data-like) components in JUMBO. I am then finding that I need to extend these for more specific objects. In my mind there are two separate, but combinable issues: - XML-data primitives. I think it would be extremely useful to implement them (but without the additional relationships). - deriving more specialised components from them (or from anything else). I think that the XSchema team has been taking this in stages - i.e. first get as simple a schema as possible and see if it works. This has to include ways of extending it - possibly in ways like you suggested. Then think of specific ways to extend it that we can all agree are valuable. Of course this is all still experimental but I have good feelings that it's worthwhile. 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 Jul 29 00:46:17 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:15 2004 Subject: Could you forward this? [from Jon Bosak] Message-ID: <3.0.1.16.19980728233709.362fe828@pop3.demon.co.uk> >Date: Tue, 28 Jul 1998 14:23:09 -0700 >From: Jon.Bosak@eng.sun.com (Jon Bosak) >To: xml-dev@ic.ac.uk, xml-l@listserv.heanet.ie >Subject: Presentations at XML Developers' Conference >Content-Length: 775 >A preliminary list of speakers presenting at the upcoming XML >Developers' Conference (August 20-21, Montral, Canada) can now be >found at http://www.gca.org/conf/meta98/xmldev98/ >It looks like a pretty interesting lineup... >The final schedule should be available within the next 48 hours. > >Jon > >---------------------------------------------------------------------- > Jon Bosak, Online Information Technology Architect, Sun Microsystems > 901 San Antonio Road, MPK17-101, Palo Alto, California 94303 > ISO/IEC JTC1/SC34/WG4::NCITS V1::OASIS::W3C XML WG::W3C XSL WG >---------------------------------------------------------------------- > It is earlier than we think. -- Vannevar Bush >---------------------------------------------------------------------- > > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From david at megginson.com Wed Jul 29 03:48:24 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:16 2004 Subject: SAX: two alternatives for namespaces Message-ID: <199807290147.VAA05229@unready.megginson.com> Background: Simple XML 1.0 names have only a single part, and are unique only within a document; the namespaces spec currently under development defines globally-unique names consisting of two parts: a (possibly null) URI part and a base part. Question: What changes to SAX 1.0 are required to support two-part names? After reading the follow-ups to my last posting, surviving far too many late WG meetings, and considering the problem during a few long, early morning runs, I can see only two reasonable alternatives for adding namespaces to SAX. I would like to hear what everyone -- especially, but not exclusively SAX parser and application writers -- thinks of these two alternatives: 1. Concatentation Use a single Java String (or C++ wstring, etc.) to represent a two-part name; select a non-XML character to use as the separator. Advantages: - requires no modification to SAX 1.0 Disadvantages: - places additional burden on applications - makes equality testing tricky - may produce unexpected results with applications that assume only traditional one-part names (especially normalisers) 2. New Interface Create a new SAX interface to represent a two-part name: public interface Name { public void setURIPart (String uri); public String getURIPart (); public void setBasePart (String base); public String getBasePart (); public boolean equals (Name name); public Name clone (); } Use this interface consistently throughout SAX for all XML 1.0 names (not just those covered by the namespaces spec). Modifications would be required to the DTDHandler, DocumentHandler, and AttributeList interfaces and to the HandlerBase and AttributeListImpl classes. Advantages: - provides a clean and powerful implementation - easily extensible: could add other information (such as the prefix used) in the future - provides easy and separate access to the URI part and the base part of a name Disadvantages: - another bloody interface - backwards-incompatible with SAX 1.0; all software would have to change Of course, we should finalise nothing until the namespaces spec becomes a recommendation. 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 kent at trl.ibm.co.jp Wed Jul 29 04:10:10 1998 From: kent at trl.ibm.co.jp (TAMURA Kent) Date: Mon Jun 7 17:03:16 2004 Subject: New release of XML for Java: 1.0.4 Message-ID: <199807290208.LAA35523@ns.trl.ibm.com> http://www.alphaworks.ibm.com/formula/xml IBM XML for Java 1.0.4, XML processor written in Java, has been released. It is a bug-fixed release. It does NOT conform to the latest DOM (19980720). If you use Sun JDK-1.1.6 on Win32, install the `JIT Upadte'. -- TAMURA, Kent @ Tokyo Research Laboratory, IBM Japan xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Wed Jul 29 04:25:40 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:16 2004 Subject: SAX: two alternatives for namespaces In-Reply-To: <199807290147.VAA05229@unready.megginson.com> Message-ID: <Pine.LNX.3.96.980728184752.14926A-100000@chris.hubick.com> On Tue, 28 Jul 1998, David Megginson wrote: > What changes to SAX 1.0 are required to support two-part names? > > 2. New Interface > > Create a new SAX interface to represent a two-part name: I vote for something like this (2). I am in the camp that as much work should be done by the XML processor as possible, rather than the application. I think this is more of a processor level feature rather than an add on. As a user, I don't mind another interface. I like SAX's design, it is extremely simple to use. I think one of the things that makes SAX easy to use is that it doesn't force me to use all the functionality, I can use DocumentHandler without having a clue about DTDHandler, EntityResolver, etc. So yet another interface doesn't bother me. And on that note... I strongly encourage adding a toString() to this Name interface, and having it return the full name just as before. As an application writer this would allow me to easily get the old funtionality from the new interface using a simple String cast, effectively allowing me to ignore namespaces if I don't care about them. Naturally I think version 2 of SAX should try to have as minimal an impact on version 1 features as possible. I think wherever possible it should extend interfaces by adding methods rather than changing existing ones. On the other hand I think that although that makes sence for providing support for something like comments, namespaces are to integraded for this approach and I can't see a better way to do it in this scenario. As far as my HXP parser goes, well, I plan on adding SAX 1 support as soon as I can, and had planned on namespace support anyhow, so I welcome this simple addition. Both of your proposals require the parser writer to support Namespaces, and as for parsers that don't - fix them :-) --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From donpark at quake.net Wed Jul 29 07:37:05 1998 From: donpark at quake.net (Don Park) Date: Mon Jun 7 17:03:16 2004 Subject: two alternatives for namespaces Message-ID: <006801bdbab1$acb9aff0$2ee044c6@arcot-main> How about an alternative solution? Define NamespaceSupport interface which is defined something like this: public interface NamespaceSupport { String getBaseName (String fullName); String getURIName (String fullName); ... Object getNamespace (String fullName); String getNamespaceURI (Object nameSpace); ... boolean equals (String fullName, Object targetNS, String targetName); ... } An implementation of NamespaceSupport is retrieved via a method in the Parser interface: public interface Parser { NamespaceSupport getNamespaceSupport(); } With some polish, it could be very nice, enviro-mentally speaking. Don Park CTO/Docuverse xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From peter at ursus.demon.co.uk Wed Jul 29 08:25:38 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:16 2004 Subject: [Q] How should SAX support Namespaces? In-Reply-To: <35B4C2F5.E6109C07@mecomnet.de> References: <3.0.1.16.19980720223336.2c7fd7c6@pop3.demon.co.uk> Message-ID: <3.0.1.16.19980729071548.39cfef34@pop3.demon.co.uk> I have just been looking at XML4J (not the one announced today - the previous one) and note that it has support for namespaces of the 1998-05 variety and also supports SAX. It is worth looking at - overall XML4J is an impressive piece of work to my untutored eye. It raises the more general suggestion that we could benefit from collating our current namespaces experience and see what approaches have been used so far. (This will be useful preparation for the next ns draft.) For example, I have been recently hacking JUMBO to support XML-Data-like primitives (e.g. float) including a primitive editor/entry system. I shall post the code shortly - I just need to try to hack in a new idea about inheritance that kept me awake last night. Other examples of WD-names-199805 systems which are (even partially) implemented could be valuable, including documents and DTDs. 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 h.rzepa at ic.ac.uk Wed Jul 29 09:04:29 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:03:16 2004 Subject: Presentations at XML Developers' Conference Message-ID: <v04011702b1e47a037cdb@[155.198.224.86]> > >Date: Tue, 28 Jul 1998 14:23:09 -0700 >From: Jon.Bosak@eng.sun.com (Jon Bosak) >To: xml-dev@ic.ac.uk, xml-l@listserv.heanet.ie >Subject: Presentations at XML Developers' Conference >Content-Length: 775 > >A preliminary list of speakers presenting at the upcoming XML >Developers' Conference (August 20-21, Montr?al, Canada) can now be >found at > > http://www.gca.org/conf/meta98/xmldev98/ > >It looks like a pretty interesting lineup... > >The final schedule should be available within the next 48 hours. > >Jon > >---------------------------------------------------------------------- > Jon Bosak, Online Information Technology Architect, Sun Microsystems > 901 San Antonio Road, MPK17-101, Palo Alto, California 94303 > ISO/IEC JTC1/SC34/WG4::NCITS V1::OASIS::W3C XML WG::W3C XSL WG >---------------------------------------------------------------------- > It is earlier than we think. -- Vannevar Bush >---------------------------------------------------------------------- > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Wed Jul 29 10:50:00 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:16 2004 Subject: Namespaces: prefixes vs. no prefixes Message-ID: <199807290844.KAA21975@berlin.dvs1.tu-darmstadt.de> [Forwarded for Murray Altheim] rbourret@dvs1.informatik.tu-darmstadt.de (Ron Bourret) writes: > > This is undoubtedly a no-brainer, but it has just now occurred to me that the > following two DTDs are almost certainly not the same. > > <!ELEMENT A (B+)> > <!ELEMENT B (#PCDATA)> > > and > > <!ELEMENT FOO:A (FOO:B+)> > <!ELEMENT FOO:B (#PCDATA)> > > Originally, I had thought that instances of the first case would be recognized > by applications designed for the second -- that is, an application would have a > "default" namespace) -- but now I am leaning the other way. The namespace spec > does not describe how to compare names, so I am assuming that they are first > resolved into fully qualified names and then compared stringwise. This is the only way that a comparison could occur. XML 1.0 processors would not be capable of this, so the DTD itself must be modified. > One of the consequences of this is that if namespace prefixes are used in a DTD, > they must be used in both the instance file and in the application. (Of course, > it is easy to imagine an application implementing a default namespace for > backward compatibility, but this is outside the spec.) > > Could somebody confirm that these DTD are, in fact, different? It really depends on how you frame your question. In the context of namespaces, they are theoretically the same since the element type names are now merely qualified by a namespace prefix. But strictly from an SGML and XML 1.0 standpoint, they are of course not the same. The element type 'A' is now transformed to an element type 'FOO:A'. As some are wont to note, computers are stupid, so parsing a ns-qualified document with an unqualified DTD will (quite correctly) throw a validation error. If a namespace-aware processor reads an unqualified external DTD and has access to the proper prefix (ie., the ns declaration occurs before the parser begins reading the DTD), then theoretically it could modify the DTD on the fly to grok the qualified document instance. I've been playing with this idea for several weeks. It relies on the ability of the parser to have access to the ns declaration before the DTD. But to answer your question, these two DTDs are in fact different. Murray ........................................................................... Murray Altheim, SGML Grease Monkey <mailto:altheim@eng.sun.com> Member of Technical Staff, Tools Development & Support Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900 "Give a monkey the tools and he'll build a typewriter." xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Lloyd.Rutledge at cwi.nl Wed Jul 29 14:16:57 1998 From: Lloyd.Rutledge at cwi.nl (Lloyd Rutledge) Date: Mon Jun 7 17:03:16 2004 Subject: Analysing XLink Message-ID: <UTC199807291215.OAA27412.lloyd@klipper.cwi.nl> Les Carr of the University of Southampton has asked me to pass this email along as a post to this group. It discusses an XLink implementation that he has begun. His entry is at the bottom of this post. -Lloyd -- Lloyd Rutledge vox: +31 20 592 41 27 CWI (Centrum voor Wiskunde en Informatica) fax: +31 20 592 41 99 Kruislaan 413, NL-1098 SJ Amsterdam, The Netherlands net: lloyd@cwi.nl P.O. Box 94079, NL-1090 GB Amsterdam, The Netherlands http://www.cwi.nl/~lloyd ****************************************************************************** As part of the Open Hypermedia Community's "Response to XLink" I have started to implement a set of JAVA packages for developing XLink-aware applications. Currently it is at a fairly rudimentary stage testing-wise, but I have mainly concentrated on trying to make high-level link processing methods that are generally useful. There is currently ONE sample application scenario, based on the LTXML group's ``Knit'' utility, although others are planned. A document describing the work so far can be found at http://journals.ecs.soton.ac.uk/xml4j/xlinkexperience.html If you would like to have a copy of the software as it exists, please let me know. (It builds on top of IBM's XML4JAVA parser & XPointer packages, but it has added better support for string()-based pointers.) -- Leslie Carr Tel: +44 1703 594479 Fax: +44 1703 592865 Email: L.Carr@ecs.soton.ac.uk URL: http://www.ecs.soton.ac.uk/~lac Dept of Electronics and Computer Science, University of Southampton SO17 1BJ, 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 Wed Jul 29 14:40:09 1998 From: david at megginson.com (David Megginson) Date: Mon Jun 7 17:03:16 2004 Subject: SAX: two alternatives for namespaces In-Reply-To: <Pine.LNX.3.96.980728184752.14926A-100000@chris.hubick.com> References: <199807290147.VAA05229@unready.megginson.com> <Pine.LNX.3.96.980728184752.14926A-100000@chris.hubick.com> Message-ID: <199807291233.IAA00220@unready.megginson.com> Chris Hubick writes: > As far as my HXP parser goes, well, I plan on adding SAX 1 > support as soon as I can, and had planned on namespace support > anyhow, so I welcome this simple addition. Both of your proposals > require the parser writer to support Namespaces, and as for parsers > that don't - fix them :-) Since XML 1.0 does not require namespace support, it is possible for a parser to be XML-conformant without supporting namespaces -- in that case, it would always set the URI part of the name to null. This leads to another thought -- that we probably need some kind of a hook for requesting and/or querying parser features. This issue came up before during the initial SAX 1.0 design. Something like the following might be appropriate: package org.xml.sax; public interface Parser { ... public boolean hasFeature (String featureName); public boolean requestFeature (String featureName, boolean status); } It is important to note that with such an approach, there would have to be a registry of feature names in addition to the SAX interface. Here's how you could use this interface: if (!parser.requestFeature("org.xml.sax.validation", true) || !parser.requestFeature("org.xml.sax.namespaces", false)) { throw new MyException("Cannot activate validation without namespaces."); } The details remain to be worked out. 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 rbourret at dvs1.informatik.tu-darmstadt.de Wed Jul 29 14:42:17 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:16 2004 Subject: Namespaces: prefixes vs. no prefixes Message-ID: <199807291235.OAA01506@berlin.dvs1.tu-darmstadt.de> John Cowan wrote: > "In the DTD iff in the instance" is certainly true. The application > need not use them if it uses something similar to my namespace > prefix remapper. Perhaps I should have an ability to declare a > prefix to be attached to unprefixed names, but I don't really see > the point of it. I was going to suggest such a function (a prefix for unprefixed names), but then realized I didn't know what the rules were. For the moment, leave it out and let applications implement it locally if they want to -- it's not difficult. In the future, it might be a nice backward compatibility tool. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From rbourret at dvs1.informatik.tu-darmstadt.de Wed Jul 29 15:10:50 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:16 2004 Subject: SAX: parser features (was SAX: two alternatives for namespaces) Message-ID: <199807291301.PAA01628@berlin.dvs1.tu-darmstadt.de> > This leads to another thought -- that we probably need some kind of a > hook for requesting and/or querying parser features. This issue came > up before during the initial SAX 1.0 design. Something like the > following might be appropriate: > > package org.xml.sax; > > public interface Parser { > ... > public boolean hasFeature (String featureName); > public boolean requestFeature (String featureName, boolean status); > } We designed this kind of mechanism into ODBC. Because of the large number of optional features, it is quite difficult to write truly generic ODBC code. I believe this was justified in ODBC's case because we wanted to work with a large variety of existing databases that had a tremendous range of capabilities. I don't think the same situation applies to SAX. SAX is still fairly young and we have a better chance to dictate/agree on required features, so we should avoid optional features as long as possible. (WRT namespaces, we should either design around them or simply require parsers to support them.) -- 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 Jul 29 15:55:23 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:16 2004 Subject: SAX: two alternatives for namespaces References: <199807290147.VAA05229@unready.megginson.com> Message-ID: <35BF29B5.DB5CC38D@locke.ccil.org> David Megginson wrote: > What changes to SAX 1.0 are required to support two-part names? Follows a summary of my views. > 1. Concatentation > > Use a single Java String (or C++ wstring, etc.) to represent a > two-part name; select a non-XML character to use as the separator. I strongly support this. > Advantages: > - requires no modification to SAX 1.0 Also: it can be layered on top of existing SAX-compliant parsers as a filter, so that parsers need not change for namespace support. > Disadvantages: > - places additional burden on applications > - may produce unexpected results with applications that assume only > traditional one-part names (especially normalisers) Adding namespace support in a filter makes avoiding these problems easy: if namespace interpretation is a Bad Idea for your application, don't install it. It is applications, not parsers, that need or don't need namespace information. > - makes equality testing tricky I'm not sure I understand this. Assuming that all relative URLs are coerced to absolute form (which my current implementation regrettably does not do), there seem to be no special issues. > 2. New Interface > Advantages: > - provides easy and separate access to the URI part and the base > part of a name Adding a few static routines to separate a combined string into its components adds very little space cost, though admittedly some runtime cost. > Disadvantages: > - backwards-incompatible with SAX 1.0; all software would have to > change I think this is a very large cost indeed. > Of course, we should finalise nothing until the namespaces spec > becomes a recommendation. Agreed, but experimental implementations are well worthwhile. -- 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 Jul 29 16:15:04 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:16 2004 Subject: Namespaces: prefixes vs. no prefixes References: <199807290844.KAA21975@berlin.dvs1.tu-darmstadt.de> Message-ID: <35BF2E4B.8EB6B930@locke.ccil.org> Murray Altheim wrote: > If a namespace-aware processor reads an unqualified external DTD and has > access to the proper prefix (ie., the ns declaration occurs before the > parser begins reading the DTD), then theoretically it could modify the DTD > on the fly to grok the qualified document instance. I've been playing with > this idea for several weeks. It relies on the ability of the parser to > have access to the ns declaration before the DTD. The current namespace draft *requires* that all namespace declarations appear before the DOCTYPE declaration, and therefore before the DTD (internal or external) is read. See clause 2.2, sentence 1. -- 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 Jul 29 16:57:24 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:16 2004 Subject: SAX: parser features (was SAX: two alternatives for namespaces) References: <199807291301.PAA01628@berlin.dvs1.tu-darmstadt.de> Message-ID: <35BF37FA.940787E0@locke.ccil.org> Ron Bourret wrote: > I don't think the same situation applies to SAX. SAX is still fairly young and > we have a better chance to dictate/agree on required features, so we should > avoid optional features as long as possible. Within XML 1.0, there are various things that non-validating parsers are allowed to do (or not do). A way of querying any particular parser to find out whether it does those things or not would be very useful. For example, a parser is allowed to disregard attribute types and claim that all attributes are CDATA. If your application depends on getting ID and IDREF types correct, you could query a parser to see if it can do that --- and if not, tell the user to pick another parser. So these are not so much SAX features as XML features. -- 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 Jul 29 17:07:35 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:16 2004 Subject: Itsy Bitsy revised again Message-ID: <35BF3A9B.53AFCE7D@locke.ccil.org> A new draft of the Itsy Bitsy Teeny Weeny Simple Hypertext DTD is now available at http://www.ccil.org/~cowan/XML/ibtwsh.dtd . The new feature is that if you define a parameter entity called "ibtwsh.include" before incorporating IBTWSH into another DTD, then the element or elements named there will be allowed as part of horizontal content. This allows domain-specific elements to be inserted into running IBTWSH text. To include multiple elements, separate them with | characters. Examples: <!ENTITY % ibtwsh.include "REF"> <!-- allows REF elements in IBTWSH text --> <!ENTITY % ibtwsh.include "REF | DEF"> <!-- allows REF or DEF elements in IBTWSH text --> The default value of ibtwsh.include is "XML". -- 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 Curt.Arnold at hyprotech.com Wed Jul 29 17:11:42 1998 From: Curt.Arnold at hyprotech.com (Arnold, Curt) Date: Mon Jun 7 17:03:16 2004 Subject: Applet for DTD content model diagramming Message-ID: <E0z1Xsi-0003vA-00@punch.ic.ac.uk> Does anyone have know a source for a applet that would draw content model diagrams such as appear in David Megginson's book for use in automatically generated schema documentation? Also, has anyone done anything with adding XML shortcuts or support to CodeWright? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From elharo at sunsite.unc.edu Wed Jul 29 17:31:06 1998 From: elharo at sunsite.unc.edu (Elliotte Rusty Harold) Date: Mon Jun 7 17:03:17 2004 Subject: New XML book In-Reply-To: <v04011702b1e47a037cdb@[155.198.224.86]> Message-ID: <v03102801b1e4ec93b90d@[168.100.203.234]> I'd like to announce the publication of my latest book "XML: Extensible Markup Language" from IDG Books. (ISBN 0-764-53199-9) This book is an introduction to XML for HTML developers.It shows you how to write documents in XML and how to use XSL style sheets to convert those documents into HTML so legacy browsers can read them. You`ll also learn how to use DTDs to describe and validate documents. This book is the first one to look at XML not from the perspective of a software developer but rather that of a web page author. It doesn`t spend a lot of pages talking about BNF grammars or parsing element trees. Instead it shows you how you can use XML and existing tools today to more efficiently and productively produce powerful web sites. Fortunately XML has a decidedly unsteep learning curve, much like HTML (and unlike SGML). As you learn a little you can do a little. As you learn a little more, you can do a little more. This book is aimed squarely at web site developers. I assume that you want to use XML to produce web sites that are difficult to impossible to create with raw HTML. You'll be amazed to discover that in conjunction with XSL style sheets and a few free tools, XML lets you do things that previously required either custom software costing hundreds to thousands of dollars per developer or extensive knowledge of programming languages like Perl. None of the software in this book will cost you more than a few minutes of download time. None of the tricks require any programming beyond the most basic cut and paste JavaScript. Now the down side: the dynamics of dead tree publishing are such that much of this book was written about six months ago. At the time I decided to use XSL rather heavily. In hindsight, that was probably a mistake. Almost all the XSL material will be out of date within the next month if it isn't already. I'll be working on updates to be posted on the Cafe con Leche web site at http://sunsite.unc.edu/xml/ next month. This is my fifth computer book, and I've yet to write one that managed to be completely in sync with the technology it described for more than a week after the date of publication, so this may be an unavoidable problem. Nonetheless, I think there's still a lot of useful information in this book, particularly for anyone who's considering using XML as a back end for web sites. "XML: Extensible Markup Language" is available now from amazon.com <http://www.amazon.com/exec/obidos/ASIN/0764531999/cafeaulaitA/> and Computer Literacy <http://www.clbooks.com/sqlnut/SP/search/gtsumt?isbn=0764531999>, and soon from bookstores everywhere. I'll be particularly interested to hear what this audience thinks of it, and how you think it might be imprloved in future editions. Table of Contents Preface Part 1: XML Basics - Chapter 1 Introducing XML - Chapter 2 Beginning XML - Chapter 3 Formalizing XML - Chapter 4 XSL Part II: DTDs - Chapter 5 Using DTDs in XML Documents - Chapter 6 Assembling Documents from Multiple Data Sources - Chapter 7 Describing Elements with Attributes Part III: The Bleeding Edge - Chapter 8 International Text - Chapter 9 XLL Part IV: XML Applications - Chapter 10 CDF - Chapter 11 Genealogy Appendixes - XML QuickRef - Appendix A International Character Sets - Appendix B XML Glossary - Appendix C About the CD - Appendix D Additional Resources +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@sunsite.unc.edu | Writer/Programmer | +-----------------------+------------------------+-------------------+ | XML: Extensible Markup Language (IDG Books 1998) | | http://www.amazon.com/exec/obidos/ISBN=0764531999/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://sunsite.unc.edu/javafaq/ | | Read Cafe con Leche for XML News: http://sunsite.unc.edu/xml/ | +----------------------------------+---------------------------------+ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dan at intervista.com Wed Jul 29 20:06:34 1998 From: dan at intervista.com (Dan Ancona) Date: Mon Jun 7 17:03:17 2004 Subject: VB example Message-ID: <3.0.32.19980729111457.00a84ff4@mail.intervista.com> A bit of a longshot here: anyone have an example showing how to use MSXML (for example) to do stuff in Visual Basic? There are tons of web-based examples out there of course, but I'm new to programming in VB and the syntax is just different enough to be giving me a headache. I'm doing this for my day job...has nothing to do w/ the whitepaper I posted, oddly enough. Thanks in advance, Dan __________________________________________________________ Dan Ancona "engage!" Tech Support, Evangelism and Cookery Intervista Software xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 29 21:01:16 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:17 2004 Subject: Cowan's namespace implementation: bug Message-ID: <35BF7164.51D55B5A@locke.ccil.org> Thanks to Ron Bourret, a trivial bug has been found and fixed in http://www.ccil.org/~cowan/XML/ns.jar, the alpha version of my SAX-compatible namespace add-on. -- 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 Alice.Portillo at PSS.Boeing.com Wed Jul 29 21:09:08 1998 From: Alice.Portillo at PSS.Boeing.com (Portillo, Christina) Date: Mon Jun 7 17:03:17 2004 Subject: System Literal Message-ID: <F1B781B35CA8D011B10F00805FEA27F5026708EF@xch-rtn-01.ca.boeing.com> Does SystemLiteral read that any characters values, [02]Char or [84]Letter, can be placed between the quotes single or double less the ranges [^"] or [^'] ? [11] SystemLiteral ::= ('"' [^"]* '"') | ("'" [^']* "'") [75] ExternalID ::= 'SYSTEM' S SystemLiteral | 'PUBLIC' S PubidLiteral S SystemLiteral Christina Portillo Product Definition and Image Technology The Boeing Company Phone: 425.237.3351 PO Box 3707 M/S 6H-AF Fax: 425.237.3428 Seattle, WA 98124-2207 christina.portillo@boeing.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Wed Jul 29 21:56:05 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:17 2004 Subject: System Literal In-Reply-To: <F1B781B35CA8D011B10F00805FEA27F5026708EF@xch-rtn-01.ca.boeing.com> Message-ID: <Pine.LNX.3.96.980729124822.15726A-100000@chris.hubick.com> On Wed, 29 Jul 1998, Portillo, Christina wrote: > Does SystemLiteral read that any characters values, [02]Char or > [84]Letter, can be placed between the quotes single or double less the > ranges [^"] or [^'] ? > > [11] SystemLiteral ::= ('"' [^"]* '"') | ("'" [^']* "'") I read this as _any_ character values, otherwise it would have to be: [11] SystemLiteral ::= ('"' (Char - '"')* '"') | ("'" (Char - "'")* "'") --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From cowan at locke.ccil.org Wed Jul 29 22:06:59 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:17 2004 Subject: System Literal References: <F1B781B35CA8D011B10F00805FEA27F5026708EF@xch-rtn-01.ca.boeing.com> Message-ID: <35BF80BC.D519DAA6@locke.ccil.org> Portillo, Christina wrote: Christina Portillo scripsit: > Does SystemLiteral read that any characters values, [02]Char or > [84]Letter, can be placed between the quotes single or double less the > ranges [^"] or [^'] ? A SystemLiteral beginning with " can contain any character except " (that is what [^"] means). A SystemLiteral beginning with ' can, correspondingly, contain any character except '. URIs allow [-$_.+!*'(),;/?:@&=] plus [A-Za-z0-9] in them, but not ", so the safest approach for XML Systemids is always to use " delimitation. -- 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 Sung_Nguyen at datacard.com Wed Jul 29 23:28:15 1998 From: Sung_Nguyen at datacard.com (Sung Nguyen) Date: Mon Jun 7 17:03:17 2004 Subject: Nested DTD Message-ID: <00101824.3096@datacard.com> Hello: I am looking for the rechnique of doing nested DTD. Please give me a hand. Thanks, SeanN xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Alice.Portillo at PSS.Boeing.com Thu Jul 30 00:13:21 1998 From: Alice.Portillo at PSS.Boeing.com (Portillo, Christina) Date: Mon Jun 7 17:03:17 2004 Subject: CharData Message-ID: <F1B781B35CA8D011B10F00805FEA27F5026708F1@xch-rtn-01.ca.boeing.com> XML states that "Text consists of intermingled character data and markup." SGML defines this as: [50] SGML character = markup character | DATACHAR [51] markup character = name character | function character | delmchar In my mind SGML DATACHAR and XML Char are equivalents. The XML defintion of CharData confuses me when I try to read it. Does this really force inclusion of the "-" and "]]>" in CharData? [14] CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*) It seems to read that CharData is: (Char less [^<&]* ) followed by - followed by (Char less [^<&]*) followed by ]]> followed by (Char less [^<&]*) Does this produce the intended result when CharData becomes part of: [43] content ::= (element | CharData | Reference | CDSect | PI | Comment)* and content becomes part of: [39] element ::= EmptyElemTag | STag content ETag [78] extParsedEnt ::= TextDecl? content Can someone tell me how to correctly read CharData? Christina Portillo Product Definition and Image Technology The Boeing Company Phone: 425.237.3351 PO Box 3707 M/S 6H-AF Fax: 425.237.3428 Seattle, WA 98124-2207 christina.portillo@boeing.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From crism at oreilly.com Thu Jul 30 00:24:04 1998 From: crism at oreilly.com (Chris Maden) Date: Mon Jun 7 17:03:17 2004 Subject: CharData In-Reply-To: <F1B781B35CA8D011B10F00805FEA27F5026708F1@xch-rtn-01.ca.boeing.com> (Alice.Portillo@PSS.Boeing.com) Message-ID: <199807292222.SAA10343@ruby.ora.com> [Christina Portillo] > The XML defintion of CharData confuses me when I try to read > it. Does this really force inclusion of the "-" and "]]>" in > CharData? > [14] CharData ::= [^<&]* - ([^<&]* ']]>' [^<&]*) > > It seems to read that CharData is: > (Char less [^<&]* ) followed by - followed by (Char less [^<&]*) > followed by ]]> followed by (Char less [^<&]*) Please read section 6, "Notation", of REC-XML. In this instance, A - B matches any string that matches A but does not match B. would be helpful, but I think you should probably read the entire spec through once, and then read it again and see if any questions remain. -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 peter at ursus.demon.co.uk Thu Jul 30 01:40:31 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:17 2004 Subject: SAX: two alternatives for namespaces In-Reply-To: <199807291233.IAA00220@unready.megginson.com> References: <Pine.LNX.3.96.980728184752.14926A-100000@chris.hubick.com> <199807290147.VAA05229@unready.megginson.com> <Pine.LNX.3.96.980728184752.14926A-100000@chris.hubick.com> Message-ID: <3.0.1.16.19980729222941.3e47559e@pop3.demon.co.uk> At 08:33 29/07/98 -0400, David Megginson wrote: > > package org.xml.sax; > > public interface Parser { > ... > public boolean hasFeature (String featureName); > public boolean requestFeature (String featureName, boolean status); > } > >It is important to note that with such an approach, there would have >to be a registry of feature names in addition to the SAX interface. > >Here's how you could use this interface: > > if (!parser.requestFeature("org.xml.sax.validation", true) || > !parser.requestFeature("org.xml.sax.namespaces", false)) { > throw new MyException("Cannot activate validation without namespaces."); > } I really like this idea. I had made a feeble effort along this sort of track by producing a SAXOptions class along the lines of GridBagConstraints in java.awt (i.e. values are poked in to influence GridBagLayout). This is obviously more sophisticated and having now seen it , the use of resources is an obvious way to go. My use was to control the whitespace behaviour of SAX... 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 Jul 30 01:40:34 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:17 2004 Subject: Analysing XLink In-Reply-To: <UTC199807291215.OAA27412.lloyd@klipper.cwi.nl> Message-ID: <3.0.1.16.19980729223236.3e475a34@pop3.demon.co.uk> At 14:15 29/07/98 +0200, Lloyd Rutledge wrote: [from Les Carr] > >As part of the Open Hypermedia Community's "Response to XLink" I have started >to implement a set of JAVA packages for developing XLink-aware applications. Many thanks for this contribution. I haven't yet looked at it but it seems just what I have been waiting for. > >Currently it is at a fairly rudimentary stage testing-wise, but I have >mainly concentrated on trying to make high-level link processing methods >that are generally useful. There is currently ONE sample application scenario, >based on the LTXML group's ``Knit'' utility, although others are planned. > >A document describing the work so far can be found at > http://journals.ecs.soton.ac.uk/xml4j/xlinkexperience.html >If you would like to have a copy of the software as it exists, please let >me know. (It builds on top of IBM's XML4JAVA parser & XPointer packages, >but it has added better support for string()-based pointers.) I like this re-use of existing software. P. Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From h.rzepa at ic.ac.uk Thu Jul 30 10:45:51 1998 From: h.rzepa at ic.ac.uk (Rzepa, Henry) Date: Mon Jun 7 17:03:17 2004 Subject: LISTADMIN: Majordomo list errors, policy and future Message-ID: <v0401170fb1e5dc4ee9a6@[155.198.224.86]> Dear all, Some members of this list may have seen some of the glitches and errors generated by the Majordomo list software this list uses. I have been endeavouring to sort out some of the reasons for this with our Centre for Computing Services. This posting explains my list policy for trying to deal with some of the errors that occur, and indicates a possible future stategy 1. Approximately 5-10 new errors occur each day deriving from the 1400 or so subscribed email addresses. These tend to be two types; 1. Temporary errors, including Disc quota exceeded messages (quite a lot of those!!) and "message that you sent has not yet been delivered to all its recipients after more than 24 hours on the queue" These errors I ignore, unless the error occurs repeatedly, in which case the entry is unsubscribed. 2. What I perceive to be hard errors. These come in many sorts. One common one is "cannot relay", or they can be more obscure such as "Cannot exec /db/mail/bin/ofcuto: No such file or directory" My policy is to unsubscribe these entries. This is done without any attempt to contact the owners, since mail cannot be delivered to them! Feedback suggests that some of these hard errors are sometimes fixed a few days or a week later, but more often they are never fixed. If for some reason, you suddently stop receiving xml-dev postings, it may be that you have been unsubscribed in this manner. You can still catch up on the postings by inspecting http://www.lists.ic.ac.uk/hypermail/xml-dev/ I would also ask that you re-subscribe by posting to majordom@ic.ac.uk the request subscribe xml-dev Please try to avoid the alternative form subscribe xml-dev j.bloggs@mail.domain since this requires moderation on my part, and I only do this in batches about twice a week (less if I am away, such as shortly when I will be on holiday!). I have received several mailings along the lines that the user expects their email account to change frequently (as often as once a month in one case), and requesting that we track such changes here, or provide instant responses to requests to change the subscription. Whilst this might be possible with eg Lyris (or other commercial software), please accept that currently, I simply do not have the resources or the time to provide such a service. 3. Majordomo has many other curious holes and peculiar errors. After considering the matter carefully for some time, my Computer centre has now agreed to evaluate Lyris as an alternative. I will keep the list posted on whether it will be possible to migrate to Lyris and to offer what I hope will be an improved service. 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 eriblair at mediom.qc.ca Thu Jul 30 18:02:26 1998 From: eriblair at mediom.qc.ca (Eric Riblair) Date: Mon Jun 7 17:03:17 2004 Subject: HELP ME PLEASE: Error when loading applet xmldso of ms Message-ID: <199807301601.MAA14441@netra.mediom.qc.ca> When I'd try to load an xmldso applet in an IE4.01 for Mac ... I had a response like this: Error loading class: com.ms.com.ComSuccessException java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.osp.OLEDBSimpleProvider java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.xml.dso.XMLRowsetProvider java.lang.ClassNotFoundException: com.ms.osp.OLEDBSimpleProvider Error loading class: com.ms.com.ComSuccessException java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.osp.OLEDBSimpleProvider java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.osp.OLEDBSimpleProvider java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.xml.dso.XMLRowsetProvider java.lang.ClassNotFoundException: com.ms.osp.OLEDBSimpleProvider java.lang.ClassNotFoundException: com.ms.xml.dso.XMLRowsetProvider at com/ms/vm/loader/URLClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Cla ss; (URLClassLoader.java:0:0x28) at java/lang/ClassLoader.loadClassInternal(Ljava/lang/String;Z)Ljava/lang/Class ; (ClassLoader.java:0:0x1f) at com/ms/xml/dso/SchemaNode.createElement(Z)V (XMLDSO.java:0:0x0) at com/ms/xml/dso/SchemaNode.setRow(Lcom/ms/xml/util/Name;)Lcom/ms/xml/dso/Sche maNode; (XMLDSO.java:0:0xc) at com/ms/xml/dso/XMLDSO.generateSchema(Lcom/ms/xml/om/Element;Lcom/ms/xml/dso/ SchemaNode;)V (XMLDSO.java:0:0x32) at com/ms/xml/dso/XMLDSO.updateSchema()V (XMLDSO.java:0:0x6a) at com/ms/xml/dso/XMLDSO.init()V (XMLDSO.java:0:0xf0) at com/ms/jam/AppletPanel.doAppletInit()V (AppletPanel.java:0:0x35) at com/ms/jam/AppletPanel.doAppletStateChange(I)V (AppletPanel.java:0:0x2f) at com/ms/jam/AppletViewerPanel.runApplet()V (AppletViewerPanel.java:0:0xba) at com/ms/jam/JAMAppletViewer.run()V (JAMAppletViewer.java:0:0x7) at java/lang/Thread.run()V (Thread.java:0:0x10) Does that mean anything to someone in this list ... Thanks for any help, Eric xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Sung_Nguyen at datacard.com Thu Jul 30 18:04:13 1998 From: Sung_Nguyen at datacard.com (Sung Nguyen) Date: Mon Jun 7 17:03:17 2004 Subject: XML-Data Samples Message-ID: <00102395.3096@datacard.com> Hello all: I am a newbie to XML - I used IBM Alpha XML Parser to work on these following samples (from XML-Data spec). I don't understand what is the context of "schema" in this sample. Is the schema is a XML DTD or just XML file? How do I include it into my XML file? Please enlighten me - I greatly appreciate. SeanN --------------------------------------------------------------- <?xml:namespace name="http://company.com/schemas/books/" as="bk"/> <?xml:namespace name="http://www.ecom.org/schemas/dc/" as="ecom" ?> <bk:booksAndAuthors> <Person> <name>Henry Ford</name> <birthday>1863</birthday> </Person> <Person> <name>Harvey S. Firestone</name> </Person> <Person> <name>Samuel Crowther</name> </Person> <Book> <author>Henry Ford</author> <author>Samuel Crowther</author> <title>My Life and Work Harvey S. Firestone Samuel Crowther Men and Rubber 23.95 -------------------------------------------------------------------- The schema for http://company.com/schemas/books: 1700-01-012100-01-01 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 30 18:53:10 1998 From: SimonStL at classic.msn.com (Simon St.Laurent) Date: Mon Jun 7 17:03:17 2004 Subject: Unparsed entities in well-formed documents Message-ID: XML processors are supposed to notify applications when the name of an external unparsed entity occurs in an attribute of type ENTITY or ENTITIES. That works fine in a validating environment in which you actually have attribute declarations, but well-formed documents may not have that support. Are well-formedness processors supposed to guess about this, or is it just up to the application to figure it out for itself and backtrack to the appropriate entity declaration? (That is, if it cares...) 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 eriblair at mediom.qc.ca Thu Jul 30 19:21:22 1998 From: eriblair at mediom.qc.ca (Eric Riblair) Date: Mon Jun 7 17:03:17 2004 Subject: HELP ME PLEASE: Error when loading applet xmldso of ms Message-ID: <199807301720.NAA19176@netra.mediom.qc.ca> "When" I'd try to load an xmldso applet in an IE4.01 for Mac ... I had a response like this: ---------------------------------------------------------------------------- ---------------------------------------- "An...Error" loading class: com.ms.com.ComSuccessException java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.osp.OLEDBSimpleProvider java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.xml.dso.XMLRowsetProvider java.lang.ClassNotFoundException: com.ms.osp.OLEDBSimpleProvider Error loading class: com.ms.com.ComSuccessException java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.osp.OLEDBSimpleProvider java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.osp.OLEDBSimpleProvider java.lang.ClassFormatError: Invalid class signature. Error loading class: com.ms.xml.dso.XMLRowsetProvider java.lang.ClassNotFoundException: com.ms.osp.OLEDBSimpleProvider java.lang.ClassNotFoundException: com.ms.xml.dso.XMLRowsetProvider at com/ms/vm/loader/URLClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Cla ss; (URLClassLoader.java:0:0x28) at java/lang/ClassLoader.loadClassInternal(Ljava/lang/String;Z)Ljava/lang/Class ; (ClassLoader.java:0:0x1f) at com/ms/xml/dso/SchemaNode.createElement(Z)V (XMLDSO.java:0:0x0) at com/ms/xml/dso/SchemaNode.setRow(Lcom/ms/xml/util/Name;)Lcom/ms/xml/dso/Sche maNode; (XMLDSO.java:0:0xc) at com/ms/xml/dso/XMLDSO.generateSchema(Lcom/ms/xml/om/Element;Lcom/ms/xml/dso/ SchemaNode;)V (XMLDSO.java:0:0x32) at com/ms/xml/dso/XMLDSO.updateSchema()V (XMLDSO.java:0:0x6a) at com/ms/xml/dso/XMLDSO.init()V (XMLDSO.java:0:0xf0) at com/ms/jam/AppletPanel.doAppletInit()V (AppletPanel.java:0:0x35) at com/ms/jam/AppletPanel.doAppletStateChange(I)V (AppletPanel.java:0:0x2f) at com/ms/jam/AppletViewerPanel.runApplet()V (AppletViewerPanel.java:0:0xba) at com/ms/jam/JAMAppletViewer.run()V (JAMAppletViewer.java:0:0x7) at java/lang/Thread.run()V (Thread.java:0:0x10) Does that mean anything to someone in this list ... Thanks for any help, Eric xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Thu Jul 30 19:23:15 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:17 2004 Subject: SAX: two alternatives for namespaces In-Reply-To: <199807291233.IAA00220@unready.megginson.com> Message-ID: On Wed, 29 Jul 1998, David Megginson wrote: > This leads to another thought -- that we probably need some kind of a > hook for requesting and/or querying parser features. This issue came I would disagree, somewhat. Although I think it would be usefull, I will go with Ron Bourret and say that I would rather see a standard set of features supported by SAX parsers. I would imagine that the vast majority of SAX applications will not have to do runtime introspection of a parser, but will rather be written, tested, and shipped using a certain processor which supports the applications needed features. There will always be features SAX won't support, and people can use the processors native API's to access them. I think there will soon be enough XML processors out there that full SAX support will be a good way to differentiate. Done think of the current SAX as version 1, think of it as level 1, and the next version can be level 2, if you want to advertise level 2 SAX support in your processor, then you have to support all it's features, such as namespaces, else you can just support level 1. Level 3 could be support for DOM/RDF/XLL/XSL/XSchema extensions or whatever. Make the processor writers work harder to make things simpler for the users, because in the end it is the users writing applications who will spend more time with SAX. Now, on the other hand... All that worries me about querying for features is that they will become too fine grained. How about seprate SAX API's for all the different areas of XML, rather than one big one. Ie, a SAX API for all parsers supporting DOM, something like: public interface DOMFactory { public void buildDOM(boolean build); public Document getDocument(); // The above Document is live unless parse has returned } And then one could query to see if this interface is supported. The thing being that if you implement an interface, you should have to support all of it. I have been trying to think of a clean way to support namespaces without having to change the current SAX (Level 1) spec. How about an interface that works similar to Locator: public interface NameSpace { String getNameURI(); } Whenever a parser supporting namespaces calls your Document/DTD Handler you would be able to call getNameURI() (implemented by the parser) during the scope of that method. AttributeList could be extended to implement this interface as well. --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From maillist at chris.hubick.com Thu Jul 30 19:38:46 1998 From: maillist at chris.hubick.com (Chris Hubick) Date: Mon Jun 7 17:03:18 2004 Subject: SAX: two alternatives for namespaces In-Reply-To: Message-ID: On Thu, 30 Jul 1998, Chris Hubick wrote: > I have been trying to think of a clean way to support namespaces > without having to change the current SAX (Level 1) spec. How about an > interface that works similar to Locator: > > public interface NameSpace { > > String getNameURI(); > > } Actually, the Handler would have to still receive the fully qualified base+uri name as before, so make that: public interface NameSpace { String getNameBase(); String getNameURI(); } --- Chris Hubick mailto:chris@hubick.com http://www.hubick.com/ xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From dbyron at coactive.com Thu Jul 30 19:57:55 1998 From: dbyron at coactive.com (David Byron) Date: Mon Jun 7 17:03:18 2004 Subject: C/C++ in XML Message-ID: <3.0.5.32.19980730105617.009ad100@refuge> Hi, I'm looking for a way of representing C/C++ data types in XML. I've been searching around on the web and found references to some existing XML that does this, but I haven't found the document itself. Can someone give me a hand with this? Thanks much. -DB --- David Byron dbyron@coactive.com Coactive Networks, Inc. http://www.coactive.com 4000 Bridgeway, Suite 303 voice:(415)289-1722 Sausalito, CA 94965 fax:(415)289-1320 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From psantos at sibs.mailcom.pt Thu Jul 30 21:41:11 1998 From: psantos at sibs.mailcom.pt (Paulo Santos) Date: Mon Jun 7 17:03:18 2004 Subject: Microsoft XML Message-ID: <199807301938.UAA24796@edi.van> Hi!!! I'm using the latest XML Parser in Java of Microsoft in Explorer 4.01 with scripting in JScript inside HTML. Can anyone send me a example of creating a empty element and putting them inside another element??? I want to create lines 17 and 18 (see the model) and I don't know how. Send me similar examples. 1 2 3 4 < ... 5 < ... 6

8 < ... 9 < ... 10 < ... 11 12 13 14 15 16 17
18 19 20 21 22 Thanks in advance, Paulo Santos xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Thu Jul 30 21:52:29 1998 From: lisarein at finetuning.com (Lisa Rein) Date: Mon Jun 7 17:03:18 2004 Subject: Microsoft XML References: <199807301938.UAA24796@edi.van> Message-ID: <35C0D736.408230B6@finetuning.com> For one thing: cool it with those lousy abbreviated end tags!!! Paulo Santos wrote: > > Hi!!! > > I'm using the latest XML Parser in Java of Microsoft in Explorer > 4.01 with scripting in JScript inside HTML. > Can anyone send me a example of creating a empty element and putting > them inside another element??? > > I want to create lines 17 and 18 (see the model) and I don't know > how. Send me similar examples. > > 1 > 2 > 3 > 4 < ... > 5 < ... > 6
7 > 8 < ... > 9 < ... > 10 < ... > 11 > 12 > 13 > 14 > 15 > 16 > 17
> 18 > 19 > 20 > 21 > 22 > > Thanks in advance, > > Paulo Santos > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From roddey at us.ibm.com Thu Jul 30 23:30:29 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:18 2004 Subject: API versioning in SAX Message-ID: <5030300023553373000002L032*@MHS> This leads to another thought -- that we probably need some kind of a hook for requesting and/or querying parser features. This issue came up before during the initial SAX 1.0 design. Something like the following might be appropriate: package org.xml.sax; public interface Parser { ... public boolean hasFeature (String featureName); public boolean requestFeature (String featureName, boolean status); } It is important to note that with such an approach, there would have to be a registry of feature names in addition to the SAX interface. Wouldn't it be better to just allow the current API version to be queried? The above scheme would probably encourage a little too much "a la carte' type of feature support, wouldn't it? If you allow stick to being able to query what level of the API the parser supports, that would be a simpler, cleaner way to know whether the underlying parser can do what you need to do. Just a thought... ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From jctsai at fedex.com Fri Jul 31 00:06:35 1998 From: jctsai at fedex.com (January Tsai) Date: Mon Jun 7 17:03:18 2004 Subject: API versioning in SAX Message-ID: <199807302206.AA18303@gateway.fedex.com> I just started leaning XML so correct me if I'm wrong here. I think it's a great idea! Since SAX is actually a SIMPLE API for XML, it helps a lot if we have some functions like: public String getValue( String ItemName, String DocumentName, ... ); public boolean putValue( String Value, String ItemName, String Document...); Just compare to those registry access functions, they are very handy. :) ---------------------------------- January Tsai FedEx - Power Ship at Dallas jctsai@fedex.com -----Original Message----- From: Dean Roddey [SMTP:roddey@us.ibm.com] Sent: Thursday, July 30, 1998 4:37 PM To: xml-dev@ic.ac.uk Subject: API versioning in SAX This leads to another thought -- that we probably need some kind of a hook for requesting and/or querying parser features. This issue came up before during the initial SAX 1.0 design. Something like the following might be appropriate: package org.xml.sax; public interface Parser { ... public boolean hasFeature (String featureName); public boolean requestFeature (String featureName, boolean status); } It is important to note that with such an approach, there would have to be a registry of feature names in addition to the SAX interface. Wouldn't it be better to just allow the current API version to be queried? The above scheme would probably encourage a little too much "a la carte' type of feature support, wouldn't it? If you allow stick to being able to query what level of the API the parser supports, that would be a simpler, cleaner way to know whether the underlying parser can do what you need to do. Just a thought... ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 31 00:25:37 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:18 2004 Subject: API versioning in SAX In-Reply-To: <199807302206.AA18303@gateway.fedex.com> Message-ID: <3.0.1.16.19980730232513.35678e42@pop3.demon.co.uk> At 17:10 30/07/98 -0500, January Tsai wrote: >I just started leaning XML so correct me if I'm wrong here. > >I think it's a great idea! You're right - it is. It takes a little while to learn everything about it :-). > >Since SAX is actually a SIMPLE API for XML, >it helps a lot if we have some functions like: It's important that you read the spec (REC-xml-19980210) and get the terminology right. The basic unit of XML is an Element (not an Item) and since Elements can contain other Elements you can't just get a String Value. > >public String getValue( String ItemName, String DocumentName, ... ); >public boolean putValue( String Value, String ItemName, String Document...); SAX is not an editor or authoring tool so you can't use it to add data. > >Just compare to those registry access functions, >they are very handy. I think you'll find that actually using SAX-based parsers is quite a good way to get to know XML. There are now many examples and most of them have simple test routines that will give you some idea of what is going on. Also if you go to the 'XML Home Page' (http://www.sil.org/sgml/xml.html) you'll find lots of good material or the FAQ (http://www.ucc.ie/xml). P. [Also on XML-DEV we try to avoid copying the whole of the message to which we are Reply-ing.] 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 amitr at abinfosys.com Fri Jul 31 09:00:42 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:03:18 2004 Subject: How do browsers (IE4.01) trap XML streams coming from server? Message-ID: <003e01bdbc51$2824b8b0$0101a8c0@server.abinfosys.com> Hello, Is IE 4.01 capable of trapping XML streams and processing them using XSL as they come from the server? (just as it traps and processes HTML streams from the server). I am in the process of building an XML enabled server side application which will talk to SQL server(6.5) tables and facing such a problem. My ENVIRONMENT is :- * OS :- Windows NT Server 4.0 * Scripting Evnvironment :- ASP * Scripting Language :- VBScript * Client Browser :- IE 4.01 * Web Server :- IIS 4.0 * Database Server :- SQL Server 6.5 I am trying to incorporate the following functionalities to the application in the following manner:- FUNCTION 1 :- The application should be able to construct XML data sources from the data stored in the SQL tables. IMPLEMENTATION OF FUNCTION 1:- I am using ASP (ADO objects within ASP) to construct XML data sources within ASP pages.A code snippet is :- . . <%@ LANGUAGE = VBScript %> <% Set Conn = Server.CreateObject("ADODB.Connection") Conn.Open "TABLE1" Set RS = Conn.Execute("select * from TABLE1") Do while not RS.EOF %> <%= RS("Field1") %> <%= RS("Field1") %> <% RS.MoveNext Loop %> FUNCTION 2 :- The server application should send the XML data source constructed in the ASP as an XML stream to the client browser. IMPLEMENTATION OF FUNCTION 2:- Sending the XML stream back to the client browser is easily achievable through ASP. But the problem is in trapping the XML stream by the client browser. Just like in a normal HTML interaction , the server sends an HTML stream back, which the client browser traps and displays , the same mechanism should also hold if one plans to send an XML stream back. Based on the above content here are my questions :- 1) Does IE 4.01 trap and process the XML data stream as it arrives from the server? (The way it traps and processes HTML) If so how?If not, how to make it do it? Ideally, an XML data stream is attached with an XSL stylesheet for display purposes, for which the MSXSL processor can be used. 2) How to associate the incoming XML data stream (not a .XML file) from the server with an XSL stylesheet (using MSXSL processor) in IE4.01? Any suggestions would be appreciated, Thanks in advance, AMIT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980731/620c6555/attachment.htm From rbourret at dvs1.informatik.tu-darmstadt.de Fri Jul 31 09:40:06 1998 From: rbourret at dvs1.informatik.tu-darmstadt.de (Ron Bourret) Date: Mon Jun 7 17:03:18 2004 Subject: ParserFilter suggestion Message-ID: <199807310739.JAA11053@berlin.dvs1.tu-darmstadt.de> Currently, SetParser in ParserFilter accepts a single parser. I think this should be a Stack of parsers. Each ParserFilter would set its own parser to the top parser on the stack, pop that off, and pass the rest of the Stack to the next level down. This would allow the application to build a stack of ParserFilters, each performing a different operation. -- 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 graham.moore at dpsl.co.uk Fri Jul 31 11:32:30 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:03:18 2004 Subject: How do browsers (IE4.01) trap XML st Message-ID: > Depending on how much browser side control you require over the XML stream, you could embed the XSL activeX control and script it to fetch data from IIS and the asp's. Just insert the activeX XSLControl into an initial HTML page. Probably a base frame. And on loading, set the URL of the XSLControl.document to be the asp page. Then insert the resulting stylesheeted HTML / XML into the content frame. In addition, calls to other asp pages will have to go via the activeX control. But thats ok as the asp's are generating the content. so it will generate something like onClick="top.XSLControl.documentURL = anotherASP.asp" The style sheet/s can be fetched in a similar. Alternatively you could use the XSLControl on the server, mangle the generated XML with the appropriate style sheet and just send the resulting HTML to the browser from the ASP. I hope this is of help. Graham. xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From amitr at abinfosys.com Fri Jul 31 15:20:49 1998 From: amitr at abinfosys.com (Amit Rekhi) Date: Mon Jun 7 17:03:18 2004 Subject: How do browsers (IE4.01) trap XML streams coming from server? Message-ID: <021c01bdbc86$4224f600$0101a8c0@server.abinfosys.com> Hi! Graham, Thanks for your code, it really helped.But there a few things I could not understand. >so it will generate something like >onClick="top.XSLControl.documentURL = anotherASP.asp" I really could not understand the point you were trying to make here. >Alternatively you could use the XSLControl on the server, mangle the >generated XML with the appropriate style sheet and just send the resulting >HTML to the browser from the ASP. But, following the lines of HTML where the HTML streams are processed on the client end, should not the same also be the case for XML streams and their associated XSL files. By allowing this processing on the server side will not we shifting processing focus from where it traditionally is?(on the client side)Will it right do to so? Thanks, AMIT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19980731/8d5525d7/attachment.htm From graham.moore at dpsl.co.uk Fri Jul 31 16:18:35 1998 From: graham.moore at dpsl.co.uk (Graham Moore) Date: Mon Jun 7 17:03:18 2004 Subject: How do browsers (IE4.01) trap XML st Message-ID: > Hi, This bit is just concerned with fact that if your asp creates a page that has links to other asps on your site, that also generate XML, then you cannot simply have xxxxxxxxx as then the XSL control will not get an opportunity to process it. Therefor any links that an asp page generates will have to make a call to the activeX control. hence xxx The idea of processing on the server was just a suggestion and personally I would not do this as you have then lost the structure that XML provides. The IE5.0 DOM is more generic that ie4.0 and will provide better access to the document structure. graham xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 31 17:34:42 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:18 2004 Subject: API versioning in SAX References: <5030300023553373000002L032*@MHS> Message-ID: <35C1E3FC.7A1D054E@locke.ccil.org> Dean Roddey wrote: > Wouldn't it be better to just allow the current API version to be queried? The > above scheme would probably encourage a little too much "a la carte' type of > feature support, wouldn't it? If you allow stick to being able to query what > level of the API the parser supports, that would be a simpler, cleaner way to > know whether the underlying parser can do what you need to do. No, because even parsers that support level 1 (the current level) may vary in their behavior, because non-validating parsers can produce different things (expand external parsed entities or not, understand ATTLISTs or not, etc.) If your application depends on these things, you need to be able to check whether the parser you are using does so. And I do believe that people will replace parsers, as smaller/faster/ better ones come out, in their applications. A major impetus of Java is to avoid monolithic apps where the user is stuck with the app exactly as packaged. -- 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 Jul 31 17:57:21 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:18 2004 Subject: ParserFilter suggestion References: <199807310739.JAA11053@berlin.dvs1.tu-darmstadt.de> Message-ID: <35C1E932.383BACE5@locke.ccil.org> Ron Bourret scripsit: > Currently, SetParser in ParserFilter accepts a single parser. I think this > should be a Stack of parsers. Each ParserFilter would set its own parser to the > top parser on the stack, pop that off, and pass the rest of the Stack to the > next level down. This would allow the application to build a stack of > ParserFilters, each performing a different operation. That was my intent in making ParserFilter a subinterface of Parser. Here's how an application can do what you want: Parser p; ParserFilter pf; p = new RealParser(); pf = new FooFilter(); pf.setParser(p); p = pf; pf = new BarFilter(); pf.setParser(p); p = pf; pf = new BazFilter(); pf.setParser(p); p = pf; ... If setParser returned "this" rather than void, then you could write the cascade in fewer lines: Parser p = new RealParser(); ParserFilter pf = new FooFilter().setParser(p); pf = new BarFilter().setParser(pf); pf = new BazFilter().setParser(pf); ... p = pf; I will probably make that change to setParser. -- 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 Jul 31 18:53:12 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:18 2004 Subject: LISTRIVIA: Re: How do browsers (IE4.01) trap XML streams coming from server? In-Reply-To: <003e01bdbc51$2824b8b0$0101a8c0@server.abinfosys.com> Message-ID: <3.0.1.16.19980731082725.3567ac50@pop3.demon.co.uk> At 12:32 31/07/98 +0530, [someone] wrote: [... a question - also crossposted to another list ...] > >Attachment Converted: "c:\eudora\attach\Howdobro.htm" And added an ATTACHMENT. We don't do this on XML-DEV. P. Beware the yellow card... 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 Jul 31 18:53:15 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:19 2004 Subject: LISTRIVIA YELLOW CARD (was Re: How do browsers (IE4.01) trap XML streams coming from server?) In-Reply-To: <003e01bdbc51$2824b8b0$0101a8c0@server.abinfosys.com> Message-ID: <3.0.1.16.19980731175327.381722fe@pop3.demon.co.uk> At 12:32 31/07/98 +0530, Amit Rekhi wrote: [... a posting to XML-DEV ...] >Attachment Converted: "c:\eudora\attach\Howdobro.htm" accompanied by an attachment which appeared on the hypermailer as: ------=_NextPart_000_0039_01BDBC7F.3C1D65F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, &nbs= p; =20 Is IE 4.01 capable of trapping XML streams and processing them using = XSL as=20 they come from the server? (just as it traps and processes = HTML streams from=20 the = server). &nb= sp;=20 I am in the process of building an XML enabled server = side application which=20 will talk to SQL server(6.5) tables and facing such=20 a problem. &n= bsp; =20 My ENVIRONMENT is=20 :- &nb= sp; =20 * OS :- Windows NT Server=20 4.0 = =20 * Scripting Evnvironment :-=20 ASP = =20 * Scripting Language :-=20 VBScript [... many more lines of total garbage deleted ...] On 1998-07-10 I wrote: >At 18:42 10/07/98 +0530, [a poster] wrote: >[...] >> >> >>Attachment Converted: "c:\eudora\attach\MergingO.htm" >Please try to avoid attachments of any sort on this list. Thanks. and on 1998-07-13 I also posted (with a slight hint of impatience): >At 10:24 13/07/98 +0530, Amit Rekhi wrote: >[... about 30 words to XML-DEV ...] >and then copied about 100 lines of previous material, quite unnecessarily >> >AMIT >> >>Attachment Converted: "c:\eudora\attach\ReMergi1.htm" >and then duplicated it all in an HTML message. >This represents an information content of about 1%, the rest being dross >that I have to pay for. >Given that I have posted twice about this in the last few days I regard >this as discourteous to me and the list members. I do not normally >name-and-shame and I hope I don't have to again. You [Amit Rekhi] either do not read what I post to you, or do not care about me and the other members of this list or are unable to control what your mailer emits. I hope it is the latter. If you are unable to control a mailer you are going to find it difficult to participate effectively in XML work. I don't like writing this sort of message, but I cannot allow this sort of pollution on XML-DEV. I hope you understand the term "yellow card" - i.e. if you continue with this we shall have no option but to unsubscribe you. I am sure it won't come to that. There are lots of place on the WWW where you can find out about mailers (*NOT* XML-DEV). 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 roddey at us.ibm.com Fri Jul 31 19:32:50 1998 From: roddey at us.ibm.com (Dean Roddey) Date: Mon Jun 7 17:03:19 2004 Subject: Translating from schema to classes Message-ID: <5030300023584109000002L092*@MHS> "I'm looking for a way of representing C/C++ data types in XML. I've been searching around on the web and found references to some existing XML that does this, but I haven't found the document itself. Can someone give me a hand with this?" This is related to something I was thinking about the other day. If I'm going to write some code to manipulate very 'record oriented' XML data, I'd often end up having a class that represents the records, into which I load the data after parsing it in. One thing that would greatly ease the job of doing this would be a program that would take an XML schema, a translation file, and spit out a class that represents the schema (with getters/setters/serialization/etc... appropriate for the language and library.) It could also automatically spit out a method that would (given a DOM fragment of that record type), suck out the data for that XML record into itself (and vice versa to update the DOM fragment to represent itself again. The translation obviously could also be an XML file in which a set of tags are defined that allow the translation to be customized, for instance a type mapping tag that says any type foo:int should map to tCIDLib::TInt4 or something like that. So, when the XML changes, I can just rerun the translator and spit out the new class. Any added value I would just provide in a derived class, so that the underlying data management class can be spit out as required, without losing any of my code. You could do a translation file for Java, for C++ STL, I could do one for my CIDLib libraries, etc... Is anyone doing something like this? Or is this just another dumb idea (something I'm good at :-) It almost enough trouble to do a translation file that it wouldn't be worth it unless you had a lot of different XML data records and/or a lot of different languages to spit out representations for. But the ability to spit out a method automatically to pull out the data into/outof the record would be nice in many cases. Just a thought anyway... ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From anderst at toolsmiths.se Fri Jul 31 19:56:33 1998 From: anderst at toolsmiths.se (Anders W. Tell) Date: Mon Jun 7 17:03:19 2004 Subject: Translating from schema to classes References: <5030300023584109000002L092*@MHS> Message-ID: <35C20558.935CA6D7@toolsmiths.se> Have a look at which is UML expressed in XML. /anders Dean Roddey wrote: > "I'm looking for a way of representing C/C++ data types in XML. > I've been searching around on the web and found references > to some existing XML that does this, but I haven't found the > document itself. Can someone give me a hand with this?" > > This is related to something I was thinking about the other day. If I'm going > to write some code to manipulate very 'record oriented' XML data, I'd often end > up having a class that represents the records, into which I load the data after > parsing it in. One thing that would greatly ease the job of doing this would be > a program that would take an XML schema, a translation file, and spit out a > class that represents the schema (with getters/setters/serialization/etc... > appropriate for the language and library.) It could also automatically spit out > a method that would (given a DOM fragment of that record type), suck out the > data for that XML record into itself (and vice versa to update the DOM fragment > to represent itself again. > > The translation obviously could also be an XML file in which a set of tags are > defined that allow the translation to be customized, for instance a type > mapping tag that says any type foo:int should map to tCIDLib::TInt4 or > something like that. > > So, when the XML changes, I can just rerun the translator and spit out the new > class. Any added value I would just provide in a derived class, so that the > underlying data management class can be spit out as required, without losing > any of my code. You could do a translation file for Java, for C++ STL, I could > do one for my CIDLib libraries, etc... > > Is anyone doing something like this? Or is this just another dumb idea > (something I'm good at :-) It almost enough trouble to do a translation file > that it wouldn't be worth it unless you had a lot of different XML data records > and/or a lot of different languages to spit out representations for. But the > ability to spit out a method automatically to pull out the data into/outof the > record would be nice in many cases. > > Just a thought anyway... > > ---------------------------------------- > Dean Roddey > Software Weenie > IBM Center for Java Technology - Silicon Valley > roddey@us.ibm.com > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ > To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 31 21:08:07 1998 From: peter at ursus.demon.co.uk (Peter Murray-Rust) Date: Mon Jun 7 17:03:19 2004 Subject: LISTRIVIA [Re: Translating from schema to classes] In-Reply-To: <35C20558.935CA6D7@toolsmiths.se> References: <5030300023584109000002L092*@MHS> Message-ID: <3.0.1.16.19980731200826.39277f0a@pop3.demon.co.uk> Please try to keep this list free of lowgrade bytes At 19:56 31/07/98 +0200, [ a poster wrote] wrote: >Have a look at >which is UML expressed in XML. > [... and then followed it by 100 lines of quoted material for which I and many others have to download even though we have already stored it and it is hypermailed. I have to *pay* for it.] If you are new to this list [or if you aren't], please make sure that you adhere to the guidelines: - quote only what is necessary - attach nothing 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 Don.Schaefer at usa.xerox.com Fri Jul 31 22:15:30 1998 From: Don.Schaefer at usa.xerox.com (Schaefer, Don) Date: Mon Jun 7 17:03:19 2004 Subject: Translating from schema to classes Message-ID: <67E29010AC4BD111955E00805F0DBA3178E231@station10.roch875.mc.xerox.com> Good topic.... Is this an instance of the chicken and the egg? Meaning I use Rational Rose to to my modelling. It generates code for all sorts of languages and it all stems from UML. Should/could/can rose render a schema would be my question. Whichever direction you choose its an important discussion... As it is now I could work from three different fronts: XML IDL UML.... These are all different avenues with a great amount of cross over. Rose already generates idl. An idl compiler generates my language interface. Maybe I should work from the idl..... I hope that this reply is not tooo far out of context for this list. don. Don Schaefer Questra Consulting Rochester NY, 14625 dschaefer@questra.com ---------- From: Dean Roddey[SMTP:roddey@us.ibm.com] Reply To: Dean Roddey Sent: Friday, July 31, 1998 1:39 PM To: xml-dev@ic.ac.uk Subject: Translating from schema to classes "I'm looking for a way of representing C/C++ data types in XML. I've been searching around on the web and found references to some existing XML that does this, but I haven't found the document itself. Can someone give me a hand with this?" This is related to something I was thinking about the other day. If I'm going to write some code to manipulate very 'record oriented' XML data, I'd often end up having a class that represents the records, into which I load the data after parsing it in. One thing that would greatly ease the job of doing this would be a program that would take an XML schema, a translation file, and spit out a class that represents the schema (with getters/setters/serialization/etc... appropriate for the language and library.) It could also automatically spit out a method that would (given a DOM fragment of that record type), suck out the data for that XML record into itself (and vice versa to update the DOM fragment to represent itself again. The translation obviously could also be an XML file in which a set of tags are defined that allow the translation to be customized, for instance a type mapping tag that says any type foo:int should map to tCIDLib::TInt4 or something like that. So, when the XML changes, I can just rerun the translator and spit out the new class. Any added value I would just provide in a derived class, so that the underlying data management class can be spit out as required, without losing any of my code. You could do a translation file for Java, for C++ STL, I could do one for my CIDLib libraries, etc... Is anyone doing something like this? Or is this just another dumb idea (something I'm good at :-) It almost enough trouble to do a translation file that it wouldn't be worth it unless you had a lot of different XML data records and/or a lot of different languages to spit out representations for. But the ability to spit out a method automatically to pull out the data into/outof the record would be nice in many cases. Just a thought anyway... ---------------------------------------- Dean Roddey Software Weenie IBM Center for Java Technology - Silicon Valley roddey@us.ibm.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to 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 Jul 31 22:48:42 1998 From: cowan at locke.ccil.org (John Cowan) Date: Mon Jun 7 17:03:19 2004 Subject: SAX, non-validating parsers, and external parsed entity references Message-ID: <35C22D8D.D14B1294@locke.ccil.org> There seems to be no way for a SAX-compliant parser that does *not* expand external parsed entity references (as explicitly permitted in clause 5.1, to report that it has encountered one. Thus, given an resource with the URI "foo" whose content is "", and a document as follows: ]>
This document is a &foo;
a conformant parser may return either of the following event streams: startDocument(); startElement("MAIN"); characters("\tThis document is a "); startElement("TEST"); endElement("TEST"); characters("\n"); endElement("MAIN"); endDocument(); or startDocument(); startElement("MAIN"); characters("\tThis document is a "); characters("\n"); endElement("MAIN"); endDocument(); Parsers of the first kind cannot even report that they have left something out! This seems to me to be a substantial deficiency in SAX. -- 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.V.Biron at kp.ORG Fri Jul 31 22:50:53 1998 From: Paul.V.Biron at kp.ORG (Biron,Paul V) Date: Mon Jun 7 17:03:19 2004 Subject: xml parser toolkits for "legacy" environment? Message-ID: <35c22d344f40004@laurel.kp.org> All of the XML parser toolkits I know about (i.e., all those listed in the Whirlwind Guide plus a few others) are written in "modern" languages (Java, C++, C, perl, etc.) Is anyone out there working on tools that would allow someone who is confined to "legacy" environments (COBOL, FORTRAN, etc. for programming languages and MUMPS, OS/400, MVS, etc. for operating systems) to use XML? In the (US) healthcare domain, these environments are very much still big players. Anyone working on freely redistributable toolkits for these environments would be doing the "world" a great favor; anyone working on commerically available toolkits would make a fortune! Any pointers that I can get to existing code or development efforts greately appreciated. > Paul V. Biron > Paul.V.Biron@kp.org > SGML Business Analyst 626-685-3529 > (voice) > Permanente Clinical Systems Development 626-685-3566 (fax) > Kaiser Permanente 626-527-1050 > (pager) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@ic.ac.uk the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk) From Patrice.Bonhomme at loria.fr Fri Jul 31 23:32:20 1998 From: Patrice.Bonhomme at loria.fr (Patrice Bonhomme) Date: Mon Jun 7 17:03:20 2004 Subject: ANN : Silfide XML Parser in Java - 0.7 Message-ID: <199807312130.XAA05420@chimay.loria.fr> The Silfide Working Group is happy to announce the availability of the Silfide XML Parser (SXP, v0.7 - Fri Jul 31 1998 ), a validating XML Parser writing in Java. The SXP entirely implements the XML 1.0 recommendation and most of its satellite recommendations: - XML Namespaces (WD 18-05-1998) - Document Object Model Level 1 (DOM Core and XML, WD 20-07-1998) - XPointer (WD 03-03-1998) - XLink (WD 03-03-1998) SXP provides also a driver for the SAX interface (fr.loria.xml.sax.SAXDriver). Both of the XML and XPointer parsers are developed with the tool JavaCC. SILFIDE is a project of CNRS and AUPELF-UREF. Server SILFIDE, as an interactive server, wants to offer to the whole of the French-speaking university community working starting from the language (linguists, teachers, data processing specialists...) a tool user-friendly and reasoned for the handling of electronic resources. A more detailed description of the Silfide project is available here: http://www.loria.fr/projets/XSilfide/ Java source files, java classes, some samples and documentation are freely available here: http://www.loria.fr/projets/XSilfide/EN/sxp/ We are waiting for all of your comments, questions and suggestions. 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)