OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Choosing a target name for a processing instruction

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: RE: [xml-dev] Choosing a target name for a processing instruction
  • From: "Michael Good" <musicxml@gmail.com>
  • Date: Tue, 2 May 2006 16:12:39 -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=jKRWznaVZTiF+/Blpj8sx24DX4SQPfyvqkqC8EeAcP6zQ8OTi7yUCUaT5/hKo4tQJg7vCP9uW2tcvOz9819pmoJWHWozWVnNHpFME3vzzjaZIarHGpAE0BU8pwB4BaVv0VontTQycWzL34HFB/lzdgNe7R7esAC/Bk4Bw+wuI+g=

> Why is this? Xerces can report PIs...

Well, maybe I'm doing something wrong, but when I tried to use

  ProcessingInstruction pi = doc.createProcessingInstruction("feature", "");

the result was

<?feature ?>

instead of


Multiple XML parsers complained that a document using the former is
not well-formed. Maybe there's a different way to make it work, but
just adding some simple PI data seemed more robust, and it was a
trivial fix.

Unfortunately I think this is moot for this case. One application that
needs this is written in Flash ActionScript, which only handles two
types of DOM nodes: elements and text. (Attributes are handled via a
separate attributes property.) Processing instructions seem to be
discarded, no matter what the XML spec says should happen, even in
Flash 8. If I'm wrong about that, please let me know!

I think the reading application will be able to handle things by
(shudder) exploiting a side effect in how the writing application
works. It's not clean, but it may do the job until we get a MusicXML
1.2 out. That just needs to happen before the writing application
changes enough to break this side effect.

Currently we leave validation policy up to each individual
application, which has worked pretty well in practice. Because later
versions are supersets of earlier versions, it's easy to check for the
MusicXML version and just ignore any extra elements or attributes you
don't understand. The syntax and semantics of the existing DTD subset
doesn't change. If that wasn't true, perhaps we would need more
elaborate policies.

Thanks again,

Michael Good
Recordare LLC


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS