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: RE: [dita] namespaces goals


We've heard from two vendors who favor Erik's proposed approach to rolling out namespaces for DITA. If you have an application that requires a namespace declaration in order to function properly, please respond as to whether you can live with the proposal. Let's aim this week to wrap up any debate on the proposal so that we can close on it at next Tuesday's regular meeting.

Regards,
--
Don Day <dond@us.ibm.com>
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
11501 Burnet Rd., MS 9037D018, Austin TX 78758
Ph. 512-838-8550 (T/L 678-8550)

"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
Inactive hide details for "Rob Frankland" <robf@rascalsoftware.com>"Rob Frankland" <robf@rascalsoftware.com>


          "Rob Frankland" <robf@rascalsoftware.com>

          08/17/2004 10:35 AM


To

"'Paul Antonov'" <apg@syntext.com>, Erik Hennum/Oakland/IBM@IBMUS

cc

<dita@lists.oasis-open.org>

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


GIF image



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