8984 2010-02-14 06:58:33 +0000 Invalid XMLLiteral definition of namesspace-well-formed XML fragments is too weak 2011-08-04 05:06:23 +0000 1 1 1 Unclassified HTML WG LC1 HTML+RDFa (editor: Manu Sporny) unspecified PC All RESOLVED FIXED http://dev.w3.org/html5/rdfa/#parsing-model P2 normal --- 1 mjs msporny mike msporny public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 31988 0 mjs 2010-02-14 06:58:33 +0000 Section 4.2 Invalid XMLLiteral values says: 'When generating literals of type XMLLiteral, the processor must ensure that the output XMLLiteral is a namespace well-formed XML fragment. A namespace well-formed XML fragment has the following properties: * The XML fragment, when placed inside of a single root element, must validate as well-formed XML. The normative language that describes a well-formed XML document is specified in Section 2.1 "Well-Formed XML Documents" of the XML specification. * A case-insensitive match for the currently active xmlns attribute as well as all currently active attributes starting with xmlns: must be preserved in the generated XMLLiteral. This preservation must be accomplished by placing all active namespaces in each top-level element in the generated XMLLiteral, taking care to not over-write pre-existing namespace values.' That set of properties appears to be too weak. It does not seem to guarantee that the fragment placed in a root element would be namespace well-formed for instance. It is required to be well-formed, but the second requirement does not seem like it would render it namespace-well-formed. 32124 1 msporny 2010-02-16 04:24:46 +0000 RDFA-SPEC-SECTIONS [invalid-xmlliteral-values] 35388 2 msporny 2010-05-04 03:56:28 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Fixed Change Description: Reworded Invalid XMLLiteral values section, bullet item #2: """ * The XML fragment, when placed inside of a single root element, must retain all active namespace information. The currently active attributes declared using xmlns and xmlns: stored in the RDFa Processor's current evaluation context in the list of URI mappings must be preserved in the generated XMLLiteral. The PREFIX value for xmlns:PREFIX must be transformed to all lower-case characters when preserving the value in the XMLLiteral. All active namespaces declared via xmlns and xmlns: must be placed in each top-level element in the generated XMLLiteral, taking care to not overwrite pre-existing namespace values. """ and added an extra example: """ Similarly, compound document elements that reside in different namespaces must have their namespaces declarations preserved: This is how you markup a user in FBML: →<fb:user uid="12345">The User</fb:user> → The markup above should produce the following triple, which preserves the fb namespace in the corresponding triple: <> <http://example.org/vocab#markup> " →<fb:user uid="12345"> →"^^http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral . """ Rationale: The previous text did specify that all namespace declarations should be preserved on the top-most element, thus ensuring a namespace-well-formed XMLLiteral. Since the reader missed this, the text has been re-worded to make this more clear as well as add the requirement that the xmlns prefix value should be forced to lower-case to ensure compatibility between HTML and XHTML documents. 53069 3 mike 2011-08-04 05:06:23 +0000 mass-move component to LC1