DAS2 spec issues [was Re: [DAS2] Re: Apollo and DAS/2 priorities]

[Andrew Dalke]

Nomi:
> the sax parser i'm using has trouble with the XHTML element in
> features4.xml that has embedded xml markup:
>
>    <XHTML xmlns="http://www.biodas.org/extension">
>         <p>This is a tiny example of an <acronym title="Extensible 
> HyperText
>         Markup Language">XHTML</acronym> document.</p>
>    </XHTML>
>
> the parser thinks that there are elements called "p" and "acronym".

But there *are* elements called "p" and "acronym".  I meant
it that way.

With embedded XML you should be able to parse the entire
file into a DOM (or equivalent for your parser of choice).
When you find an extension element you can pass that node
and not have to do another translation/parsing step.

I see that as an advantage to embedding XML in XML.

The other option is to escape the XML (in one of several ways)
and only process it when you need it.

> getting it to handle that correctly will be a pain (because the parser
> has already predigested the xml at that point).  is this something 
> we're
> really going to see in the genome annotation data?

This is a proposal by me.  It's not been vetted by others.
I think of it as an escape hatch.  Some servers and clients will
make use of data that DAS cannot handle.  They can put it in
these extension elements.

Once that element gains wider use, we'll migrate that data into
a DAS element.

For example, a client may decide to support rich text notes,
with HTML-like markup in some XML format.  Suppose it's
called SuperDasViewer.  It can add an element in some namespace
and use it like

<note xmlns="http://super.das.viewer/" updated="2006-01-30">
Based on <a href="http://someplace.else/">the expression data</a>
plotted on a <i>Zyderberg matrix</i>
<img src="../images/zyderberg.png" /> it's obviously a promoter
region.
</SDV:note>


					Andrew
					dalke at dalkescientific.com