6:34 p.m.
Whenever I run `C-c C-p` to parse the DTD, I get "External entity
CHAPTER not found". Can any one explain why? And perhaps suggest a
fix?
-Charlie
--
--
tuxxer <tuxxer(a)cox(dot)net>
<== tuxxer's gpg key fingerprint ==>
57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1
2:57 a.m.
On Sat, 2004-09-04 at 16:34, tuxxer wrote:
Whenever I run `C-c C-p` to parse the DTD, I get "External
entity
CHAPTER not found". Can any one explain why? And perhaps suggest a
fix?
This happens when you are parsing the DTD for an individual <chapter> in
a single file; since there is no DOCTYPE header, Emacs isn't sure how to
parse the file.
This is where the saved parsed file comes in handy:
http://fedora.redhat.com/participate/documentation-guide/s1-emacs-cedfile...
http://fedora.redhat.com/participate/documentation-guide/s1-emacs-loadced...
Once you've loaded the .ced file, the XML will parse and validate. You
may experience a difference in indenting levels or other things when the
XML is properly parsed.
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
5:08 p.m.
On Sun, 2004-09-05 at 07:57, Karsten Wade wrote:
On Sat, 2004-09-04 at 16:34, tuxxer wrote:
> Whenever I run `C-c C-p` to parse the DTD, I get "External entity
> CHAPTER not found". Can any one explain why? And perhaps suggest a
> fix?
This happens when you are parsing the DTD for an individual <chapter> in
a single file; since there is no DOCTYPE header, Emacs isn't sure how to
parse the file.
This is where the saved parsed file comes in handy:
http://fedora.redhat.com/participate/documentation-guide/s1-emacs-cedfile...
http://fedora.redhat.com/participate/documentation-guide/s1-emacs-loadced...
Once you've loaded the .ced file, the XML will parse and validate. You
may experience a difference in indenting levels or other things when the
XML is properly parsed.
I've done that. But my .ced file is called hardfen-parent.ced. Do I
need a .ced file for each individual XML file?
-charlie
--
--
tuxxer <tuxxer(a)cox(dot)net>
<== tuxxer's gpg key fingerprint ==>
57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1
7:42 a.m.
On Sun, 2004-09-05 at 18:08, tuxxer wrote:
On Sun, 2004-09-05 at 07:57, Karsten Wade wrote:
> On Sat, 2004-09-04 at 16:34, tuxxer wrote:
> > Whenever I run `C-c C-p` to parse the DTD, I get "External entity
> > CHAPTER not found". Can any one explain why? And perhaps suggest a
> > fix?
>
> This happens when you are parsing the DTD for an individual <chapter> in
> a single file; since there is no DOCTYPE header, Emacs isn't sure how to
> parse the file.
>
> This is where the saved parsed file comes in handy:
>
> http://fedora.redhat.com/participate/documentation-guide/s1-emacs-cedfile...
> http://fedora.redhat.com/participate/documentation-guide/s1-emacs-loadced...
>
> Once you've loaded the .ced file, the XML will parse and validate. You
> may experience a difference in indenting levels or other things when the
> XML is properly parsed.
I've done that. But my .ced file is called hardfen-parent.ced. Do I
need a .ced file for each individual XML file?
You only need one for the parent file (the one with the actual
declaration at the top). A copy of the Documentation Guide comes with
the CVS pull. Look at that one for an example. There's only a single
.ced file for the parent. The component (chapter) files are all declared
as entities in the parent. When you edit one of them, you load the .ced
file, and off you go.
--
Paul W. Frields, RHCE
5:37 a.m.
On Sun, 2004-09-05 at 00:34, tuxxer wrote:
Whenever I run `C-c C-p` to parse the DTD, I get "External
entity
CHAPTER not found". Can any one explain why? And perhaps suggest a
fix?
Yes, either as Karsten says,
or the emacs way;
Add
<!--
Local Variables:
mode: xml
sgml-parent-document: ("../dir/root.xml" "chapter")
End:
-->
That tells psgml that the file root.xml holds the 'chapter' element
that this file is a part of?
See the psgml doco for details,
but basically this just links this file with the parent
that has the doctype declaration.
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
10:52 a.m.
On Sun, 2004-09-05 at 03:37, Dave Pawson wrote:
On Sun, 2004-09-05 at 00:34, tuxxer wrote:
> Whenever I run `C-c C-p` to parse the DTD, I get "External entity
> CHAPTER not found". Can any one explain why? And perhaps suggest a
> fix?
Yes, either as Karsten says,
or the emacs way;
Please don't do as Dave says, unless he can truly fix this problem.
If you use a Local Variable instead of a .ced file, the indenting is off
by two; the core element for the file is indented flush left. When
using a .ced file, the indenting for the <chapter> or <section> starts
two from the left-flush.
I assume Dave would then run the file through an XSLT before doing XML
diffs[1]. That seems like a lot of steps to me.
If you use a Local Variable, and the rest of the project is using .ced
files, then doing a diff on your file with an editor is going to be
impossible.
I've run these experiments numerous times, but if someone can point out
the error in my method to let us use Local Variable, I am more than
happy to use this easier method. Otherwise, we must stick with the
project practice or change the practice across all documents for
editorial consistency.
- Karsten
[1] BTW, I've always only ever been talking about XML diffs, *not*
diffs of the rendered file.
Add
<!--
Local Variables:
mode: xml
sgml-parent-document: ("../dir/root.xml" "chapter")
End:
-->
That tells psgml that the file root.xml holds the 'chapter' element
that this file is a part of?
See the psgml doco for details,
but basically this just links this file with the parent
that has the doctype declaration.
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
11:15 a.m.
On Mon, 2004-09-06 at 16:52, Karsten Wade wrote:
> Yes, either as Karsten says,
> or the emacs way;
Please don't do as Dave says, unless he can truly fix this problem.
Its not a
problem Karsten. Its the way psgml is supposed to work?
If you use a Local Variable instead of a .ced file, the indenting is off
by two;
so address that problem? Unrelated to finding the schema?
I assume Dave would then run the file through an XSLT before doing
XML
diffs[1]. That seems like a lot of steps to me.
No. I keep saying (OK once :-)
that plain text diffs on xml are
... not right.
If you use a Local Variable, and the rest of the project is using .ced
files, then doing a diff on your file with an editor is going to be
impossible.
Thats a project weakness. Nothing to do with schema location.
I've run these experiments numerous times, but if someone can point out
the error in my method to let us use Local Variable, I am more than
happy to use this easier method.
The error is using the wrong tools.
I edit pretty large xml files in emacs quite a lot.
I also use nxml-mode with xml-mode and believe me
hacking that 4 liner to the bottom of the file
is the easier option.
If you are bothered by the indents,
fix the elisp for sgml-mode,
or ask on psmgl-list for Lennart to do it!
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
12:45 p.m.
On Mon, 2004-09-06 at 09:15, Dave Pawson wrote:
On Mon, 2004-09-06 at 16:52, Karsten Wade wrote:
> > Yes, either as Karsten says,
> > or the emacs way;
>
> Please don't do as Dave says, unless he can truly fix this problem.
Its not a problem Karsten. Its the way psgml is supposed to work?
Something can work as it's supposed to and still be a problem. :)
For example, we have two different indenting behaviors depending on
which method we choose to get a file to parse. That is a problem. It
doesn't matter if they methods are, in themselves, working correctly. :)
>
> If you use a Local Variable instead of a .ced file, the indenting is off
> by two;
so address that problem? Unrelated to finding the schema?
> I assume Dave would then run the file through an XSLT before doing XML
> diffs[1]. That seems like a lot of steps to me.
No. I keep saying (OK once :-) that plain text diffs on xml are
... not right.
Oh, good, we're in agreement.
> If you use a Local Variable, and the rest of the project is
using .ced
> files, then doing a diff on your file with an editor is going to be
> impossible.
Thats a project weakness. Nothing to do with schema location.
Okay ... but the solution to a project weakness is not to suggest that
people just start doing things a different way. We're having enough
challenges managing things as they are.
> I've run these experiments numerous times, but if someone
can point out
> the error in my method to let us use Local Variable, I am more than
> happy to use this easier method.
The error is using the wrong tools.
What is the wrong tool? Using a .ced file built from a parent XML file
to parse a child XML file?
I edit pretty large xml files in emacs quite a lot.
I also use nxml-mode with xml-mode and believe me
hacking that 4 liner to the bottom of the file
is the easier option.
Then perhaps we should abandon the .ced files and use Local Variable
instead? Wouldn't get any objections from me!
If you are bothered by the indents,
I'm not bothered by them until I have to reconcile two authors/editors
who are using different methods.
The difference between a random bunch of documents stored together and
an organized, quality document project is a) consistent methodology, and
b) sticking to a) until everyone agrees to change the method.
My request is, if you have an idea of how to do something better than
our current methodology, please *suggest* it as a new solution, and
we'll get a quick consensus and move forward. Telling new users to just
do something different from what is laid out in our project guide is
confusing for the user and detrimental to the project.
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
2:45 p.m.
On Mon, 2004-09-06 at 18:45, Karsten Wade wrote:
> > I've run these experiments numerous times, but if
someone can point out
> > the error in my method to let us use Local Variable, I am more than
> > happy to use this easier method.
>
> The error is using the wrong tools.
What is the wrong tool? Using a .ced file built from a parent XML file
to parse a child XML file?
.ced file is the right tool, for faster access to a compiled dtd for
a specific file.
.ced is not always the right way to get hold of the dtd for a suite
of files
e.g. if n files make up an article.
In that case, the psgml comment is (IMHO) the right way to do it.
Especially since splitting up the file makes psgml parsing sufficiently
fast.
IMHO its using a line based comparison or diff tool to find out
what the changes are in an XML file, when xml is largely
'don't care' about white space.
> I edit pretty large xml files in emacs quite a lot.
> I also use nxml-mode with xml-mode and believe me
> hacking that 4 liner to the bottom of the file
> is the easier option.
Then perhaps we should abandon the .ced files and use Local Variable
instead? Wouldn't get any objections from me!
Not my view. Use when appropriate?
> If you are bothered by the indents,
I'm not bothered by them until I have to reconcile two authors/editors
who are using different methods.
The difference between a random bunch of documents stored together and
an organized, quality document project is a) consistent methodology, and
b) sticking to a) until everyone agrees to change the method.
My request is, if you have an idea of how to do something better than
our current methodology, please *suggest* it as a new solution,
I've recently
looked at two XML based diff engines.
Neither seem appropriate for this projects use.
the sourceforge one has possibilities though,
and
we'll get a quick consensus and move forward. Telling new users to just
do something different from what is laid out in our project guide is
confusing for the user and detrimental to the project.
I don't tell people anything.
Just saying what I use, and have done for 7 years.
YMMV.
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
6:54 p.m.
On Mon, 2004-09-06 at 12:45, Dave Pawson wrote:
On Mon, 2004-09-06 at 18:45, Karsten Wade wrote:
> Then perhaps we should abandon the .ced files and use Local
Variable
> instead? Wouldn't get any objections from me!
Not my view. Use when appropriate?
We need to be consistent until we have proof that we can change our
practices. Surely you can understand this?
I don't tell people anything.
Just saying what I use, and have done for 7 years.
YMMV.
It's great that you bring your experience to bear in solving problems
here. Your help is really important. But if your suggestion is to try
something that is not inline with our practices, it's detrimental to the
goals of the project. The Documentation Guide clearly says to follow
one practice, and you suggest a different one. Because of the authority
your voice lends, you influence a new writer down a path that diverges
from the project. The writer and the project suffer now, or down the
road.
Having and following good practices is what it takes to make Fedora docs
the best resource for Fedora users, as opposed to a collection of random
and semi-maintained documents.
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
2:38 p.m.
Dave Pawson wrote:
The error is using the wrong tools.
I edit pretty large xml files in emacs quite a lot.
I also use nxml-mode with xml-mode and believe me
hacking that 4 liner to the bottom of the file
is the easier option.
I've gotta side with Dave on this one. The emacs 'Local Variables'
approach allows you to open up any of the 'child' docs and
immediately start editing in DTD-aware mode. (Emacs then
automatically loads the top-level parent file.)
Also, as soon as you change the internal subset of the DTD, by, e.g.
, adding a new entity, you *must* recompile the DTD because the DTD
itself has been changed.
Regarding the indenting issue: I've heard this is a problem for
translation, but one should be still be able to produce reasonable
diffs w/ some work around. Or someone could test the GPL tool
'xmldiff'[1], to see if it cares about indentation.
FWIW, I use a slightly different form of the local varable statement
than Dave; mine specifies three quantities:
- top-level-parent-document
- top-level-element-in-parent-doc
- top-level-element-in-this-doc
e.g., for a chapter file, I'd have this at the end:
<!-- Keep this comment at the end of the file
Local variables:
mode: xml
sgml-parent-document:("parent-file.xml" "book" "chapter")
End:
-->
My $0.02,
Mark
[1] http://www.logilab.org/projects/xmldiff/
If you are bothered by the indents,
fix the elisp for sgml-mode,
or ask on psmgl-list for Lennart to do it!
--
----------------------------------------------------------
Mark Johnson <mjohnson(a)redhat.com>
OS Product Documentation
Engineering, Red Hat, Inc. <http://www.redhat.com>
Tel: 919.754.4151 Fax: 919.754.3708
GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
6:47 p.m.
On Mon, 2004-09-06 at 12:38, Mark Johnson wrote:
Regarding the indenting issue: I've heard this is a problem for
translation, but one should be still be able to produce reasonable
diffs w/ some work around. Or someone could test the GPL tool
'xmldiff'[1], to see if it cares about indentation.
Sounds like a fine approach to me. Here is where we stand:
* Until we learn otherwise, we need to practice a given set of rules
(outlined in the Doc Guide) to keep editing and translating feasible.
These rules include whitespace (and indenting) practices.
* Those who are interested should a) research XML diff tools, and b)
bring this up with the translation team (fedora-i18n-list) to find out
what they want to and are able to do. I just joined that list, and am
prepared to discuss toolchains.
So, while I'm all for Local Variables and letting people indent and use
whitespace as they wish, until we *know* that our documents can be
internationalized with available tools, we must stick with what works,
regardless of our personal preferences.
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
12:14 p.m.
On Tue, 2004-09-07 at 00:47, Karsten Wade wrote:
* Until we learn otherwise, we need to practice a given set of rules
(outlined in the Doc Guide) to keep editing and translating feasible.
These rules include whitespace (and indenting) practices.
I'm asking you to question why its important, outside the requirements
of specific docbook elements (those which respect ws in presentation).
* Those who are interested should a) research XML diff tools, and b)
bring this up with the translation team (fedora-i18n-list) to find out
what they want to and are able to do. I just joined that list, and am
prepared to discuss toolchains.
So, while I'm all for Local Variables and letting people indent and use
whitespace as they wish, until we *know* that our documents can be
internationalized with available tools, we must stick with what works,
regardless of our personal preferences.
How will indentation impact i18N (even in the tiniest way) Karsten?
--
Regards DaveP.
XSLT&Docbook FAQ
http://www.dpawson.co.uk/xsl
3:11 p.m.
On Tue, 2004-09-07 at 10:14, Dave Pawson wrote:
How will indentation impact i18N (even in the tiniest way) Karsten?
As has been mentioned previously, the legacy translation toolchain uses
line based diffs. A translator uses the diff to determine what has
changed since the last translation, reducing workload greatly.
We don't know what will break down the path from our changing existing
practices. Wouldn't the responsible thing be to find out *first* before
changing them?
Anyone interested in perusing the f-i18n-list archives, please post your
research with links. Otherwise, we'll just have to ask what their plans
are.
- Karsten
--
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
7170
days inactive
7173
days old
13 comments
5 participants
participants (5)
-
Dave Pawson -
Karsten Wade -
Mark Johnson -
Paul W. Frields -
tuxxer