Re: [xml-dev] RE: Highly Declarative Designs

[Frank Manola <fmanola@acm.org>]

Roger--

Let me try a different variant of your examples, and ask some questions about it.  Suppose we have an HTML5 audio element:

  <audio>
     <source src="example.mp3">
  </audio>

and a question that I want answered is "what note is the soloist singing in the first beat of measure 58?"  

With the HTML5 as written, this question is not readily answered.  I'm going to need an app to play the music, pick out what the soloist is doing from the background, and determine the pitch.  This may be expensive and error-prone.  

On the other hand, consider an alternative design something like:

  <audio>
   <source src="example.mp3">
   <note part=soloist measure=1 beat=1>bflat</note>
   <note part=soloist measure=1 beat=2>csharp</note>
   ...
   <note part=soloist measure=58 beat=1>gnatural</note>
  ...
   <note part=piano measure=1 beat=1>eflat</note>
 ...
 </audio>

Now I can obtain the answer to the question by exclusively navigating markup.  I assert that the second form is highly declarative with respect to note information.  

Now since I concocted this second design on the fly, I don't want to argue about the merits or demerits of the details of this particular "design" (to use the term loosely!), but do you believe that a design embodying any kind of remotely similar ideas, despite it being "highly declarative", is a way to represent music that you would recommend using "wherever possible"?   If so, suppose I say that I might also want to be able to answer the question "how many key changes are there in this performance"?  Applying the same "design" principles, I could add sufficient markup to enable this added question to be answered by exclusively navigating markup as well, presumably creating an even more highly declarative design.  Does that make this design even more preferable, and to be universally recommended, than the second one?  

--Frank

On Feb 8, 2011, at 8:01 AM, Costello, Roger L. wrote:

> Hi Folks,
> 
> Thank you John, Frank, and Kurt for your comments. I am still contemplating them.
> 
> Today I found an example [1] from HTML5 which illustrates the difference between a design that is highly declarative versus one that is not.
> 
> HTML5 has an <audio> element. You can specify multiple file formats using the <source> element. E.g.,
> 
>    <audio>
>        <source src="witchitalineman.ogg">
>        <source src="witchitalineman.mp3">
>    </audio>
> 
> A browser that can play back Ogg Vorbis files will look no further than the first <source> element. A browser that can play MP3 files but not Ogg Vorbis files will skip over the first <source> element and play the file in the second <source> element.
> 
> You can help the browsers by providing the mime types for each source file: 
> 
>    <audio>
>        <source src="witchitalineman.ogg" type="audio/ogg">
>        <source src="witchitalineman.mp3" type="audio/mpeg">
>    </audio>
> 
> 
> I assert that the second form is highly declarative with respect to mime type information. 
> 
> Consider this question:
> 
>   What is the mime type of the audio files?
> 
> With the second form the question is readily answered simply by navigating to the type attribute. Using XPath this is accomplished as follows:
> 
>    audio/source[1]/@type
>    audio/source[2]/@type
> 
> With the first form the question is not so readily answered. It requires an application (e.g., browser) to parse "witchitalineman.ogg" and infer the mime type from the file name suffix.
> 
> My recommendation is to use the highly declarative design. In the above example, that means use the second form.
> 
> Comments?
> 
> /Roger
> 
> [1] The example comes from the book, "HTML5 for Web Designers" by Jeremy Keith.
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>