Re: [dita] Namespaces and Schemas: Some Initial Findings and XSLTImplications

[Eliot Kimber <ekimber@innodata-isogen.com>]

Don Day wrote:

> Eliot Kimber <ekimber@innodata-isogen.com> wrote on 06/29/2004 01:52:12 PM:
> 
> 
>>This means that the relevant schema awareness is provided entirely in
>>the initial parsing and does not require any schema awareness in the
>>XSLT engine itself.
> 
> 
> Good job! But I worry that not every user is going to understand how to do
> the same things with their processing environment.  One of my strong
> desires is that DITA processing remain easy to do with
> off-the-shelf/off-the-web tools with little or no installation tinkering.
> Will these considerations impact the use of Ant and other tools that also
> call the built-in Xalan?  That is, have you taken a step down a road that
> prereqs all other tools to work with Saxon only?

No, the point is that the XSLT processing works with both Xalan and 
Saxon (and any othe JAXP-conforming processor). So if you're happy using 
Xalan you're fine.

People doing schema-based document processing will have to do this for 
anything, not just DITA. It's unavoidable until all XSLT processors 
automatically use schema-aware parsers.

>>I also realized that one must namespace qualify the attributes as well
>>as the tag names in match statements, e.g.:
>>
>><xsl:template match="dbase:*[contains(@dbase:class,' topic/titlealts
> 
> ')]"/>
> 
>>So I am satisfied that moving to a schema-only approach would not
>>prevent people from using common tools and the existing XSLTs with
>>namespaces added.
> 
> 
> Doesn't this prevent using the same transfroms for DTD-based processing?
> Again, I see a polarization forming of tools/docs that only work with
> Schemas, and that are not fully interoperable with DTD-based content and
> processors.  The IBM tools team has seen this coming for awhile, and
> haven't seen any easy answers here.  It looks like the jump from DTDs to
> Schemas will still touch everything, docs and tools alike, however minor.
> "Why can't we all just get along?"

No, this does not affect the ability to use DTDs at all. The transforms 
are tied to the namespaces and attribute values, not the type of schema 
used, so if you want to use DTD-based documents you can.

The appropriateness of DTDs as a general matter of XML practice is a 
completely different matter that we don't need to argue here. I take it 
as given that we can't provide a schema-only solution simply because of 
existing legacy systems and tool sets (even though I would personally 
prefer a schema-only solution).

Note that this current discussion comes out of my assertion that DITA 
should require that all DITA documents use a (the) DITA namespace. This 
assertion is driven by the fact that DITA documents need to be self 
describing with regard to their types and this is the only 
*standard-defined* mechanism for doing so. Neither DOCTYPE declarations 
nor noNamespaceSchemaLocation is reliable as an indication of abstract 
document type. Therefore the use of at least one DITA-defined namespace 
is required.

Given that there are then at least two related questions:

1. What are the implications for schema construction?

2. What are the implications for XSLT processing?

Note that for DTDs it's a purely syntactic issue of declaring the 
namespace declaration attributes--DTD processing is not namespace aware 
so there are no other implications.

> Besides (can't help myself), that global search and replace is so...
> debasing.
> 
> 
>>Instances require only that the DITA namespace be declared as the root
>>namespace, which requires modifying only the root tag and no others, so
>>the impact on existing bodies of DITA documents is about as low as it
>>can be and still require some modification.

OK, pride goeth...I have realized that it's not quite so easy. I don't 
see how it can be done with global search and replace, largely because 
it would require matches of the "/." which matches too much stuff that 
isn't XSLT expressions (such as URLs in namespace declarations). Doh!

> On the transforms side, couldn't you just declare the namespace in the
> <xsl:stylesheet> element and let the otherwise un-prefixed elements and
> attributes in the transform instance inherit the parent namespace?

It doesn't appear so--at least this didn't work in my tests and if I 
undestand the XSLT spec correctly, it explicitly says that unqualified 
names *do not* match the stylesheet's root namespace but match only 
names in no namespace (but I could easily be wrong here).

Cheers,

Eliot
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9030 Research Blvd, #410
Austin, TX 78758
(512) 372-8122

eliot@innodata-isogen.com
www.innodata-isogen.com