[2/2] msxml3: Support xmlns[:*] attribute nodes intelligently.

[Nikolay Sivov]

On 6/12/2012 11:55, Ulrik Dickow wrote:
> Patch 2 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 .
>
>
>

> +    /* Emit appropriate fixme or warning in case of unsupported or invalid namespace.
> +     * The W3C spec would like us to exit earlier for attempts to redefine the namespace for
> +     * the reserved "xmlns" attribute or prefix (http://www.w3.org/TR/xml-names/#ns-decl),
> +     * likehttp://gdome2.cs.unibo.it/gtk-doc/gdome2-gdomeelement.html#GDOME-EL-SETATTRIBUTENS,
> +     * but since native msxml3 accepts anything here, it's safest to just continue with warning.
> +     */
The question is more like what libxml2 thinks about that. If it follows 
w3c here which is likely the question will be - won't it break somewhere 
internally in libxml2 code if we hack it that way?
> +    if(namespaceURI && namespaceURI[0] && node_type != NODE_ELEMENT)
> +    {
> +        if(node_type == NODE_ATTRIBUTE)
> +            switch((!strcmpW(name, xmlnsW) ||
> +                    !strncmpW(name, xmlnscW, sizeof(xmlnscW)/sizeof(WCHAR))) +
> +                   !strcmpW(namespaceURI, w3xmlns))
Could you please simplify that, it's a bit hard to read.
> +     * Note: We would be more in line with the native msxml if we only detected a
> +     * redundancy/conflict for prefixes existing on the element itself (in element->ns
> +     * or in the linked list element->nsDef).  But as long as our *_get_xml() doesn't
> +     * eliminate redundant namespace definitions in children, this behaviour may be
> +     * an advantage in some cases.  As disadvantage is that we incorrectly regard the
> +     * redefinition in element 'b' in '<a xmlns="x"><b xmlns="y"/></a>' as a conflict.
> +     * Libxml2 currently doesn't have a function or option to only search for namespaces
> +     * on the current node; but it would be easy to make a reduced version of xmlSearchNs
> +     * (currently defined inhttp://git.gnome.org/browse/libxml2/tree/tree.c#n5871).
> +     * However, most apps probably set the ns to y on node b creation, so no conflict here.
> +     *
I don't think it's better to potentially break one thing while fixing 
the other. And I guess I like a thought on making xmlSearchNs version 
that will do what we want from it. Just to clarify - is that right that 
libxml2 problem here is a lack of some checks
that lead to duplication and conflicts later? (that are visible in doc 
dumps too)
> +/* Convenient helper function for creating an attribute node in a given namespace.
> + * Note: CHECK_HR() should not be here, but in caller, to give optimal line number info.
> + */
You mean EXPECT_HR here I guess.
> +static HRESULT create_attribute_ns(
> +    IXMLDOMDocument *doc,
> +    const char *attr_name,
> +    const char *nsURI,
> +    IXMLDOMAttribute **attr_ptr)
> +{
> +    HRESULT hr;
> +    VARIANT var;
> +    IXMLDOMNode *node;
> +
> +    V_VT(&var) = VT_I1;
> +    V_I1(&var) = NODE_ATTRIBUTE;
> +
> +    hr = IXMLDOMDocument_createNode(doc, var,_bstr_(attr_name),_bstr_(nsURI), &node);
> +    if (hr == S_OK)
> +    {
> +        IXMLDOMNode_QueryInterface(node, &IID_IXMLDOMAttribute, (void**) attr_ptr);
> +        IXMLDOMNode_Release(node);
> +    }
> +    return hr;
> +}
Please null out pointer in case of failure, or better always before 
createNode().


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20120612/fd8841a9/attachment.html>