It's perfectly XML compatible, but the draft as printed provides
architectural DTD declarations that assume the use of typical SGML features
(i.e., markup minimization) and does not provide an alternative set of
declarations that restricts itself to those SGML features used by XML.
Obviously anyone could create those declarations (as I did for HyTime in
developing my PHyLIS tool), but there's no reason for the editors not to
provide it directly given that it's an obvious requirement (and in fact, it
should have always been the policy that two forms of architectural
declarations be provided, one for SGML declarations that allow markup
minimization and one for SGML declarations that do not, which is the key
difference {whether or not start and end tag parameters are prohibited}).
The concepts defined in the standard are independent of syntax. If you're
simply implementing the semantics but not using true architectural
processing, then you don't care about the details of the declaration syntax
of the architectural meta-DTDs, using them simply as documentation and not
as processible data sets.
Remember that when defining any sort of SGML application (that is, an
application of SGML, not software that processes SGML), the *ONLY* thing
that would make it not usable with XML documents would be the requirement
that docments use an SGML feature that XML does not provide. As data
entities is the only feature of SGML not provided by XML that also has
significant *semantic* utility (as opposed to being a syntactic convenience
like markup minimization or the LINK feature), you'd have to go out of your
way to make your application not XML compatible. And in any case, you can
get by without data attributes, although it's clumsy and suboptimal.
Cheers,
E.
-- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address>