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] Proposed Issue: Recognizing DITA Documents


> Not without some research, but I was on the XML Namespace 
> committee when we had a big fight about whether or not to 
> use PIs for declaring namespaces. Tim B-L sent down an 
> edict to the effect of "thou shalt not use PIs". So I'm 
> pretty confident in my statement.

I would argue that the design constraints in effect were quite different
than those that are applicable for DITA. And the W3C has defined
processing instructions for stylesheet attachment.

> But the second meaning is not that useful--that is, it 
> doesn't really matter whether a topic is or is not the 
> root element of a document, at least for the purposes 
> of applying DITA-defined semantics and process.

While I agree that there is value in defining the semantics of DITA
topics even as they might be found in the middle of a non-DITA document,
I think that it is of much greater practical importance that the
documents that XMetaL creates be consumable by the DITA toolkit, by
other authoring applications and by content management systems. If I
pump a SOAP message with DITA content buried in it through the toolkit I
do not necessarily expect output. Only a document rooted in DITA has
semantics that are totally defined by DITA. There is a classic problem
with applications trying to interpret fragments without knowledge of the
context.

<my_xml_scripting_doctype>
  <if test="SomeXpressionInSomeLanguage()">
           <topic>...</topic>
  </if>
  <else>
           <topic>...</topic>
  </else>
</my_xml_scripting_doctype>

A tool that has only been configured for DITA (and doesn't know the
semantics of the surrounding language) will totally misunderstand what
it is supposed to do with this document. This is an extreme and
unrepresentative example of the problem but it can occur in many
contexts. (for example, processors that pull titles out of DITA
documents will only be reliable if DITA documents are reliably
structured)

That's why I think it is important to have a clear definition for a
"DITA Document". If some people wish to also use DITA elements and
topics in contexts other than "DITA Documents" then that is also fine.

 Paul Prescod



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