RE: XSLT, XHTML, and default attribute values [somewhat OT]

At 08:03 AM 9/14/2004, Andrew wrote:
> > that's true.  but then why not just remove the DTD
> > altogether?  then you don't have to support obscure and/or
> > parser dependant configuration options.
>
> I'm not sure it is true.  If a DTD is specified in the xml the parser
> *must* attempt to read it to ensure any defaulted values are present in
> the XML, regardless of configuration.  Turning off validation (I think)
> simply suppresses validation errors.  The only way I know of to parse an
> xml file with a DTD specified (without access to the DTD itself) is to
> implement a custom entity resolver.  Of course, you can edit the XML
> file prior to transforming to remove the doctype, but regex'ing over xml
> markup just feels wrong.
>
> I don't understand the benefits of using defaulted values, as anyone
> studying the xml also needs to study the dtd to ensure they get the full
> picture.  Seems crazy, really.
The biggest direct benefit is from tools that leverage the DTD to provide 
authoring support for creators of markup.
Likewise, there's the philosophical position that a DTD in some sense 
represents a kind of Platonic ideal of the document markup, in which it's 
appropriate to declare things like what an attribute should be if it's not 
otherwise stated. If you don't do this in the schema (small 's') you have 
to find some other way of recording and implementing such expectations; and 
the schema is not self-sufficient as a specification of the "document type" 
(not that it ever really was).
That being said, it's a perfectly defensible position (IMHO) that 
defaulting attributes can and should be done in a transformation, at least 
in many architectures.
This is another case (like its weakness in up-conversion) where it becomes 
apparent how XSLT 1.0 was designed for "terminal" transformations 
(formatting output for display), not medial data-massaging, where the 
output conforms to the same DTD as the input, and hence doesn't need to 
render defaulted attribute values.
Different kinds of application scenarios have different functional 
requirements for their various stages. Alert the media.
Cheers,
Wendell


======================================================================
Wendell Piez                            
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================