Re: [dita] Qualifying DITA Package and Class Names

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Eliot:

I find this approach very appealing. Your statement sets a well-defined namespace direction and lays the groundwork for future evolution (guiding interim investigations) without risk to the initial release.

The TC might want to express point 5 about alternative classification syntaxes as a formal notice that the classification scheme may change for more direct expression of namespaces but that changes to the classification scheme will not affect the element names or structures.


Thanks,


Erik Hennum
ehennum@us.ibm.com


Eliot Kimber <ekimber@innodata-isogen.com> wrote on 08/04/2004 01:49:48 PM:

> 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
>