MHonArc v2.5.0b2 -->
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
abstract.
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
releases.
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.
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122
eliot@innodata-isogen.com
www.innodata-isogen.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]