OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: No Subject


"If the system identifier is a URN in the publicid namespace, it is
converted into a public identifier by "unwrapping" the URN. In this =
case,
one of the following must apply:

1. No public identifier was provided. Resolution continues as if the =
public
identifier constructed by unwrapping the URN was supplied as the =
original
public identifier and no system identifier was provided.

2. The normalized public identifier provided is lexically identical to =
the
public identifier constructed by unwrapping the URN. Resolution =
continues as
if the system identifier had not been supplied.

3. The normalized public identifier provided is different from the =
public
identifier constructed by unwrapping the URN. This is an error. =
Applications
may recover from this error by discarding the system identifier and
proceeding with the original public identifier."


So the following DOCTYPE declaration should amount to not specifying a
system identifier:

<!DOCTYPE article PUBLIC
  "-//OASIS//DTD DocBook XML V4.1.2//EN"
  "urn:publicid:-:OASIS:DTD+DocBook+XML+V4.1.2:EN">


BTW, early drafts of the XML Catalog spec suggested that XML Catalog
resolvers should be expected to look after a default catalog, located =
as a
relative URI to the document being processed [2]. This was removed =
because,
as Daniel Veillard states it [3], "... having to make an URI reference
lookup based on the resource one want to fetch to guess if there is a
catalog associated is not scalable, not secure and not something I ever =
want
to implement. At least I can trust /etc/xml/catalog and load it once =
for the
full lifetime of my application."=20

My conclusion: If you must rely on resolving entities via canonical =
URLs
over the internet, you are in for all kinds of trouble. Better take the
trouble to set up local entity resolution.

[1]
http://www.oasis-open.org/committees/entity/specs/cs-entity-xml-catalogs=
-1.0
.html#s.ext.input
[2]
https://lists.dulug.duke.edu/pipermail/lsb-xml-sgml/2002-August/000265.h=
tml
[3]
https://lists.dulug.duke.edu/pipermail/lsb-xml-sgml/2002-August/000266.h=
tml


kind regards
--=20
      \|/
     <@ @>         Peter Ring
+-oOO-(_)-OOo---------------------------
|         Address  Pal=E6gade 4
|                  P.O.Box 9026
|                  DK-1022 K=F8benhavn K
|         Phone    +45 3396 0153
|         Fax      +45 3396 0101
|         EMail    pri@magnus.dk
|         WWW      www.magnus.dk

-----Original Message-----
From: Oliver Fischer [mailto:plexus@snafu.de]
Sent: 6. maj 2003 21:26
To: Jirka Kosek
Cc: Peter Ring; docbook@lists.oasis-open.org
Subject: Re: [docbook] URN for Simplified DocBook and DocBook XML


Jirka Kosek wrote:

> Using URN is a very good practise in many places (e.g. namespace=20
> identifiers) but not in system identifiers. System identifier must be =

> always resolvable, and this can't be guaranteed with URN.

According to the standard is a URN also a valid URI - IMHO. Or did I=20
misinterpret the docs I read? A SystemLiteral is URI and both URL=20
and URN are URIs. So why not use a URN als SystemLiteral?

I could use catalog files to resolve the URN. Or not?

MfG

--=20

Oliver Fischer

--[ Oliver Fischer ]-[ plexus@snafu.de ]---------------------------
Technologie des letzten Jahrtausends? Das Internet!
http://www.xshare.com


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]