local schema for listitem
Tim Bergsma
tbergsma at kbs.msu.edu
Fri Dec 20 07:32:28 PST 2002
Chad,
This gives the same schema error: "-1: cos-element-consistent: Error
for type 'ListType'. Multiple elements with name 'li,null', with
different types, appear in the model group. "
Even when I abstract one of the choices to a second group, the validator
gags on this. It really doesn't like having two content models with the
same name.
So here's where the problem stands:
1. We know there has to be an element <li>.
2. We know <li> can only have a single content model.
3. We want the content to be a choice of two content models. What's
worse, in the production version one of the models is element only and
one is mixed, a property that you only get to specify for an element,
not for some choice within an element.
I'm starting to think it might not be possible. Let me know if you think
different.
Thanks,
Tim.
Chad Berkley wrote:
>
> How about this then. I think the schema is valid, but I didn't try to
> validate it. It allows for a choice strictly between
> <li><p>...</p></li> and <li>...</li>.
>
> <xs:complexType name="liWithPOrNoP">
> <xs:choice>
> <xs:sequence>
> <xs:element name="li">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="p" type="xs:string"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> <xs:element name="li" type="xs:string"/>
> </xs:choice>
> </xs:complexType>
>
> chad
>
> On Wed, 2002-12-18 at 06:44, Tim Bergsma wrote:
> > Chad,
> >
> > What I originally wanted was a choice between and eml-like paragraphType
> > (defined elsewhere) and an xs:string. Getting this would be a great
> > leap forward. But I got greedy and tried to allow inline markup (e.g.,
> > <em>, <sub>) in my string. xs: any doesn't work for precisely the
> > reason you stated. I don't want unknown markup to validate, because my
> > eml stylesheet has to know exactly what's coming.
> >
> > How about start simple. I want both of these to validate:
> >
> > <li>Here's my simple list item. No markup allowed.</li>
> > <li><p>Here's an eml-ready list item. paragraphType defines
> > content.</p></li>
> >
> > Thanks for any thoughts. Don't spend too long on it.
> >
> > Tim.
> >
> >
> > Chad Berkley wrote:
> > >
> > > Hi Tim,
> > >
> > > I'm not sure I completely understand your problem, but here's a shot...I
> > > think what you want to do is allow a choice between a paragraph and
> > > something else right? If so, would this work for you?
> > >
> > > <xs:complexType name="pOrAny">
> > > <xs:choice>
> > > <xs:element name="p" type="xs:string"/>
> > > <xs:any processContents="lax"/>
> > > </xs:choice>
> > > </xs:complexType>
> > >
> > > the problem with using an xs:any is that then any additional tagging is
> > > valid as well. I'm not sure if that's what you want.
> > >
> > > if I'm totally off the mark here, clue me in and maybe i can figure
> > > something else out.
> > >
> > > chad
> > >
> > > On Tue, 2002-12-17 at 10:17, Tim Bergsma wrote:
> > > > Hi. Got a nasty schema problem that I can't seem to solve.
> > > >
> > > > EML requires that a listitem contain text only in paragraphs. That's
> > > > fine for EML, but gets really hard on the eyes when authoring.
> > > >
> > > > I have a local schema kbsml_text.xsd that subsets and arranges html so
> > > > that it converts easily to eml. I figured I'd let local listitem
> > > > authors omit the paragraph tags if they only wanted to write a simple
> > > > string of text. Then, my eml style sheet would check for the presence
> > > > of the paragraph tag, and supply it if missing. Essentially I want
> > > > "paragraph without the tags" as an alternative content model for
> > > > listitem.
> > > >
> > > > Unfortunately, paragraph itself is mixed model, whereas listitem content
> > > > is otherwise strict. But I only get to specify "mixed" on the
> > > > complexType as a whole, which allows (validates) stray text even when
> > > > the strict model is followed:
> > > >
> > > > <xs:complexType name="ListType">
> > > > <!--12-17-2002 Tim Bergsma. Adding a simple string as
> > > > an alternative to highly structured 'li' content.-->
> > > > <xs:sequence>
> > > > <xs:element name="li" minOccurs="1" maxOccurs="unbounded">
> > > > <xs:complexType mixed="true">
> > > > <xs:choice minOccurs="1" maxOccurs="1">
> > > > <xs:choice minOccurs="1" maxOccurs="unbounded">
> > > > <xs:element name="p" type="ParagraphType"/>
> > > > <xs:element name="ul" type="ListType"/>
> > > > <xs:element name="ol" type="ListType"/>
> > > > </xs:choice>
> > > > <xs:choice minOccurs="0" maxOccurs="unbounded">
> > > > <xs:element name="em" type="xs:string"/>
> > > > <xs:element name="sub" type="SubSuperScriptType"/>
> > > > <xs:element name="sup" type="SubSuperScriptType"/>
> > > > <xs:element name="img" type="ImageType"/>
> > > > <xs:element name="a" type="AnchorType"/>
> > > > </xs:choice>
> > > > </xs:choice>
> > > > </xs:complexType>
> > > > </xs:element>
> > > > </xs:sequence>
> > > > </xs:complexType>
> > > >
> > > > Choice of independent complexTypes doesn't work, since the content of
> > > > choice must be element, choice, group, sequence, etc. Using an element
> > > > doesn't work, because name is required, and therefore, tags (e.g.
> > > > paragraph wrapper). I tried creating two listItemTypes, and invoking
> > > > them higher up with a choice of two types having the same name; but the
> > > > names in a list of choices must be unique.
> > > >
> > > > Any ideas?
> > > >
> > > > Thanks,
> > > >
> > > > Tim
> > > >
> > > > P.S. I haven't shown the whole schema, but a valid instance follows.
> > > >
> > > > <kbsml_text>
> > > > <p>
> > > > <ol>
> > > > <li>This is a bad place for text. I wish it would not validate.
> > > > <p>this is text in a paragraph.
> > > > </p>
> > > > </li>
> > > > <li>
> > > > <p>This is more text <em>in</em> a paragraph.
> > > > </p>
> > > > </li>
> > > > <li>this is some text <em>not</em> in a paragraph.</li>
> > > > </ol>
> > > > </p>
> > > > </kbsml_text>
> > > > --
> > > > Tim Bergsma
> > > > LTER Information Manager
> > > > W.K. Kellogg Biological Station
> > > > Michigan State University
> > > > Hickory Corners, MI 49060
> > > > 629/671-2337
> > > > tbergsma at kbs.msu.edu
> > > > http://lter.kbs.msu.edu
> > > > _______________________________________________
> > > > eml-dev mailing list
> > > > eml-dev at ecoinformatics.org
> > > > http://www.ecoinformatics.org/mailman/listinfo/eml-dev
> > > --
> > > -----------------------
> > > Chad Berkley
> > > National Center for
> > > Ecological Analysis
> > > and Synthesis (NCEAS)
> > > berkley at nceas.ucsb.edu
> > > -----------------------
> >
> > --
> > Tim Bergsma
> > LTER Information Manager
> > W.K. Kellogg Biological Station
> > Michigan State University
> > Hickory Corners, MI 49060
> > 629/671-2337
> > tbergsma at kbs.msu.edu
> > http://lter.kbs.msu.edu
> --
> -----------------------
> Chad Berkley
> National Center for
> Ecological Analysis
> and Synthesis (NCEAS)
> berkley at nceas.ucsb.edu
> -----------------------
--
Tim Bergsma
LTER Information Manager
W.K. Kellogg Biological Station
Michigan State University
Hickory Corners, MI 49060
629/671-2337
tbergsma at kbs.msu.edu
http://lter.kbs.msu.edu
More information about the Eml-dev
mailing list