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


Paul Prescod wrote:
> 
> Eliot Kimber spakest thus:
> 
>>The only other mechanism that seems likely would be some sort 
>>of PI-based declaration, but the W3C has a firm statement 
>>against the use of PIs in XML documents and I think we 
>>should respect that.
> 
> 
> Could you provide a pointer to this statement? 

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 don't think this is a compelling objection--it's easy 
>>enough to examine an entire document for the namespace 
>>declarations within it. It may be tedious but it's not 
>>hard. If anybody needs Java code to do this, I can 
>>provide it :-)
> 
> 
> Why not just put it on the root element always?

Because the root element of a given document may not be a DITA-defined 
element. While it is a typical practice to declare all the namespaces in 
a document on the root, just for convenience, there's certainly no 
requirement in any XML standard to do that and I can't see that we would 
help things by imposing such a requirement.

It's already a fact of XML processing that if you are recognizing 
elements based on their namespaces that you have to look through an 
entire document to be sure you've examined all the namespaces in the 
document. I don't see why DITA processors should be given a pass on this.

I suppose a validating DITA processor could check for the declaration 
and fail any documents that don't have it on the root, but that feels 
like Simon Says behavior since, in the absence of this requirement, 
documents would still be perfectly recognizable as containing DITA-based 
elements.

> If this feature was designed specifically to enable recognition of DITA
> documents by other processes then there is probably no reason to add
> another one. I'm still not clear on the canonical form of a DITA
> document. Is this a DITA document?
> 
> <mydita>
> <foo>
> <bar>
> <baz>
> <mytopic class="- topic/topic mytopic/mytopic " 
> 	xmlns:ditaarch=" http://dita.oasis-open.org/architecture/2005/";
> 	ditaarch:DITAArchVersion="1.0">
> ...
> </mytopic>
> </baz>
> </bar>
> </foo>
> </mydita>

If by "DITA document" you mean "a document that contains one or more 
DITA-based elements", then yes.

If by "DITA document" you mean "a document whose root element is 
DITA-based", then no.

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.

So as far as I'm concerned, the first meaning is the useful one.

That also suggests that the concept of "canonical form of a DITA 
document" is not meaningful--DITA allows too much variation in how 
documents are constructed. DITA processors have to deal with DITA 
elements however they find them.

If there is a useful notion of "canonical DITA document" then it must be 
in terms of a "view document" that reflects just those aspects of the 
real document that are DITA-based (that is, correctly derived from 
DITA-defined types).

Cheers,

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

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



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