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

Re: Choosing a target name for a processing instruction

  • To: xml-dev@l...
  • Subject: Re: Choosing a target name for a processing instruction
  • From: "Michael Good" <musicxml@g...>
  • Date: Mon, 1 May 2006 11:14:41 -0700
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=jmPkMfXwEAfAmYgZUrqM7o5/LR5vorlfYaMrZVFYN1XIHaj32M5kRAmPLo4netN64gDGP3JWwFKWOT3MUsCsJGTyglWgNuCo0ySVqqgHLlezbqn947UIyJTSg+R/C5UIO7s2Lm0PbpPJ/F0sHNU2Pwi0GV2cKJ+I87O4OKU36YY=

writing processing instructions
Thanks for all the great feedback!

We always encourage MusicXML developers to use validating parsers.
Music notation is complicated, so MusicXML has grown quite large to
accommodate everything that is needed for industrial-quality
interchange of documents between programs. Validation has been a huge
help in making document interchange work better for our audience of
composers, arrangers, engravers, publishers, and other musicians.

MusicXML has had its success in large part by being
developer-friendly. For instance, when we updated to MusicXML 1.1, we
made sure that all valid MusicXML 1.0 documents are also valid
MusicXML 1.1 documents. There's no way we can have the flagship
MusicXML writer produce invalid documents. Fortunately, SOAP's
limitations aren't an issue for MusicXML applications.

We have just two applications that really need this added
functionality ASAP - our writing application and a third-party reading
application. It turns out that writing a processing instruction
without a data field is problematic with our Java/Xerces combination,
so instead of using

<?feature?>

we are now using

<?treat-like feature?>

This indicates that the following element would really be treated as
another element if only that element had a little more extensibility
to it. This provides the extra generalization that Peter suggested,
without requiring any parsing overhead beyond doing two exact matches
instead of one.

Elliotte, you're right that any application that reads this processing
instruction won't be able to get rid of the PI-reading code.
Fortunately that may just be one application, though anybody else will
be free to join in. But we should be able to get rid of the PI-writing
code when MusicXML 1.2 comes out.

MusicXML is developed via an informal community process, so we can't
just release a patch version as quickly as we need for this feature.
As long as the reading application's parser can handle a simple
processing instruction, we should be OK.

Rick, we've already discussed this with the developers that needs this
feature now, and we'll be discussing this on our MusicXML list with
the major MusicXML implementers later today. I wanted the broader
advice of the XML developer community to help develop the initial
proposal. It has been very helpful. Thanks again!

Best regards,

Michael Good
Recordare LLC
www.recordare.com

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
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

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.