CODEWITHSUNDEEP
xmlxsdxml-namespaces
Tankman六四
Tankman六四

Reputation: 1768

`elementFormDefault` sometimes doesn't work

Introduction

elementFormDefault="unqualified" on the <schema> element sets a default form="unqualified" for the elements defined in that schema.

The following valid XML segment used a schema defined with elementFormDefault="unqualified"

<asnx:module xmlns:asnx="urn:ietf:params:xml:ns:asnx">
   <sequence/>
</asnx:module>

The <sequence> element doesn't have namespace qualification because the schema was defined like this:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns="urn:ietf:params:xml:ns:asnx"
       targetNamespace="urn:ietf:params:xml:ns:asnx"
       elementFormDefault="unqualified">
....

Abnormality

In a specific system I'm working with, modularised XHTML was used in the descriptive part of XML data, like this:

<product:description>
 <xhtml:div>
  <xhtml:p>This product is discontinued</xhtml:p>
 </xhtml:div>
</product:description>

Due to the way the software application I'm working on was assembled, it won't work unless it's written in this form:

<product:description>
  <xhtml:div>
    <p>This product is discontinued</p>
  </xhtml:div>
</product:description>

That is, the software application fails to process the embedded XHTML if elements are qualified.

I thought a quick fix is to modify the schema for XHTML namespace to make validator accept embeded XHTML elements unqualified. That is, to change XHTML's schema xhtml1-strict.xsd (only locally - the system won't reach out to w3.org website to get the official xsd file), by changing the root <schema> element from elementFormDefault="qualified" to elementFormDefault="unqualified".

To my surprise, the change has no effects. The validator (xmllint) still demand <p> to be qualified:

element p: Schemas validity error : Element 'p': This element is not expected. Expected is one of ( {http://www.w3.org/1999/xhtml}p, {http://www.w3.org/1999/xhtml}div, {http://www.w3.org/1999/xhtml}fieldset, {http://www.w3.org/1999/xhtml}table, {http://www.w3.org/1999/xhtml}noscript, {http://www.w3.org/1999/xhtml}h1, {http://www.w3.org/1999/xhtml}h2, {http://www.w3.org/1999/xhtml}h3, {http://www.w3.org/1999/xhtml}h4, {http://www.w3.org/1999/xhtml}h5 )

Ruled-out probable causes

I thought maybe I was editing a xhtml1-strict.xsd not used by the system, so I edited parts of it like changing "div" to "vid" and observe the resulting error. That way I verified that the file I edit is the file used by the validator.

I also tried to change the other schemas imported in the product namespace and verified that changing elementFormDefault in any imported schema does have the anticipated effect on the way validator requires the children element to be qualified/unqualified, and that effect is clearly missing when I do the same to xhtml1-strict.xsd, so there is something magical about xhtml schema.

Upvotes: 0

Views: 338

Answers (2)

Michael Kay
Michael Kay

Reputation: 163262

(This is a comment on your answer, but too long to submit as a comment).

Answering the point that you "spent a lot of time trying to search in the defining documents" - yes, it's hard to navigate the W3C XSD specification, but it's actually pretty clear when you know where to look and know the correct terminology.

Using the 1.0 spec, section 3.3.2 has a sub section "If the <element> element information item has <schema> as its parent, the corresponding schema component is as follows:" that says the target namespace is that of the schema.

It then has another section "otherwise if the <element> element information item has <complexType> or <group> as an ancestor and the ref [attribute] is absent" which says "If form is present and its ·actual value· is qualified, or if form is absent and the ·actual value· of elementFormDefault on the <schema> ancestor is qualified, then the [target namespace is the] ·actual value· of the targetNamespace [attribute] of the parent <schema> element information item, or ·absent· if there is none, otherwise ·absent·.

Upvotes: 0

Tankman六四
Tankman六四

Reputation: 1768

I don't have a solution but I have an "answer" now.

First, elementFormDefault doesn't work on elements directly defined in the schema, but only in sub-elements defined in an element. In XHTML, elements like <p> are not defined as sub-elements of <body>, but rather instead, a standalone element on its own.

Second, even for sub-elements, only those not referring to the standalone elements can have form attribute, which are affected by elementFormDefault.

I reached that conclusion with a lot of experiments. I spent a lot of time trying to search in the defining documents in vain.

The author of xhtml chose to define elements standalone and refer to them, hence XHTML in its entirty is not affected by elementFormDefault.

Upvotes: 1

Related Questions