Re: [dita] Use of standardized prefixes when incorporating foreignvocabularies

[Eric Sirois <esirois@ca.ibm.com>]

Hi Eliot,

I should elaborated the fact the I'm not saying we should
specify/mention/suggest the use of a specific prefixes for foreign
vocabularies in the DITA spec.

The issue is that if I include MathML DTD as a foreign specialization ...I
define the prefix mml for my specialization.  In your case you prefer math
as the prefix.  We both use our favorite XML editor to write up the topics.
You try to process that topic within your publishing stream  which use your
specialized version of MathML and the parser is throwing some errors
because it does not recognize the mml prefix.

I would like to add note something like the following ("When using DTDs to
specialize a namespaced standard vocabulary using the foreign element if
the foreign vocabulary has more than one common namespace prefix, use the
standard prefix."   ) in the spec informing user, for DTDs only stating
that some care should be when integrating foreign content libraries because
the above issue can occur when sharing content between two companies that
have different publishing streams.

I know that we can't keep folks from running into this issue. We should,
at least, have a cautionary statement in that spec with the hopes that it
can proactively avoid having questions regarding this issue from popping on
the dita-users forum.
    -- Caution:  Flying monkeys may swarm when integrating namespaced DTDs,
clicking your heels three time will ease or alleviate the pain, when
possible please remain on the yellow brick road.  ---- How a users stays on
the yellow brick is up to them...but we did tell them stay on the yellow
brick road.

My apologies for the analogy...my wife was watching the movie the other
night. ;-)

Kind regards,
Eric
Eric A. Sirois
Staff Software Developer
DB2 Universal Database - Information Development
DITA Migration and Tools Development
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Phone:(905) 413-2841
Blue Pages (Internal)

"Transparency and accessibility requirements dictate that public
information and government
transactions avoid depending on technologies that imply or impose a
specific product or
platform on businesses or citizens" - EU on XML-based office document
formats.


                                                                           
             "W. Eliot Kimber"                                             
             <ekimber@innodata                                             
             -isogen.com>                                               To 
                                       Eric Sirois/Toronto/IBM@IBMCA       
             10/06/2006 12:50                                           cc 
             PM                        dita@lists.oasis-open.org           
                                                                   Subject 
                                       Re: [dita] Use of standardized      
                                       prefixes when incorporating         
                                       foreign    vocabularies             
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Eric Sirois wrote:
> While helping a user understand/integrate MathML DTD using the foreign
> element the example in the proposal it used the mml prefix while the DTD
> itself defines the prefix m.  Another example would be the use of
namespace
> prefix xs and xsd for XML Schemas.  When using DTDs, it is quite possible
> that  two different organizations can create two perfectly legal
> specializations using two different prefixes.  The topics created based
on
> the two specialization is no longer shareable.

I'm not sure why you say this: each topic must be initially validated
and processed in its own document context and that document context must
specify the correct namespace URI for the local prefixes.

Any processor that processes the two topics in the same process in order
to produce a new instance reflecting the combining of those topics in
some way and doesn't either rewrite the prefixes or locally declare the
namespaces is simply not a namespace-aware process and therefore not a
candidate for use in this case.

That is, once you start using namespaces for anything, all your tools
need to be namespace aware. Expecting that prefixes will be consistent
and invariant is simply not realistic.

In addition, this points up the fact that DTDs, as opposed to XSD
schemas and similar namespace-aware constraint mechanisms, are really
not viable options for handling namespaced data for the simple fact that
the constraint specifications are not themselves namespace aware,
meaning that you are dependent on the local prefixes. That is, DTDs
cannot reflect the fact that <foo xmlns="bar"> and <foo xmlns="baz"> are
two fundamentally different element types.

This is one reason that I don't see DTDs being useful *at all* in a
general XML context and begin to question the wisdom of any standard,
DITA included, providing DTDs except as a convenience or as a way of
expressing requirements (without expecting the declarations to be used
literally with documents). The problem with the DITA specification as
currently defined is that it imposes constraints on the structure *of
the DTDs*, which somewhat puts it in an untennable position.

I continue to assert that DITA should be making no normative
requirements on how documents' constraint specifications are
constructed--it should only be making requirements on the rules for
document instances. Any DTD or schemas normatively defined by DITA
should be meta schemas that define rules that instances must conform to
but that are not necessarily the literal specifications of those rules
that all instances are expected to use.

Cheers,

E.


--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com