[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] namespaces goals
Erik's proposal seems to make sense for our needs. Rob Rob Frankland, President & CEO Rascal Software 1511 3rd Ave, #523 Seattle, WA 98101 206-624-7300 -----Original Message----- From: Paul Antonov [mailto:apg@syntext.com] Sent: Tuesday, August 17, 2004 7:46 AM To: Erik Hennum Cc: dita@lists.oasis-open.org 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/{specializationPacka > geIdentifier} > > 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/{specializationPackag > eIdentifier} > > [ 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]