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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: Qualifying DITA Package and Class Names

In a separate thread, Erik Hennum said:

> The realization that, for DITA processes, the class is
> everything and the element name nothing is very
> important.  My conclusion from this realization is that,
> if we introduce namespaces, we need to use use
> the namespaces in the class attribute as well.
> Currently, we use a DITA-only identifier for each
> specialization package.  These identifiers are at risk
> for name collisions -- two specializers working
> indepently could easily come up with the same
> package identifier and only discover one another
> years later after creating an immovable installed base.
> The standard XML approach would be to use a
> namespace for each specialization package
> to prevent such collisions.

I agree--within the universe of DITA package and class names, 
non-DITA-defined names should be qualified as a matter of best practice.

Functionally, DITA packages correspond exactly to namespaces in the XML 
sense: they establish a unique name space of names that serve to 
characterize XML elements, the names of DITA classes.

This means that you could take the current DITA package name part of the 
DITA class syntax "package/class" as the equivalent of a namespace 
prefix and we could even consider changing the syntax to " 
package:class" (that is, the value of the DITA class attribute would 
become an ordered sequence of namespace-qualified names).

[Aside: This observation supports Erik's assertion that each package 
should have it's own namespace.]

However, to anticipate Paul G's reaction (and probably Don's too), 
making that kind of syntax change in 1.0 is probably not at all wise and 
I *am not* suggesting it. Merely pointing out that it makes sense in the 

However, it is still the case that there a real issue with how to 
qualify package and class names in non-DITA-defined specializations.

I think that in 1.0 we can solve this problem as follows:

1. Assert that the "package/class" syntax is functionally equivalent to 
"prefix:local_name" in that the package name is taken to be a namespace 
prefix that maps to some defined namespace URI.

2. Assert that in DITA 1.0 the DITA-defined package names are "magic" 
reserved namespace prefixes and that documents do not need to delcare 
these namespaces--conforming DITA processors will assume the 
declarations of the corresponding namespaces URIs. We must define those 
URIs in the 1.0 spec and it wouldn't hurt to include them in the DITA 
schemas. But document instances would not need to declare them (that is 
DTD-only or no-schema documents would still be fine).

3. Assert that any non-DITA-defined package name must have a 
corresponding in-scope xmlns declaration that maps that package name to 
the appropriate namespace. Or, possibly, allow the package name to be 
replaced by a URI (but I don't this would have to be allowed and 
allowing it would introduce some potentially tricky syntax issues that 
are probably better avoided in 1.0).

4. Assert that DITA processors that can must expand package names to 
their URIs for the purposes of mapping classes to processing or 
validation rules (just as they would expand normal XML namespace 
prefixes). Processors that cannot do that (i.e., non-DITA-aware CSS 
renderers) just have to depend on the package prefixes being unique. 
This means that if you are creating documents with two different 
non-DITA-defined specializations, you better make sure that the local 
package names are different so your CSS style sheets will work right.

This approach provides the following:

1. Does not require any syntactic change to any existing DITA documents 
or schemas (because the current DITA-defined package and class names are 
not changed).

2. Does not break any existing DITA-base-aware processors (again, 
because the DITA-defined class values haven't changed in any way).

3. Provides for easy disambiguation of conflicting package names for 
non-DITA-defined specializations.

4. Uses exactly the same processing rules and expectations that 
namespace-aware XML processing already imposes (that namespace prefixes 
have to be expanded if you want 100% reliable processing but that if 
you're pretty sure the prefixes are reliable without expansion you can 
just use the prefix).

5. Leaves the door open for alternative classification syntaxes in later 

6. Doesn't require any DITA-specific definitional mechanisms, such as a 
DITA-specific "package namespace declaration".

7. Does require that if you want to add the schema for a new 
specialization to your schema and it comes with a prefix that conflicts 
with one you already use in your schema, you will need to change one or 
the other prefixes locally. I don't see a way to avoid this and keep the 
existing class attribute syntax unchanged.

In the post-1.0 timeframe I think we would probably want to think 
seriously about providing a way to declare namespaces within class= 
attribute values the same way you can in XPath 2 or in XPointer--this 
would avoid the need to change DTDs and schemas locally just to 
disambiguate two conflicting local prefixes.

But otherwise I don't see any useful difference between DITA package and 
class names and traditional XML namespaces and element type 
names--they're just names in namespaces.


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


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