Restrictions when storing XML within script elements

Added by Eric van der Vlist about 11 years ago

As documented by "Norm Walsh at XML Prague 2011":http://norman.walsh.name/2011/03/26/HTML-XML-Prague#p77, so called XML data islands are seen as text nodes when located in script elements in HTML source documents.

Thanks to Saxon CE's magic it is possible to insert actual nodes inside script elements (like inside any other elements). The result is unfortunately leading to hybrid DOMs with imperfect (and browser dependent) support of upper cases and namespaces.

This repro case illustrates some of these issues:

HTML:


    
        <title>XML Island</title>
        <script type="text/javascript" language="javascript" src="saxon/SaxonceDebug/Saxonce.nocache.js"></script>
    <script type="application/xslt+xml" language="xslt2.0" src="repro-script.xsl" data-initial-template="init"></script>
    <script type="application/xml" id="script">
    </script>
</head>
<body>
    <pre id="document"></pre>
</body>

XSLT:




    


    
        
            
                
            
        
        
            
        
    

    
        
             
            ixsl:serialize-xml($script): 
            
            
----
namespace-uri($script): 
            
            
----
namespace-uri($script/*): 
            
            
----
name($script/*): 
            
            
----
ixsl:get($script/*, 'nodeName'); 
            
            
----
local-name($script/*): 
            
            
----
ixsl:get($script/*, 'localName'):

The result when run with Firefox is:

ixsl:serialize-xml($script): 
----
namespace-uri($script): http://example.com
----
namespace-uri($script/*): http://example.com/ns
----
name($script/*): bar
----
ixsl:get($script/*, 'nodeName'); Bar
----
local-name($script/*): bar
----
ixsl:get($script/*, 'localName'): Bar

And with Chromium:

ixsl:serialize-xml($script): 
----
namespace-uri($script): http://example.com
----
namespace-uri($script/*): http://example.com/ns
----
name($script/*): bar
----
ixsl:get($script/*, 'nodeName'); Bar
----
local-name($script/*): bar
----
ixsl:get($script/*, 'localName'): Bar

For both browsers, the case is preserved in JavaScript node's names properties but names are still converted to lowercase when accessed from XPath expressions.

Both browsers keep namespace uris information but appear to loose namespace prefixes.

Chromium appears to have an additional issue with its serialization that strips namespaces declarations.

Should we just admit that namespaces and upper cases shouldn't be used in such cases or is there any hope Saxon CE could improve this situation?

Thanks,

Eric

Replies (2)

RE: Restrictions when storing XML within script elements - Added by Michael Kay about 11 years ago

I think we should accept that storing XML in data islands is always going to be problematic. Admittedly there are some things we could do better: the case folding to lower case when using XPath is something Saxon does when we access the HTML DOM. We could try and refine the conditions under which we do it but it would just add warts on top of warts.

Perhaps a more promising approach is to provide some better place to store XML fragments where they can be retrieved later, perhaps even as a property of a node in the HTML tree, but not actuall part of the tree.

RE: Restrictions when storing XML within script elements - Added by Eric van der Vlist about 11 years ago

Yes, storing XML fragments outside the HTML DOM seems much saner.

OTH, and this is something on which I should elaborate during my presentation at XML Amsterdam, the benefits I was trying to achieve by storing these island inside the HTML DOM are:

That I can update specific elements (using xsl:result-document) and attributes (using ixsl:set-attribute) within these fragments rather than replacing the whole fragment.
That events fired on nodes from these fragments can trigger XSL templates (I have read in the doc that this is also possible for any object but the syntax for HTML nodes is much easier).

If XML fragments are stored outside the HTML DOM I think that it would be useful to insure that we can keep these two features.

Thanks,

Eric

(1-2/2)

Please register to reply

Project

Profile

Help

Saxon » Saxon-CE