[
Lists Home |
Date Index |
Thread Index
]
- To: xml-dev@lists.xml.org
- Subject: Best practices for default values for attributes?
- From: Michael Good <musicxml@yahoo.com>
- Date: Thu, 10 Mar 2005 12:14:28 -0800 (PST)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=kUT6FlI9zul53/NZeAzgoHENGRrnKjWPOTYQhAAdhiiyTzeUNm2ayiLpp7tyFid3TKMHwV16L1QG/RbRs1zI+RvouI1vUGPt+hHxd94M0/iEp2d7dVWHenu4N1EDcPbYcsp3hakDtqpSUYlVSn2BMG61vFLE1xioiWj4gCgwYok= ;
We are in the process of updating the MusicXML language from version 1.0 to
version 1.1. MusicXML represents common Western music notation from the 17th
century onwards, and is currently supported by over 40 applications. MusicXML
is very much in the "document" camp of XML usage and still uses DTDs. For
compatibility, all valid MusicXML 1.0 documents will also be valid MusicXML 1.1
documents.
The main focus of this update is to add more music formatting data. Following
MusicXML's overall design, this formatting data is usually expressed in
attributes rather than elements.
Adding all these attributes is leading me to revisit one of MusicXML 1.0's
decisions about using default attributes. Usually, MusicXML uses #REQUIRED or
#IMPLIED without a default value, even when there is a common default that
applications should use when the attribute is missing. This is especially true
where an attribute is only used in an unusual situation, and 99% of the time it
uses the default value.
I found that various validating XML readers and editors would clutter the XML
display with the default values of the attributes, which you generally do not
want to see when looking at the XML file. So MusicXML 1.0 only uses default
attribute values where they help the readability of a file when viewed in a
validating display.
We have had feedback from some users - not a lot, though - that they would like
to see MusicXML make more use of default values for attributes. If you are
using a validating parser, this should make some code easier to write, but I am
not sure it is worth the tradeoffs. I was wondering what people think current
"best practices" are in this area. I don't see it covered in Effective XML or
in other online writings on XML style.
Thanks for any advice!
Best regards,
Michael Good
Recordare LLC
www.recordare.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
