MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] namespaces goals
I vote for leaving it so for DITA 1.0. We cannot do any better until there
is a _working and tested_ DITA toolkit with namespace support.
Regards,
-- Paul
On Sun, 15 Aug 2004, Erik Hennum wrote:
>
> Esteemed DITA TC:
>
> In hopes that it will be useful background for deliberations about
> namespaces, I'd like to try to pull together the goals for namespaces that
> seem to have emerged on this thread:
>
>
> 1. We should avoid the twin risks of delaying DITA 1.0 for investigating,
> prototyping, and testing namespace schemes and of rushing into a namespace
> scheme that has to be reworked later.
>
> Our approach now should be conservative so we can solve the problem
> correctly later for the long term.
>
>
> 2. In DITA 1.0, namespaces should be optional.
>
> As Paul asserts, we don't want existing DITA implementers to have to take
> on a major rework of their content and processing.
>
> Conversely, in environments where namespaces are required (Mary's situation
> with Word or Eliot's application), it should be possible to use namespaces
> for DITA content.
>
>
> 3. In DITA 2.0, namespaces should be used to identify specialization
> packages in the typing system for the DITA architecture
>
> Namespaces should identify specialization packages so they can be used to
> match elements with processors and so we can prevent name collisions
> between packages created independently by different designers.
>
> The scheme for managing type ancestry (that is, the values and processing
> of the class attribute) will likely have to be revised to make use of
> namespaces.
>
>
> 4. In DITA 2.0, namespaces should be used to identify DITA shell
> vocabularies.
>
> Namespaces should provide a handle for the vocabularies assembled by DITA
> shells. That identifier makes it possible to match DITA content with the
> best content handler and is especially important for applications that
> understand a specific vocabulary rather than the DITA architecture.
>
> The scheme for declaring the namespace for the shell vocabulary without
> colliding with the namespace for the root element's specialization package
> will need to be thought through.
>
>
>
> I'd propose considering the following approach:
>
>
> 1. We document a namespace pattern to be used for core DITA and its
> specializations and use this pattern to document a standard namespace for
> each specialization package and shell provided in the core DITA
> distribution.
>
> The namespace pattern might follow the pattern proposed by Eric Sirois:
>
> http://{organizationSource}/{DITAVersion}/shell/{documentTypeBasename}
>
> http://{organizationSource}/{DITAVersion}/package/{specializationPackageIdentifier}
>
> Thus, the namespaces for the core DITA distribution would follow the
> pattern:
>
> http://dita.oasis-open.org/{DITAVersion}/shell/{documentTypeBasename}
>
> http://dita.oasis-open.org/{DITAVersion}/package/{specializationPackageIdentifier}
>
> [ Supports Goal 2 ]
>
>
> 2. We don't use the documented namespaces in the DTDs or Schemas provided
> in the core DITA distribution.
>
> [ Supports Goals 1 and 2 ]
>
>
> 3. We provide a caution that a future DITA release may integrate namespaces
> more directly into the DITA type classification system. This change alone
> should not result in any changes to element structures or local element
> names but could change the way namespaces are used on the root element.
>
> [ Supports Goals 3 and 4 ]
>
>
> 4. A DITA adopter who works in an environment that requires namespaces can
> create a wrapper that imports the shell, applying the namespace for the
> shell vocabulary.
>
> For individual topic type shells, the recommended approach might be to wrap
> the topic type in a dita element whose content model allows a single
> instance of the topic. By avoiding declaring the shell namespace for the
> vocabulary on the root element (which may have a specialization package
> namespace in the future), this approach avoids a potential source of
> rework.
>
> For instance, to use a namespaced concept vocabulary, an adopter could
> create a new concept_ns.xsd Schema that includes concept.xsd, defining a
> dita element that contains the concept element and declaring the dita
> element to be in the http://dita.oasis-open.org/1.0/shell/concept
> namespace.
>
> We wouldn't include these wrappers in the distribution because we don't
> encourage the namespaced approach in DITA 1.0. We document this approach
> as a stopgap for those who have to have namespaces before we work through a
> complete scheme for DITA type and vocabulary classification based on
> namespaces. Someone might, however, implement these wrappers based on the
> documentation and put them out on the DITA users's group as a helpful
> community extension to core DITA.
>
> DITA doesn't have a tradition of an untyped container for map, so that
> corner would need to be addressed.
>
> [ Supports Goals 1 and 2 ]
>
>
> 5. Applications can determine the content handler for DITA content through
> awareness of either the DITA shell vocabulary namespaces or the DITA class
> attribute.
>
> An application could require vocabulary namespaces for DITA content and
> match the namespaces for the DITA shell vocabularies provided by the core
> distribution.
>
> Alternatively, an application could accept non-namespace DITA content and
> look for a class attribute that has topic or map as the specialization
> package qualifier in the first position.
>
> [ Supports Goals 1 and 2 ]
>
>
>
> What do you think?
>
>
> Erik Hennum
> ehennum@us.ibm.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]