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: [no subject]


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.

One possible approach for using namespaces
to identify packages in the class attribute:

<concept  class="-
    topic:http://dita.oasis-open.org/1.0/pkg/topic
    concept:http://dita.oasis-open.org/1.0/pkg/concept
">

That's more than a little verbose, however.

Coming up with a namespaced scheme for the class
attribute, making sure it serves all purposes (for
instance, CSS styling), and migrating existing
document types and code will be a major
undertaking.

I read Paul's cautions and get the willies.

The comments about a data dictionary are really
intriguing.  DITA document types should be
possible to generate automatically from a
library of pluggable specialization packages.


Thanks,


Erik Hennum
ehennum@us.ibm.com


Eliot Kimber <ekimber@innodata-isogen.com> wrote on 08/03/2004 11:01:11 AM:

> Options for namespaces for DITA.
>
> I think we have the following practical options for using namespaces
> with DITA 1.0:
>
> 1. Have exactly one namespace for all element types, including local
> specializations.
>
> 2. Have exactly two namespaces, one for maps, one for all other element
> types, including local specializations.
>
> 3. Have many namespaces: one for maps, one each for topic, task,
> reference, concept, different domains, locally-specialized elements, etc.
>
> 4. Have two namespaces for DITA-defined types (including domains). Local
> specializations are in their own namespaces.
>
> Of these options, I think that (1) will not work, for the simple reason
> that maps and topics use the same element type names with different
> content models. Thus maps and topics are fundamentally different
> document types and therefore represent different namespaces.
>
> I think that (3) is just nuts, but that's mostly because I don't yet
> understand the implications of having that many namespaces, especially
> for schema definition and modularization.
>
> ...


Eliot Kimber <ekimber@innodata-isogen.com> wrote on 08/04/2004 08:38:27 AM:

> ...
>
> Given this realization, it should become clear that the namespace of the
> *element types* is essentially irrelevant for the purpose of defining
> and implementing DITA processing. That means that there is no particular
> need to put the DITA-defined element types into any particular name
> space. Likewise for specialized elements: for DITA processing purposes
> only their class values will be used so they could be in no name space
> or in any namespace--it simply doesn't matter.
>
> ...
>
> And as I think of it now, this also suggests that the normative
> definition of the DITA document types should be a "data dictionary" of
> element classes, not a collection of element types or a DTD. That is,
> any DTD or schema that reflects the DITA *classes* is only one of an
> infinite number of possible such DTDs or schemas and therefore any DTD
> or schema published as a standard would not be *the* definition of the
> DITA types of merely a conforming implementation of the DITA types. We
> should certainly publish at least one DTD and one Schema as reference
> implementation but I don't think they can be *the* normative definition
> of what the DITA types are.
>
> ...
--0__=07BBE475DFC95F3A8f9e8a93df938690918c07BBE475DFC95F3A
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline

<html><body>
<p>Hi, Eliot:<br>
<br>
Dang.  The one that makes sense to me is the nut case.  Let me try<br>
to argue some method in my madness.<br>
<br>
In every approach other than 3, we have two typing systems:  the<br>
external namespaces and the internal DITA classes.<br>
<br>
Architectually, we'd be better off with one typing system -- one<br>
implementation, one check to make, and so on.<br>
<br>
Also, with an internal typing system that augments the namespace<br>
type, the consumer of DITA content can't rely on the namespace<br>
as an indicator for whether the content can be handled.  The <br>
application has no way to know whether new specializations <br>
have been added into the namespace or not.  Only applications<br>
that have knowledge of the DITA architecture will be able to use<br>
DITA content.<br>
<br>
It's analgous to adding new elements to a vocabulary but<br>
keeping the same public identifier.<br>
<br>
If each specialization package had its own namespace,<br>
a document using namespace prefixes would resemble <br>
the following example:<br>
<br>
&lt;concept:concept id=&quot;someConcept&quot;&gt;<br>
  &lt;topic:title&gt;Some concept&lt;/topic:title&gt;<br>
  &lt;concept:conbody&gt;<br>
    &lt;topic:p&gt;Some body content with<br>
      a &lt;topic:ph&gt;phrase&lt;/topic:ph&gt;,<br>
      a &lt;programming:codeph&gt;code&lt;/programming:codeph&gt; phrase, and<br>
      a &lt;java:methodName&gt;getString&lt;/java:methodName&gt; name.<br>
    &lt;/topic:p&gt;<br>
  &lt;/concept:conbody&gt;<br>
&lt;/concept:concept&gt;<br>
<br>


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