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

["Box, Don" <dbox@develop.com>]

This is actually a bit confusing, but I think I finally have my head around
it (I certainly didn't two days ago).

If one looks at Section 4.3.3 of Part 1, the description of the {content
type} deserialization rules discusses the EXPLICIT PARTICLE that is
introduced as a parent of most complex type content models. To paraphrase,
unless the complexType's content model is a lone all, group, sequence, or
choice, the model is interpreted as if a compositor has been introduced. In
the case of content='mixed', it is a choice compositor marked
minOccurs='0'/maxOccurs='unbounded'.

That stated, I believe (but may be wrong) that the following:

<complexType name='bob' content='mixed' >
	<element name='a'/>
	<element name='b'/>
	<element name='c'/>
</complexType>

is equivalent to:

<complexType name='bob' content='mixed' >
 <choice minOccurs='0' maxOccurs='unbounded' >
	<element name='a'/>
	<element name='b'/>
	<element name='c'/>
 </choice>
</complexType>

This is pretty much the DTD story. If one really wants the "revolutionary
structured mixed content model" that acts like elementOnly but allows
non-whitespace character data, one would have needed to write this:

<complexType name='bob' content='mixed' >
 <sequence minOccurs='m' maxOccurs='n' >
	<element name='a'/>
	<element name='b'/>
	<element name='c'/>
 </sequence>
</complexType>

where m and n are the values that match your expectations ;-)

Taking this into account, I believe my original schema for XSLT was using
content='mixed' correctly, although I now see at least one opportunity to
tighten up some constraints.

DB
http://www.develop.com/dbox


> -----Original Message-----
> From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
> Sent: Wednesday, April 19, 2000 10:12 PM
> To: Box, Don
> Cc: Curt.Arnold@hyprotech.com; dbox@develop.com;
> www-xml-schema-comments@w3.org; xml-dev@xml.org;
> xml-dev-temp@egroups.com
> Subject: RE: Schema for XSLT (concerns mixed content, content 
> attribute)
> 
> 
> Schemas treats "mixed" differently than DTD's.  In schemas, both 
> element-only and mixed take a full content model.  The only 
> difference 
> with mixed is that the instance can have character information item 
> children before after and in between the elements validated 
> by the model. 
> So, you have the full power of content models with mixed.  
> Also, mixed 
> does not imply any defaults for min/maxOccurs.  This is NOT 
> the DTD model, 
> but it can express every constraint allowed by DTD mixed (and more).
> 
> --------------------------------------------------------------
> ----------
> Noah Mendelsohn                                    Voice: 
> 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> --------------------------------------------------------------
> ----------
> 
> 
> 
> 
> 
> 
> 
> "Box, Don" <dbox@develop.com>
> Sent by: www-xml-schema-comments-request@w3.org
> 04/18/00 06:21 PM
> 
>  
>         To:     "'Arnold, Curt'" <Curt.Arnold@hyprotech.com>, 
> "'xml-dev@xml.org'" 
> <xml-dev@xml.org>
>         cc:     "Box, Don" <dbox@develop.com>, 
> "'www-xml-schema-comments@w3.org'" 
> <www-xml-schema-comments@w3.org>, "'xml-dev-temp@egroups.com'" 
> <xml-dev-temp@egroups.com>, (bcc: Noah Mendelsohn/CAM/Lotus)
>         Subject:        RE: Schema for XSLT (concerns mixed 
> content, content attribute)
> 
> > -----Original Message-----
> > From: Arnold, Curt [mailto:Curt.Arnold@hyprotech.com]
> > Sent: Tuesday, April 18, 2000 2:01 PM
> > To: 'xml-dev@xml.org'
> > Cc: 'dbox@develop.com'; 'www-xml-schema-comments@w3.org';
> > 'xml-dev-temp@egroups.com'
> > Subject: RE: Schema for XSLT (concerns mixed content, content 
> > attribute)
> > 
> > 
> > First, a few comments on Don's schema for XSLT then a 
> > discussion about some problems representing XSLT's content 
> > model with schema.
> > 
> > The derivedBy attribute was not specified on the definition 
> > of the copy and message complex types as appears to be 
> > required by Schema representation constraint 1.1
> 
> Thanks. I thought I caught all of those. It's now fixed.
> 
> > The param element reference in the named-template type 
> > definition should have a minOccur="0" and a 
> > maxOccur="unbounded".  As written, a template has to have one 
> > and only one param.
> 
> My reading of rule 4.3 under the {content type} definition 
> (found under
> section 4.3.3) implies that there is an implicit <choice minOccurs='0'
> maxOccurs='unbounded' > particle over the particle children of a
> content=mixed complex type.  I'll defer to Henry on this. 
> 
> > You frequently use type-scoped element definitions.  I try to 
> > avoid these unless a specific tag-name has a distinct content 
> > models in different contexts since it will be difficult if 
> > not impossible to
> > generate an equivalent DTD.
> 
> Local element and attribute declarations are one of the more powerful
> features of the schema language. I make no apologies for using them. 
> Believe
> me, the WG struggled long and hard to get them to where they 
> are now. The
> least we can do as a community is use them ;-)
> 
> > Second, Schema doesn't seem to have the ability to adequately 
> > represent the content model of <xsl:template> or 
> > <xsl:for-each>.  <xsl:template> content should be zero or 
> > more <xsl:param> elements
> > followed by template content. 
> 
> Yeah, I thought about alternative ways to model that. One way 
> would have
> been to use a named model group (that was my first pass btw). 
> The problem 
> is
> that for mixed content, you can't use sequence constraints. This is a
> problem with older technologies as well.
> 
> > <xsl:for-each> content should 
> > be zero or more <xsl:sort> elements followed by template content.
> 
> Same problem.
> 
> > [snip]
> 
> I don't know that anyone has the will to add MORE complexity 
> to the schema
> language to handle mixed content. 
> 
> DB
> http://www.develop.com/dbox
> 
> 
> 
> 

***************************************************************************
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/
***************************************************************************