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

Re: Interesting mailing list & a rare broadside

• To: James Clark <jjc@j...>
• Subject: Re: Interesting mailing list & a rare broadside
• From: ht@c... (Henry S. Thompson)
• Date: 08 Jun 2002 19:52:57 +0100
• Cc: Dare Obasanjo <dareo@m...>, xml-dev@l...
• In-reply-to: <982303057.1023532477@[192.168.0.237]>
• References: <8BD7226E07DDFF49AF5EF4030ACE0B7E0696F45D@r...> <982303057.1023532477@[192.168.0.237]>
• User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2(beta13) (Demeter)

I'm not sure your answer follows from Dare's, but I'll let him answer
that.

Let me try to clarify the overall situation.

When the WG were designing this part of the REC, we were confronted by 
two competing requirements:

 1) document authors should be able to specify the schema they
 authored to and expect to be validated with;

 2) application authors should be able to specify the schema they want
 incoming documents to be validated with.

We identified four major sources of schemas in general:

 1) Direct provision by the application;
 2) Specification by the application user ("on the command line", as
    it were);
 3) Via namespace names interpreted as URIs and dereferenced;
 4) Specification in the instance via xsi:(noNamespaceS|s)chemaLocation

We concluded that it would be a mistake to give _any_ of these
cast-iron primacy, and wrote the REC so that any the above could be
preferred to any other, by application design choice and/or runtime
user choice.  We noted that a general-purpose schema validator would
do well to provide for user choice. So far, I'm not aware that much
choice has been given -- all the validators I'm aware of operate
pretty much in the same way, i.e. 'command line' schema documents
override schemaLoc and/or namespace name-derived schemas.

I think general-purpose processors could and should do better (and I
include XSV here), in two ways:

  1) Provide a switch that says, in effect, "don't listen to the
     instance _at all_";
  2) Provide a parameter specifying the desired top-level element
     or type.

I also expect that non-general-purpose processors operating in
mission-critical environments will operate the "don't listen" strategy 
as  a matter of course.

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]

• References:
  • RE: Interesting mailing list & a rare broadside
    • From: "Dare Obasanjo" <dareo@m...>
  • RE: Interesting mailing list & a rare broadside
    • From: James Clark <jjc@j...>

• Prev by Date: Re: xsi:type and broken contracts
• Next by Date: RE: Interesting mailing list & a rare broadside
• Previous by thread: Re: Malicious documents?
• Next by thread: RE: Interesting mailing list & a rare broadside
• Index(es):
  • Date
  • Thread