Re: [dita] Namespaces and Schemas: Some Initial FindingsandXSLT Implications

[Eliot Kimber <ekimber@innodata-isogen.com>]

Paul Grosso wrote:

> At 10:04 2004-06-29 -0500, Eliot Kimber wrote:
> 
>> Paul Grosso wrote:
>> 
>> The whole issue of defaulted attributes in XML is one of the XML
>> Big Lies, namely the assertion that there is no markup minimization
>> in XML. There isn't *except* for defaulted attributes. In thinking
>> about it now this suggests that there ought to be a simple,
>> schema-compatible, way to define attribute defaults that is
>> separate from the larger function of defining data types and
>> content constraints so that processors could easily implement
>> attribute defaulting without having to step up to full schema
>> awareness, but it appears that this idea got lost in schema land
>> (not surprisingly). Hmmm.
> 
> 
> You can always declare attribute defaults in a separate file in DTD
> syntax and then reference that file from the document instance's
> internal subset or as the document's external subset.  The fact that
> one is using an XML Schema to validate things in no way prevents one
> from using DTD declarations to do some things such as define
> attribute defaults.

This is true but not an approach I want to use unless there is no other 
alternative. This is for two reasons:

1. It would require maintenance or generation of redundant declarations 
as the attributes would have to be reflected in both a set of markup 
declarations and in the governing schemas.

2. It reintroduces the problem of having XML document instances that 
consist of more than one external entity. That is, my whole motivation 
for using schemas and not DTDs is to enable single-entity instances.

However, having said that, I am forced to acknowledge that the use of 
default attributes to drive processing has the effect of establishing a 
hard dependency between document instances and schemas such that a 
document cannot be processed without both knowing what the governing 
schema is and having access to it at processing time. It may be that 
this level of dependency is simply unavoidable in order to have the 
sophistication and leverage that a DITA-style architectural mechanism 
provides. To some degree it doesn't matter if this dependency is 
syntactic (DTDs) or semantic (schemas). [In the context of content 
management, avoiding syntactic dependencies avoids a number of issues 
that serve to complicate content management.]

This all means that there is no way that a DITA document can be 
processed it terms of its class mappings without telling the processor 
what the class mappings are.

In an SGML-style world using fixed attributes made sense because you 
always had to fully declare everything anyway so adding a few more 
attributes didn't really add any cost.

In an XML world, where DTDs are optional, it may make less sense to use 
fixed attributes because it has the effect of requiring a schema or DTD 
where none would otherwise necessarily be required (that is, 
transformation has not requirement on validation).

It may, as I think Paul Antonov is trying to express, make sense to have 
a DITA-specific, XML-based mechanism for defining the mapping that would 
be independent of schemas and DTDs.

This would have the advantage of being independent of whatever document 
constraint mechanism you chose to use. But it would require more 
complicated DITA-specific processors. For example, you wouldn't be able 
to use normal match expressions to match elements based on their mapping 
but would have to define DITA-specific extension functions to resolve 
the mapping. This wouldn't be hard to do in either XSLT 1.0 (at least 
using an exslt-aware processor) or XSLT 2.0 but it would have to be done.

In thinking about it now I think this approach deserves carefull 
consideration. At a minimum it meets the "courses for horses" 
engineering principle, rather than trying to repurpose an existing 
mechanism to a purpose it was neither designed for nor is particularly 
well suited to.

>> In any case, it poses a practical problem, hopefully addressed by
>> the code mentioned in Eric's post on this same topic.
> 
> 
> I may be stepping into a hornet's nest here, but let me suggest that
> we shouldn't let the lowest common denominator of free software that
> doesn't completely implement existing standards determine critical
> issues in the design of DITA.

I agree in principle: standards shouldn't be driven by limitations in 
existing technology. But at the same time, DITA is fundamentally a 
practical solution to immediate problems so we have to at least 
understand when a particular feature can be used using easily available 
tools.

Cheers,

E.
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9030 Research Blvd, #410
Austin, TX 78758
(512) 372-8122

eliot@innodata-isogen.com
www.innodata-isogen.com