[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XSLT, XHTML, and default attribute values [somewha

Subject: RE: XSLT, XHTML, and default attribute values [somewhat OT]
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 14 Sep 2004 12:58:31 -0400
xhtml default
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@xxxxxxxxxxxxxxxx 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 ======================================================================


--+------------------------------------------------------------------ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/ or e-mail: <mailto:xsl-list-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx> --+--

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.