[Bug 25168] New: Should XML Serialization be allowed to produce invalid XML?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25168

            Bug ID: 25168
           Summary: Should XML Serialization be allowed to produce invalid
                    XML?
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM Parsing and Serialization
          Assignee: travil@microsoft.com
          Reporter: travil@microsoft.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org

Today in an HTML document,
  createElement("first:last")
Will create an HTMLElement node with prefix = null, and localName =
"first:last".

An XML Serialization according to the spec today (and matching IE/Firefox and
soon Chrome) will generate the following invalid XML:
  <first:last xmlns="http://www.w3.org/1999/xhtml"/>

This is invalid (when round-tripped through DOMParser) because the prefix
"first" is not defined. The XML parser does not know that "first:last" should
be interpreted as a localName only.

There are two ways to avoid serializing invalid XML fragments:
1) Not allow the Serializer to emit localNames (for elements or attributes)
that would not have been possible to create in an XML environment. This would
involve changing the actual element or attribute localNames which would have a
web compatibility problem. For example, "first:last" could be Serialized as
"first_last" instead. (Underscore is preferred to a hyphen since hyphens are
the character delineating a Custom Element for a web component.)
2) Fail to serialize on potential invalid output.

#2 above seems like it would have too great a potential to break web
compatibility--it's a pretty big hammer to apply to the API in the event of a
validation issue. Though it could be useful for programmatic validation of a
DOM. Personally, I don't prefer this option.

#1 seems feasible, though it could change the name of various element and or
attribute, so it's not without any side-effects.

If, in fact, we think that the XMLSerializer should always produce valid XML,
then I would prefer an escaping approach to minimize back-compat on calling
APIs. Otherwise, we should agree to allow the serializer to produce invalid XML
and have that understanding.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 26 March 2014 22:56:32 UTC