[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Best Practice - beyond schema

• To: Paul Spencer <paul@a...>
• Subject: Re: Best Practice - beyond schema
• From: ht@c... (Henry S. Thompson)
• Date: 21 Jun 2002 16:00:04 +0100
• Cc: "Xml-Dev" <xml-dev@l...>
• In-reply-to: <d2f0huo6k63f967nuukl2jo41584l2ud3d@4...>
• References: <NBBBIBMKFOFCNEBAKDPLAEOCFLAA.paul@a...><f5bfzzluh1p.fsf@c...><d2f0huo6k63f967nuukl2jo41584l2ud3d@4...>
• User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2(beta13) (Demeter)

Paul Spencer <paul@a...> writes:

<snip/>

> I don't think use of <xs:any> etc is enough to allow us to use two
> XML Schema schemas in series.

Not obvious why this won't work -- I hadn't thought of it but it's a
good idea, if your locale-specific variants are not of the
optional->required/prohibited variety.  The W3C XML Schema REC is
designed, via <xs:any namespace="##other" processContents="strict"/>,
to enable what amounts to serial processing by two single-namespace
schema documents.

> The use of <xs:redefine> is certainly appealing - we have a single
> schema against which to validate for each locale rather than having to
> process two (in separate languages) in series. Change management is
> reasonably simple, but possibly error prone. Change in the global
> schema requires recoding of the locales, which is a shame. This is
> caused by the need to replicate information that is not being changed
> when applying restrictions. It could be that this can be minimized by
> careful design. I suspect that my schemas are already coded to make
> this reasonably easy, but some further definitions of named complex
> types could help.

Or named model groups.

>  It would be interesting to experiment. Why is this
> error-prone? Well, I know that XML Spy (4.3) will not report an error
> if a type changes (say by adding an element) but the derived
> (restricted) type is not changed to match. I have not tried other
> tools. Certainly, an automated check for this would be required. And
> no - I have not yet checked the spec to see what action should be
> taken, or even really thought about it yet.

So your tool is broken -- get it fixed, don't use a bad design to work 
around it!

<snip/>

> My intention is to experiment a bit with the <xs:redefine> to see just
> how big the derived schema documents become. Then I feel I will have a
> good view of the better mechanism for this and other circumstances.

Keep us posted -- if there are reasons why it doesn't let you do what
you need, that's important feedback to the WG wrt subsequent versions.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2002, 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@c...
		     URL: http://www.ltg.ed.ac.uk/~ht/
 [mail really from me _always_ has this .sig -- mail without it is forged spam]

• Follow-Ups:
  • Re: Best Practice - beyond schema
    • From: "Rick Jelliffe" <ricko@a...>

• References:
  • Best Practice - beyond schema
    • From: "Paul Spencer" <paul@a...>
  • Re: Best Practice - beyond schema
    • From: ht@c... (Henry S. Thompson)
  • Re: Best Practice - beyond schema
    • From: Paul Spencer <paul@a...>

• Prev by Date: Re: Best Practice - beyond schema
• Next by Date: Re: What Is Type Augmentation and Should We Be Concerned? (WAS RE: [ xml-dev] Best Practice - beyond schema)
• Previous by thread: Re: Best Practice - beyond schema
• Next by thread: Re: Best Practice - beyond schema
• Index(es):
  • Date
  • Thread