Re: [Cp-tools-discuss] Re: XML Entities, DTDs

[Alex Lancaster]

>>>>> "JS" == Julian Scheid <address@hidden> writes:

[...]

JS> But it's an evolving standard which we would need to keep up with
JS> if we reinvented the wheel. Besides, an XSLT processor delivers
JS> entity transformation for free, so why should we implement it? If
JS> there are no entity definition files out there with an acceptable
JS> license (which I don't believe) then we need to implement our own,
JS> but only the definitions and not the transformation.

>> Speaking of which. Since we still don't have a dtd can we also use
>> the --novalid flag for xsltproc so we won't get the warning
>> messages about missing dtds?

JS> I'll write the DTD soon... until then feel free to use
JS> --novalid. I'll leave the warning in so it reminds me of what is
JS> missing. ;)

By the way, if I recall correctly, even though the xsltproc option is
"--novalid", contrary to it's name, it doesn't actually validate the
document by default (i.e. *not* specifying "--novalid" *doesn't* mean
that it validates the document).

It simply attempts to load the DTD at the specified URI as resolved by
the XML catalog (and possibly check for well-formedness of the DTD?),
but it doesn't actually validate the document against the DTD.

If you want to validate the document, you need to run "xmllint" and
check it's return value before running xsltproc.

It's a subtle behaviour that can easily bite you (as it has me)
because you might assume that all your documents are valid (by the
DTD) because xsltproc is not emitting any warnings or errors.  (It
will only emit warnings that result from the actual XSLT
transformation, e.g. XML elements that don't match templates etc).

Just FYI.

A.
-- 
    Alex Lancaster * address@hidden * SourceForge Developer