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: Simplest Namespace That Could Possibly Work

There may be a blindly simple way to solve the 1.0 namespace issue:

Have a namespace-bound schema that defines only the DITA class attribute.

This would:

- Satisfy my requirements for having documents be unambiguously bound to 
the DITA specification

- Bring the DITA class attribute, which is the key to all DITA-specific 
processing (because it enables recognition of element types derived from 

- Otherwise avoid all namespace issues related to specialization, schema 
organization, and so on.

Given this approach, the only change would be to the class attributes 
themselves, to wit:

DITA as submitted to OASIS:

<!ATTLIST topic %global-atts; class CDATA "- topic/topic ">
<!ATTLIST title %global-atts; class CDATA "- topic/title ">

DITA with namespaced class:

<!ENTITY % ditabase-ns-decl

<!ATTLIST topic
   %global-atts; dita:class CDATA #FIXED "- topic/topic"
<!ATTLIST title
   %global-atts; dita:class CDATA #FIXED "- topic/title"

A DTD-based document instance would be visually indistinguishable from 
an existing one, although the parsed document would obviously differ in 
having "dita:class" intead of "class" and would have the namespace decls:

<?xml version="1.0"?>
<!DOCTYPE topic SYSTEM "uri-of-dita-DTD-declaration-set">
<topic id="topic-01">

A schema-valid document could look like this:

<?xml version="1.0"?>

A minimal document (no schema or DOCTYPE declaration would look like this:

<?xml version="1.0"?>

Note that all three of these documents are 100% clear about being DITA 
documents by dint of the fact that all declare the ditabase namespace, 
but their processing and validation mechanism is otherwise completely 
unchanged from current DITA practice.

Existing DITA-aware processors would need only add an OR clause to their 
"class" attribute check in order to accomdate both legacy DITA instances 
and OASIS DITA 1.0 instances, e.g:

<xsl:template match="*[(contains(@class, ' topic/topic ') OR
                        (contains(@dita:class, ' topic/topic ')" >

All other processing would be unchanged (because no other names would be 



W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122


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