You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Jeff Turner <je...@apache.org> on 2002/12/14 06:54:17 UTC
[PROPOSAL] DTD Versioning (Re: Should href be required on link)
On Fri, Dec 13, 2002 at 04:46:32PM +0100, Keiron Liddle wrote:
> Hi all,
>
> Shouldn't the href attribute on a link (or jump, fork) be required.
>
> In other words what is a link that points to nowhere.
Interesting.. I wonder if the original DTD author was pasting from XLink or
something.
> Anyway it causes an error with Fop.
Do you mean, in FOP, someone wrote <link/> and wondered why it broke? :)
What was the error?
This is a backwards-incompatible change, and a good time to decide on a
decent DTD versioning policy. Our DTDs haven't changed since 0.2 was
released, but there are a stack of proposed modifications
(etc/DTD_DEFICIENCIES.txt).
So far, I think we've had a loose understanding that the filename and
PUBLIC id must change on large or backwards-incompatible changes.
The problem with this is that a PUBLIC id then refers to a small family
of DTDs, not a single DTD. If a document makes use of a new element or
attribute added in a later version of a DTD, it will break with earlier
versions.
Most DTD publishers don't have this problem. A bunch of OASIS people go
into a room and emerge saying "behold! Docbook 4.1.2".
Seems the only safe solution is to create a new DTD (and public
identifier) for each DTD version. This isn't as horrible as it sounds..
Say we decide to add XInclude elements and attributes to document-v11. We
create a new file, document-v11-1.dtd, which inherits and overrides
document-v11.mod as follows:
<!ENTITY % document PUBLIC
"-//APACHE//ENTITIES Documentation V1.1//EN"
"document-v11.mod">
<!-- Override entities so that 'xi:include' and 'xmlns:xi' are allowed in
content -->
<!ENTITY % local.sections "|xi:include">
<!ENTITY % local.inline "|xi:include">
<!ENTITY % common.att 'id ID #IMPLIED
xml:lang NMTOKEN #IMPLIED
xmlns:xi CDATA #IMPLIED'>
<!-- Pull in document-v11.mod contents -->
%document;
<!-- Declare new elements -->
<!ELEMENT xi:include EMPTY>
<!ATTLIST xi:include
href CDATA #REQUIRED>
Then in the catalog, we first declare our new v11-1 DTD:
PUBLIC "-//APACHE//DTD Documentation V1.1.1//EN" "dtd/document-v11-1.dtd"
And then we map the OLD public identifier to the new DTD:
PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "dtd/document-v11-1.dtd"
This gives doc publishers a choice; they can either tie their docs to a
specific DTD with the PUBLIC id '-//APACHE//DTD Documentation V1.1.1//EN', or
they can use the looser id '-//APACHE//DTD Documentation V1.1//EN', which
allows them to use new features and bugfixes in the 1.1 series as they appear.
What do people think?
--Jeff
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by Joerg Pietschmann <j3...@yahoo.de>.
On Saturday 14 December 2002 06:54, you wrote:
> Do you mean, in FOP, someone wrote <link/> and wondered why it broke? :)
I've put quite a few <link> without hrefs into the FOP FAQ,
to be completed later. I didn't wonder why it broke though.
J.Pietschmann
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by Steven Noels <st...@outerthought.org>.
David Crossley wrote:
> The secondary catalog using view-cvs means that they do
> not need to touch their xml instances, just load the
> additional catalog.
The funny thing about http/viewcvs entries in catalogs for older
versions is that the current resolver library breaks when it isn't able
to fetch a DTD across HTTP, e.g. when behind a proxy, even when you
don't need that specific DTD. It apparently tries to load/locate all
catalog entries upon initialization.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by David Crossley <cr...@indexgeo.com.au>.
Peter B. West wrote:
<snip/>
> If the catalog requires a network connection, do you need it? When
> Keiron and Victor started using Forrest for FOP, they used view-cvs
> checkout URIs as the system ids to access particular versions. If the
> "old stuff" has system ids that directly access the files in cvs, won't
> the absence of a catalog public resolver trigger access through the
> system id?
You are right. However that does not cater for projects
that were quite happily using the production DTDs for
Forrest and its catalog to resolve to local DTD copies.
When Forrest updates to new DTDs then their project would
suddenly break.
The secondary catalog using view-cvs means that they do
not need to touch their xml instances, just load the
additional catalog.
--David
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeff Turner wrote:
> On Thu, Dec 19, 2002 at 07:47:52PM +1100, David Crossley wrote:
>
>>Jeff Turner wrote:
>
> ...
>
>>>PUBLIC "-//APACHE//DTD Documentation//EN" "dtd/document-v11-3-1.dtd"
>>>PUBLIC "-//APACHE//DTD Documentation V1//EN" "dtd/document-v11-3-1.dtd"
>>>PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "dtd/document-v11-3-1.dtd"
>>>PUBLIC "-//APACHE//DTD Documentation V1.1.3//EN" "dtd/document-v11-3-1.dtd"
>>>PUBLIC "-//APACHE//DTD Documentation V1.1.3.1//EN" "dtd/document-v11-3-1.dtd"
>
> ...
>
>>Great idea to use the OASIS catalog to manage this.
>>
>>How do we cope when it gets cumbersome? How many
>>dtd revisions do we keep track of in the catalog
>>and in cvs.
>>
>>Again, catalogs to the rescue. We could have a main catalog
>>to declare the recent identifiers, then a separate catalog
>>for the old stuff. This second one would not be used by
>>default Forrest, but would be available to them if they
>>need it. We already provide ways to load other catalogs.
>
>
> Good idea.
>
> Might be best to wait for Steven to get back before trying this.. there
> are some unresolved issues on how DTD changes are made.
>
>
> --Jeff
>
>
>>The secondary catalog could utilise Steven's idea of
>>linking to cvs.apache.org for the systemIdentifiers.
>>
>>I know that we are using OASIS catalogs and entity resolver
>>to avoid the dependency on a network connection to get the
>>resource. However, these are way out-of-date DTDs that we
>>are talking about. If users are concerned, then they can
>>download a local copy of the old DTD and adjust their
>>OASIS catalog.
If the catalog requires a network connection, do you need it? When
Keiron and Victor started using Forrest for FOP, they used view-cvs
checkout URIs as the system ids to access particular versions. If the
"old stuff" has system ids that directly access the files in cvs, won't
the absence of a catalog public resolver trigger access through the
system id?
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Dec 19, 2002 at 07:47:52PM +1100, David Crossley wrote:
> Jeff Turner wrote:
...
> > PUBLIC "-//APACHE//DTD Documentation//EN" "dtd/document-v11-3-1.dtd"
> > PUBLIC "-//APACHE//DTD Documentation V1//EN" "dtd/document-v11-3-1.dtd"
> > PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "dtd/document-v11-3-1.dtd"
> > PUBLIC "-//APACHE//DTD Documentation V1.1.3//EN" "dtd/document-v11-3-1.dtd"
> > PUBLIC "-//APACHE//DTD Documentation V1.1.3.1//EN" "dtd/document-v11-3-1.dtd"
...
>
> Great idea to use the OASIS catalog to manage this.
>
> How do we cope when it gets cumbersome? How many
> dtd revisions do we keep track of in the catalog
> and in cvs.
>
> Again, catalogs to the rescue. We could have a main catalog
> to declare the recent identifiers, then a separate catalog
> for the old stuff. This second one would not be used by
> default Forrest, but would be available to them if they
> need it. We already provide ways to load other catalogs.
Good idea.
Might be best to wait for Steven to get back before trying this.. there
are some unresolved issues on how DTD changes are made.
--Jeff
> The secondary catalog could utilise Steven's idea of
> linking to cvs.apache.org for the systemIdentifiers.
>
> I know that we are using OASIS catalogs and entity resolver
> to avoid the dependency on a network connection to get the
> resource. However, these are way out-of-date DTDs that we
> are talking about. If users are concerned, then they can
> download a local copy of the old DTD and adjust their
> OASIS catalog.
>
> --David
>
>
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by David Crossley <cr...@indexgeo.com.au>.
Jeff Turner wrote:
<snip/>
> Not physical symlinks, but using the catalog for the same effect:
>
> PUBLIC "-//APACHE//DTD Documentation V1.1.1//EN" "dtd/document-v11-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1.2//EN" "dtd/document-v11-2.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1.3//EN" "dtd/document-v11-3.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "dtd/document-v11-3.dtd"
>
> Here, 1.1 is an alias for 1.1.3, or more generally, 1.1.x where x is the
> latest.
>
> Taken to it's logical conclusion, we have:
>
> PUBLIC "-//APACHE//DTD Documentation//EN" "dtd/document-v11-3-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1//EN" "dtd/document-v11-3-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "dtd/document-v11-3-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1.3//EN" "dtd/document-v11-3-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1.3.1//EN" "dtd/document-v11-3-1.dtd"
>
>
> - First would be for docs who will follow the Forrest DTD whatever
> happens (eg Forrest's own site).
> - Middle would be what most users use.
> - Last is for paranoid users who want to specify _precisely_ which DTD
> they used.
Great idea to use the OASIS catalog to manage this.
How do we cope when it gets cumbersome? How many
dtd revisions do we keep track of in the catalog
and in cvs.
Again, catalogs to the rescue. We could have a main catalog
to declare the recent identifiers, then a separate catalog
for the old stuff. This second one would not be used by
default Forrest, but would be available to them if they
need it. We already provide ways to load other catalogs.
The secondary catalog could utilise Steven's idea of
linking to cvs.apache.org for the systemIdentifiers.
I know that we are using OASIS catalogs and entity resolver
to avoid the dependency on a network connection to get the
resource. However, these are way out-of-date DTDs that we
are talking about. If users are concerned, then they can
download a local copy of the old DTD and adjust their
OASIS catalog.
--David
RE: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by John Morrison <jo...@ntlworld.com>.
> From: Jeff Turner [mailto:jefft@apache.org]
> On Sun, Dec 15, 2002 at 12:05:45PM -0000, John Morrison wrote:
> > > From: Jeff Turner [mailto:jefft@apache.org]
> > > So we have v1.1, and we create v1.1.1. What do we do with 1.1?
> > >
> > > That depends on whether you treat v1.1 as v1.1.0, or as an alias to
> > > v1.1.x, where 'x' is the latest in the series.
> > >
> > > If v1.1 = v1.1.0, then 1.1.1 completely supersedes it, and I can kinda
> > > see why you'd want to 'cvs rm' it.
> > >
> > > Alternatively, we can make 1.1 an alias for the latest in the 1.1.x
> > > series.
> > >
> > > This allows users to choose the specificity of the DTD they use. Just
> > > like if I have /lib/libfoo.so.1 symlinked to
> /lib/libfoo.so.1.4.3, I can
> > > link against either.
> >
> > I like the idea of symlinking, but remember that windows can't
> do that :(
> > cygwin *can*, but the JVM won't be able to follow it :( (I've always
> > wanted a cygwin compile of the JVM for just such a reason).
>
> Not physical symlinks, but using the catalog for the same effect:
>
> PUBLIC "-//APACHE//DTD Documentation V1.1.1//EN" "dtd/document-v11-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1.2//EN" "dtd/document-v11-2.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1.3//EN" "dtd/document-v11-3.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "dtd/document-v11-3.dtd"
>
> Here, 1.1 is an alias for 1.1.3, or more generally, 1.1.x where x is the
> latest.
>
> Taken to it's logical conclusion, we have:
>
> PUBLIC "-//APACHE//DTD Documentation//EN" "dtd/document-v11-3-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1//EN" "dtd/document-v11-3-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "dtd/document-v11-3-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1.3//EN"
> "dtd/document-v11-3-1.dtd"
> PUBLIC "-//APACHE//DTD Documentation V1.1.3.1//EN"
> "dtd/document-v11-3-1.dtd"
>
>
> - First would be for docs who will follow the Forrest DTD whatever
> happens (eg Forrest's own site).
> - Middle would be what most users use.
> - Last is for paranoid users who want to specify _precisely_ which DTD
> they used.
Looks good to me :)
J.
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by Jeff Turner <je...@apache.org>.
On Sun, Dec 15, 2002 at 12:05:45PM -0000, John Morrison wrote:
> > From: Jeff Turner [mailto:jefft@apache.org]
> > So we have v1.1, and we create v1.1.1. What do we do with 1.1?
> >
> > That depends on whether you treat v1.1 as v1.1.0, or as an alias to
> > v1.1.x, where 'x' is the latest in the series.
> >
> > If v1.1 = v1.1.0, then 1.1.1 completely supersedes it, and I can kinda
> > see why you'd want to 'cvs rm' it.
> >
> > Alternatively, we can make 1.1 an alias for the latest in the 1.1.x
> > series.
> >
> > This allows users to choose the specificity of the DTD they use. Just
> > like if I have /lib/libfoo.so.1 symlinked to /lib/libfoo.so.1.4.3, I can
> > link against either.
>
> I like the idea of symlinking, but remember that windows can't do that :(
> cygwin *can*, but the JVM won't be able to follow it :( (I've always
> wanted a cygwin compile of the JVM for just such a reason).
Not physical symlinks, but using the catalog for the same effect:
PUBLIC "-//APACHE//DTD Documentation V1.1.1//EN" "dtd/document-v11-1.dtd"
PUBLIC "-//APACHE//DTD Documentation V1.1.2//EN" "dtd/document-v11-2.dtd"
PUBLIC "-//APACHE//DTD Documentation V1.1.3//EN" "dtd/document-v11-3.dtd"
PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "dtd/document-v11-3.dtd"
Here, 1.1 is an alias for 1.1.3, or more generally, 1.1.x where x is the
latest.
Taken to it's logical conclusion, we have:
PUBLIC "-//APACHE//DTD Documentation//EN" "dtd/document-v11-3-1.dtd"
PUBLIC "-//APACHE//DTD Documentation V1//EN" "dtd/document-v11-3-1.dtd"
PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "dtd/document-v11-3-1.dtd"
PUBLIC "-//APACHE//DTD Documentation V1.1.3//EN" "dtd/document-v11-3-1.dtd"
PUBLIC "-//APACHE//DTD Documentation V1.1.3.1//EN" "dtd/document-v11-3-1.dtd"
- First would be for docs who will follow the Forrest DTD whatever
happens (eg Forrest's own site).
- Middle would be what most users use.
- Last is for paranoid users who want to specify _precisely_ which DTD
they used.
--Jeff
>
> J.
RE: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by John Morrison <jo...@ntlworld.com>.
> From: Jeff Turner [mailto:jefft@apache.org]
> So we have v1.1, and we create v1.1.1. What do we do with 1.1?
>
> That depends on whether you treat v1.1 as v1.1.0, or as an alias to
> v1.1.x, where 'x' is the latest in the series.
>
> If v1.1 = v1.1.0, then 1.1.1 completely supersedes it, and I can kinda
> see why you'd want to 'cvs rm' it.
>
> Alternatively, we can make 1.1 an alias for the latest in the 1.1.x
> series.
>
> This allows users to choose the specificity of the DTD they use. Just
> like if I have /lib/libfoo.so.1 symlinked to /lib/libfoo.so.1.4.3, I can
> link against either.
I like the idea of symlinking, but remember that windows can't do that :(
cygwin *can*, but the JVM won't be able to follow it :( (I've always
wanted a cygwin compile of the JVM for just such a reason).
J.
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by Jeff Turner <je...@apache.org>.
On Sun, Dec 15, 2002 at 11:56:04AM +0100, Steven Noels wrote:
> Jeff Turner wrote:
>
> >On Sun, Dec 15, 2002 at 09:02:10AM +0100, Steven Noels wrote:
>
> >>Trying to fix the link element, I was thinking to do:
> >>
> >>catalog:
> >>PUBLIC "-//APACHE//ENTITIES Documentation V1.1//EN"
> >>
> >>"http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.mod?rev=1.7"
> >
> >
> >The point of catalogs is to find a *local* DTD, so why would you map it
> >to something over HTTP?
>
> Of course, but then I was thinking of what to do with the old versions.
> Should we litter CVS? If we have too much fileage[1], we might even be
> less motivated to fix and enhance DTDs.
Oh I see. Yes, that seems sensible if things get cluttered. Though DTDs
aren't very big and we could keep archiving the things in v10/, v11/,
v12/ etc directories..
[snip *-v1.1-x.dtds extending -v1.1.mod]
> Yes. But I consider this not to be a grammar evolution/modification, it
> is more of a localisation. If we decide link has to change, it should be
> done in-place, not in the local declaration subset (even though I just
> shaved, my beard is itching), and we should have proper versioning as
> you indicated.
Okay. So I guess the convention is to keep *.dtd clean and ready for
user 'localisation'.
> I'm not really keen on this particular way of patching the DTD.
Yes it smells funny, and I've never seen anyone else do it.. but it seems
to solve the problem.
> >A disadvantage of this scheme is that it makes extending 1.1.x DTDs a bit
> >yucky. You'd have to make a verbatim copy of document-v11-x.dtd, and
> >then make any additions. So whatever is in document-v11-1.dtd must also
> >be in document-v11-2.dtd, and all successors.
>
> Yep. My point exactly.
>
> ><snip things I didn't understand>
>
> I know you can do better ;)
I've re-read that bit with slightly more understanding now.
So we have v1.1, and we create v1.1.1. What do we do with 1.1?
That depends on whether you treat v1.1 as v1.1.0, or as an alias to
v1.1.x, where 'x' is the latest in the series.
If v1.1 = v1.1.0, then 1.1.1 completely supersedes it, and I can kinda
see why you'd want to 'cvs rm' it.
Alternatively, we can make 1.1 an alias for the latest in the 1.1.x
series.
This allows users to choose the specificity of the DTD they use. Just
like if I have /lib/libfoo.so.1 symlinked to /lib/libfoo.so.1.4.3, I can
link against either.
[on RNG]
> I'm very much inclined to do so, but still would like to keep both:
> there are much more grammar-aware editors that understand DTDs.
Yes. jing error reporting is a bit poor too.
--Jeff
> [1] fileage, as in: mileage, verbiage, foliage
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://radio.weblogs.com/0103539/
> stevenn at outerthought.org stevenn at apache.org
>
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by Steven Noels <st...@outerthought.org>.
Jeff Turner wrote:
> On Sun, Dec 15, 2002 at 09:02:10AM +0100, Steven Noels wrote:
>>Trying to fix the link element, I was thinking to do:
>>
>>catalog:
>>PUBLIC "-//APACHE//ENTITIES Documentation V1.1//EN"
>>
>>"http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.mod?rev=1.7"
>
>
> The point of catalogs is to find a *local* DTD, so why would you map it
> to something over HTTP?
Of course, but then I was thinking of what to do with the old versions.
Should we litter CVS? If we have too much fileage[1], we might even be
less motivated to fix and enhance DTDs.
>>PUBLIC "-//APACHE//ENTITIES Documentation V1.1.1//EN"
>> "dtd/document-v11.1.mod"
>>
>>and cvs removing document-v11.mod.
>
>
> I was suggesting leaving document-v11.mod alone, and making all further
> updates in .dtd files that override/extend document-v11.mod. There
> wouldn't be a document-v11.1.mod. The directory listing would be:
>
> document-v11.mod
> document-v11.dtd
> document-v11-1.dtd
> document-v11-2.dtd
>
> And corresponding catalog entries:
>
> PUBLIC "-//APACHE//ENTITIES Documentation V1.1//EN"
> "dtd/document-v11.mod"
>
> -- Document Type Definitions --
> PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
> "dtd/document-v11.dtd"
>
> -- Document Type Definitions --
> PUBLIC "-//APACHE//DTD Documentation V1.1.1//EN"
> "dtd/document-v11-1.dtd"
>
> -- Document Type Definitions --
> PUBLIC "-//APACHE//DTD Documentation V1.1.2//EN"
> "dtd/document-v11-2.dtd"
>
>
> So to implement Keiron's patch, we'd create a document-v1.1-1.dtd which
> overrides the 'link.att' entity as follows:
>
> <!ENTITY % common-charents PUBLIC
> "-//APACHE//ENTITIES Common Character Entity Sets V1.0//EN"
> "common-charents-v10.mod">
> %common-charents;
>
> <!ENTITY % document PUBLIC
> "-//APACHE//ENTITIES Documentation V1.1//EN"
> "document-v11.mod">
>
> <!-- Redefine 'href' attribute as REQUIRED -->
> <!ENTITY % link.att 'href CDATA #REQUIRED
> role CDATA #IMPLIED
> title CDATA #IMPLIED '>
>
> %document;
>
>
> I've tried this and it works.
Yes. But I consider this not to be a grammar evolution/modification, it
is more of a localisation. If we decide link has to change, it should be
done in-place, not in the local declaration subset (even though I just
shaved, my beard is itching), and we should have proper versioning as
you indicated.
I'm not really keen on this particular way of patching the DTD.
> A disadvantage of this scheme is that it makes extending 1.1.x DTDs a bit
> yucky. You'd have to make a verbatim copy of document-v11-x.dtd, and
> then make any additions. So whatever is in document-v11-1.dtd must also
> be in document-v11-2.dtd, and all successors.
Yep. My point exactly.
> <snip things I didn't understand>
I know you can do better ;)
>>But the itch is gradually becoming unbearable. If we don't clean up the
>>mess, we'll never get to properly manage our DTDs. I'll do some more
>>thinking.
>
>
> In the distant future it would be nice to switch to RELAX NG Compact,
> being the only schema syntax readily understandable by end users. Throw
> out DOCTYPE declarations and XML 1.0's definition of 'validity' and use a
> versioned namespace to identify the doc type.
I'm very much inclined to do so, but still would like to keep both:
there are much more grammar-aware editors that understand DTDs.
[1] fileage, as in: mileage, verbiage, foliage
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by Jeff Turner <je...@apache.org>.
On Sun, Dec 15, 2002 at 09:02:10AM +0100, Steven Noels wrote:
> Jeff Turner wrote:
>
> >Seems the only safe solution is to create a new DTD (and public
> >identifier) for each DTD version. This isn't as horrible as it sounds..
>
> Trying to fix the link element, I was thinking to do:
>
> catalog:
> PUBLIC "-//APACHE//ENTITIES Documentation V1.1//EN"
>
> "http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.mod?rev=1.7"
The point of catalogs is to find a *local* DTD, so why would you map it
to something over HTTP?
>
> PUBLIC "-//APACHE//ENTITIES Documentation V1.1.1//EN"
> "dtd/document-v11.1.mod"
>
> and cvs removing document-v11.mod.
I was suggesting leaving document-v11.mod alone, and making all further
updates in .dtd files that override/extend document-v11.mod. There
wouldn't be a document-v11.1.mod. The directory listing would be:
document-v11.mod
document-v11.dtd
document-v11-1.dtd
document-v11-2.dtd
And corresponding catalog entries:
PUBLIC "-//APACHE//ENTITIES Documentation V1.1//EN"
"dtd/document-v11.mod"
-- Document Type Definitions --
PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"dtd/document-v11.dtd"
-- Document Type Definitions --
PUBLIC "-//APACHE//DTD Documentation V1.1.1//EN"
"dtd/document-v11-1.dtd"
-- Document Type Definitions --
PUBLIC "-//APACHE//DTD Documentation V1.1.2//EN"
"dtd/document-v11-2.dtd"
So to implement Keiron's patch, we'd create a document-v1.1-1.dtd which
overrides the 'link.att' entity as follows:
<!ENTITY % common-charents PUBLIC
"-//APACHE//ENTITIES Common Character Entity Sets V1.0//EN"
"common-charents-v10.mod">
%common-charents;
<!ENTITY % document PUBLIC
"-//APACHE//ENTITIES Documentation V1.1//EN"
"document-v11.mod">
<!-- Redefine 'href' attribute as REQUIRED -->
<!ENTITY % link.att 'href CDATA #REQUIRED
role CDATA #IMPLIED
title CDATA #IMPLIED '>
%document;
I've tried this and it works.
A disadvantage of this scheme is that it makes extending 1.1.x DTDs a bit
yucky. You'd have to make a verbatim copy of document-v11-x.dtd, and
then make any additions. So whatever is in document-v11-1.dtd must also
be in document-v11-2.dtd, and all successors.
<snip things I didn't understand>
>
> But the itch is gradually becoming unbearable. If we don't clean up the
> mess, we'll never get to properly manage our DTDs. I'll do some more
> thinking.
In the distant future it would be nice to switch to RELAX NG Compact,
being the only schema syntax readily understandable by end users. Throw
out DOCTYPE declarations and XML 1.0's definition of 'validity' and use a
versioned namespace to identify the doc type.
--Jeff
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at http://radio.weblogs.com/0103539/
> stevenn at outerthought.org stevenn at apache.org
>
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by Steven Noels <st...@outerthought.org>.
Jeff Turner wrote:
> Seems the only safe solution is to create a new DTD (and public
> identifier) for each DTD version. This isn't as horrible as it sounds..
Trying to fix the link element, I was thinking to do:
catalog:
PUBLIC "-//APACHE//ENTITIES Documentation V1.1//EN"
"http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.mod?rev=1.7"
PUBLIC "-//APACHE//ENTITIES Documentation V1.1.1//EN"
"dtd/document-v11.1.mod"
and cvs removing document-v11.mod. Or is that too drastic? This is only
one little part of the solution however, since each DTD referencing
document.mod should be changed. You see why they prefer to emerge with
an entire set.
Which means if we change a global element in document.mod, as I just did
for that link thing, we need to change references to this .mod in all
wrapper DTDs. Ouch.
While doing this, I would imagine we better first move some elements
from document.mod to common-elems.mod
Before that however, we should list what element & attribute
declarations should belong where:
1) wrapper or driver files:
document.dtd
howto.dtd (is more than only a driver)
faq.dtd
todo.dtd
2) structure:
document.mod
faq.mod
todo.mod
3) common declarations:
common-charents.mod
common-elems.mod
Now I know why I didn't dare to touch them :-|
But the itch is gradually becoming unbearable. If we don't clean up the
mess, we'll never get to properly manage our DTDs. I'll do some more
thinking.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on link)
Posted by Steven Noels <st...@outerthought.org>.
Jeff Turner wrote:
> On Fri, Dec 13, 2002 at 04:46:32PM +0100, Keiron Liddle wrote:
>
>>Hi all,
>>
>>Shouldn't the href attribute on a link (or jump, fork) be required.
>>
>>In other words what is a link that points to nowhere.
>
>
> Interesting.. I wonder if the original DTD author was pasting from XLink or
> something.
Yep, Stefano was.
<snip/>
> What do people think?
+1 for backwards-compatible changes (things being added) or _light_
extra restrictions. Where should we store the old versions? Or do we add
links to the CVS view of older versions:
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/resources/schema/dtd/document-v11.mod?rev=1.6
The optional href attribute was inspired by named anchors, i.e. <a
name="foobar"/>: my bad.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0103539/
stevenn at outerthought.org stevenn at apache.org
Re: [PROPOSAL] DTD Versioning (Re: Should href be required on
link)
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Sat, 2002-12-14 at 06:54, Jeff Turner wrote:
> > Anyway it causes an error with Fop.
>
> Do you mean, in FOP, someone wrote <link/> and wondered why it broke? :)
> What was the error?
Current releases of Fop require the internal-destination or
external-destination otherwise an exception is thrown. This causes the
pdf document to not be created. With something like <link>text</link>.