xml-dev - Re: Schema for XSLT (concerns mixed content, content attribute)

[ht@cogsci.ed.ac.uk (Henry S. Thompson)]

"Arnold, Curt" <Curt.Arnold@hyprotech.com> writes:

> My interpretation of derivedBy='extension' is that any content
> defined in the derived type appears after the content in the base
> type.  (I looked but couldn't see any definition of special behavior
> if the base complexType was mixed) So that your definitions would
> allow template content then <xsl:sort> or <xsl:param> elements.

Correct.

> However, since the only mechanism to get mixed content is through a
> content='mixed' attribute on a <complexType> element and that the
> only mechanism to build a content model off of a complexType is
> restriction or extension, there does not seem to be a mechanism for
> doing what you would really want.

I'd do it by defining template with a disjunction, and then
restricting one or the other branch of the disjunction out of
existence for the derived types.

> That lead me to look at the content attribute of complexType which
> appears to only provide information in a very few places and has
> substantial potential to be inconsistent with other parts of the
> type declaration.  Elimination of the content attribute would seem
> to eliminate some complexity.
> 
> The content attribute can have values of elementOnly, textOnly,
> mixed and empty.

Your discussion below seems to assume that 'content' is an attribute
on <element>, when in fact it belongs on <attribute>.

> textOnly can usually be implied by the type attribute referencing a
> simple type or a <simpleType> child element.  The equivalent of
> content='textOnly' would be nothing more would be type='string'.
> There doesn't seem to be a case where content='textOnly' adds value.

There's one corner case:

  <xs:element name='foo'>
    <xs:complexType content='textOnly'/>
  </xs:element>

is weaker than base='string' (or type='string' on the xs:element), in
that it can be restricted by a complex type with _any_ simple type as
its base

> elementOnly can be implied by a type attribute referencing a
> complexType or a <complexType> child element.

How can we distinguish mixed from element only in that case?

> If we had the <mixed> group tag, then mixed content is just a
> particular flavor of complex type.

If we had such a group tag, it would re-introduce the pernicious mixed
content bug from SGML.

> That leaves empty.  Either an <empty/> element like in previous
> drafts or better yet defining an "empty" complex type in the schema
> for schema that is the default base type if no type is defined and
> would be the default base type for complexType elements.

I think we're open to re-designs in this area, but this one isn't
quite there yet.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************