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

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

Hi Eliot,

You are correct.  Locally, the files are valid.  Once the document(s) are
shared with the other company,  they are no longer valid against their
local version of the DTDs because of the different hardcoded prefixes.

Another use case for this issue are XML Editors supporting DITA embedding
support for foreign vocabularies, for instance MathML - I know of two so
far, within their applications.  One decides to use math as the prefix and
the other decides to use mml as their prefix.   The spec should provide
some guidance on which prefix they should use for their implementation.

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 02:42                                           cc 
             PM                        dita@lists.oasis-open.org           
                                                                   Subject 
                                       Re: [dita] Use of standardized      
                                       prefixes when incorporating         
                                       foreignvocabularies                 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Eric Sirois wrote:
> 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'm confused by the "parser...does not recognize the MML prefix" because
it's not a parser issue--that is, either the topic is valid with respect
to its governing DTD or schema or it's not. When authoring a document it
would not be possible to create one with the wrong prefix assuming the
editor is syntax driven or I'm validating as a I go.

Once I get to the point of processing, anything that is MathML-aware
better by gosh be looking for the MathML namespace URI and not a
particular prefix. If my processor is in fact expecting a particular
prefix then my processor is broken, which is a "my processor is broken"
issue, not a namespace prefix or DTD vs. schema problem.

If somebody has the expectation that they can take two topics created
using different local schemas (DTD or XSD doesn't matter) and blindly
smash them together into the same document instance then they are simply
not thinking clearly because it's never possible if you expect to use
one or the other of the original document's DTDs to validate the result,
as a general case (of course it might work in a particular case but that
would just be coincidence).

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