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