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