[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] tricky validation problem w multiple schemas
"Naomi Dushay" <Naomi@cs.cornell.edu> writes:
> instance doc 2:
> <DO xsi:noNamespaceSchemaLocation="DO.xsd">
> <DS DSID="a">
> <DS DSID="b">
> <FRIP FID="f1">
> <desc>this is an instance of a Q frip</desc>
> <FSch:root xmlns:FSch="http://fsch.ns"
> xsi:schemaLocation="http://fsch.ns FRIPQ.xsd">
> <FSch:roleq1 RDSID="a" />
> <FSch:roleq2 RDSID="b" />
> I can validate instance doc 2 against DO.xsd.
> If I snip out the FSch qualified XML, I can validate that against
> But I'm still not happy:
> 1. Neither XML Spy nor Topologi has a way for me to validate the
> appropriate piece of XML instance doc 2 against FRIPQ "in situ." That
> is, the only way I've found to validate against FRIPQ.xsd is to snip out
> that piece of XML and make it a separate instance doc.
XSV will handle this one just fine -- whenever it hits a previously
unseen namespace, it looks for an xsi:schemaLocation attribute and
does the right thing.
> 2. RDSID within a frip role tag is supposed to be an IDREF to a
> DSID attribute in a DS tag.
> But in the above model, my frip schema doesn't know about DO.xsd
> ... so how can they refer to XML in the DO?
RDSID is an IDREF, the IDs will be IDs, it should all work.
> Is there a way for me to do all of these:
> a. have DO schema that will allow extensible frips to be
> plugged in at the appropriate spot.
> b. DO schema doesn't know anything about specific frip schemas,
> only DO instance docs know about specific frip schemas.
> c. specific frip validating doc can be used to validate
> specific frip instance in DO instance doc.
> d. specific frip validating doc can validate:
> i. correct role elements for specific frip
> ii. attribute RDSID for each role is an IDREF
> refering to a DSID in a DS element in DO instance doc.
> iii. match RDSID for each role to DSID pertaining to
> correct MIME type specified (e.g. for Frip Q, roleq1 must match DS with
> MIME "text/plain")
(a), (b), (c), (d) i and ii are fine with W3C XML Schema. (d)iii is
application logic/business rule, and W3C XML Schema can't help.
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: firstname.lastname@example.org