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


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]