[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Use of standardized prefixes when incorporating foreignvocabularies
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]