Lists Home |
Date Index |
- To: Elliotte Harold <firstname.lastname@example.org>
- Subject: Re: [xml-dev] Best practices for default values for attributes?
- From: Michael Good <email@example.com>
- Date: Thu, 10 Mar 2005 13:44:55 -0800 (PST)
- Cc: firstname.lastname@example.org
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=1llecxy7pUoIMrX3soC3o/PC6csUew8PwOgxkpRkRh/NU+mViEFxDaZIvsA5kE9xNjTuy61mG2iShwGi5E/m+uOrOMq+mj/cFCAOidCR55GYjXEeupoeBjOW47tRdKdon2pxCF5xHeqMV6tVgOSvHiaQeaubxTPQpdcfnWjdSLk= ;
- In-reply-to: 6667
Thanks! I did see that, but that seemed to be more for encoding the MusicXML
document than designing the MusicXML DTD. So you're saying that this principle
should also apply to authoring DTDs - define defaults for missing values in the
spec, but don't use default attributes?
What happens in that case is that you have to write the same type of code with
a validating parser as a non-validating parser. That can make things more
robust across changes in parser technology, DTD version changes, and the like.
But one could argue that it makes the DTD harder to read and use.
I'm leaning towards keeping things as-is and not adding default values, but I'm
interested in the experiences of people using XML for document interchange in
--- Elliotte Harold <email@example.com> wrote:
> You aren't looking in the right chapter. :-) Item 18, "Include all
> information in instance documents" strongly recommends against using
> default attribute values. The problem arises when processing documents
> with tools like browsers that don't read the DTD.
> I wasn't aware of the problem with editors cluttering the display with
> default attribute values (I mostly use plain text editors myself) but
> that sounds like another good reason to avoid default attribute values.
Do you Yahoo!?
Make Yahoo! your home page