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] some remaining architectural spec questions


Michael Priestley wrote:
> *3) should we remove a reference to architectural forms?*
> the description of the class attribute describes how it differs from 
> architectural forms. is this positioning necessary for our audience?
> current wording:
>  >>>
> The class attribute tells a processor what general  classes of elements the
> current element belongs to./ It's something like an  architectural forms 
> attribute,/
> /except that it contains multiple mappings  in a single attribute, instead/
> /of one mapping per attribute./  Also, DITA  scopes values by module 
> type (for
> example topic type, domain type, or map type) instead of document type, 
> which
> lets us combine multiple topic types in a single document without 
> complicating
> transform logic.
>  >>>

I would vote to remove it simply because the number of people who 
actually know about SGML architectures is probably vanishingly small. 
It's interesting historically but I don't think it's relevant to our 
target audience.

> *4) catalogs and public identifiers*
> should we add these to the spec?

I vote no on catalogs: they are an implementation detail. They should be 
included with the DTD and schema distributions but they should not be 
normative, any more than the XSLTs in the toolkit are normative.

On public identifiers: while I have no personal use for public 
identifiers, I grant that they have a practical use (partly because of 
Xerce's broken implementation of URI resolution through catalogs which 
essentially prevents recursive resolution of URIs). If we have normative 
URIs for the DITA namespace(s) and schemas, I see no reason not to also 
have normative public IDs for at least the top-level external 
declaration sets.

Cheers,

Eliot

-- 
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]