[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: First editing pass online
Hi Norm; >A DTD is just a collection of declarations, I don't think I'm missing any. For the systems that we use, there have to be 1. a container on the dtds, 2. a name of the dtd and version number. 3. I was expecting that the last fortnight's work would result in a clearer definition of the uriReference than just having it be CDATA ><!DOCTYPE declaration? Those don't appear in DTDs just instances. They appear in the *dtds* that I have seen have used '<!DOCTYPE ... [', been given, used and written at Xerox, the Financial Times and Informa. There are still a number of systems out here that expect that information to appear. True, other dtds are used starting with '<!VERSION ...[' >attributes. What ambiguity do you see? I'm expecting to see some of result from the two weeks of discussion (thread ='locating schema via public ids'), where we discussed the need for the attributes fo the reference that has become '%uriReference'. Especially, I can recall the point that Paul made on 23 Jan 2001, where he said that 'The problem is that each member of schemaLocation and the value of noNamespaceSchemaLocatin is required to be a URI.' and again on 24 Jan 2001; 3:42 PM, saying '...But the point is that we need some way for the schemaLocation to specify both the public id and the system id, just like the doctype decl of XML can do for a DTD'. Tell me that I'm completely wrong, but I do not see that the reference to the uri of the schema is required to be anything at all other than CDATA in the dtd that has been included in the xmlcat? Regards, David Leland -----Original Message----- From: Norman Walsh [mailto:ndw@nwalsh.com] Sent: Friday, February 02, 2001 12:25 PM To: entity-resolution@lists.oasis-open.org Subject: Re: First editing pass online Hi David, I'm a little confused by your comments. / "Leland, David" <David.Leland@informa.com> was heard to say: | The dtd as given is a fragment, A DTD is just a collection of declarations, I don't think I'm missing any. | lacking the document declaration, and a do you mean the <!DOCTYPE declaration? Those don't appear in DTDs just instances. | container. Secondly, '%uriReference;' is not defined as a parameter entity | with an attlist, so our recommendation will have an ambiguity. The uriReference PE is defined: <!ENTITY % uriReference "CDATA"> It's just a data type (for an attribute), not an element, so it doesn't have any attributes. What ambiguity do you see? | On another suject, that of the path identifier, would it not be better to | state that the search path for the catalog resource to be: | | 'catalogueOwnerURI, catalogueServerLocationURI, catalogueOffsetURI' | | [so that the hints about the catalog are included in the name of the | resource] I don't think so. The way resources are identified on the web is via URI. Making the uriReference an element with attributes doesn't make sense unless you plan to make the URI attribute a sub-element and I would really rather not. (It's much, much easier in a SAX-driven parser to deal with empty elements that have attributes than it is to deal with sub-element structure.) Even if we did want to make it a sub-element, I don't see what benefit we'd get from breaking it into pieces. Instead of uri="http://www.oasis-open.org/docbook/catalog", what do you imagine? | instead of: | | 'publicIdentifier, partialPublicIdentifier' | | The two issues may be handled together: | | ***************************** | <!-- catalog resourced names include the hint about location.--> Catalogs *are not* hints. They are assertions of fact: this resource is available *there*. | <!ELEMENT %uriReference; EMPTY> | <!ATTLIST &uriReference; | catalogueOwnerURI CDATA #REQUIRED | catalogueServerLocationURI CDATA #REQUIRED | catalogueOffsetURI CDATA #REQUIRED > | ***************************** And I'm even more confused now. The publicIdentifier and partialPublicIdentifer have nothing to do with URIs. It's early in the morning, maybe I'm not awake yet. Can you explain in a little more detail? Be seeing you, norm -- Norman.Walsh@East.Sun.COM | To create a little flower is the labour Technology Development Group | of ages.--Blake Sun Microsystems, Inc. | ********************************************************************** This electronic transmission and any files attached to it are strictly confidential and intended solely for the addressee. If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this transmission. If you have received this transmission in error, please notify us by return and delete the same. Further enquiries/returns can be posted to postmaster@informa.com Thank you. **********************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC