RE: First editing pass online

["Leland, David" <David.Leland@informa.com>]

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.
**********************************************************************