[
Lists Home |
Date Index |
Thread Index
]
- From: Bob Kline <bkline@rksystems.com>
- To: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
- Date: Thu, 30 Dec 1999 09:20:18 -0500 (EST)
On 30 Dec 1999, Henry S. Thompson wrote:
> [Thread wrt instance->schema connections, lack of rigidity thereof]
>
> With apologies for the 'turgid prose' of the draft in this area, let
> me try to explain why flexibility IN THE REC in this area is a Good
> Thing:
>
> Schemas are a powerful and useful mechanism, with a wide range of
> possible deployment scenarios. Different schemas may usefully be
> employed with respect to the same instance document for different
> purposes, all legitimate. 'xsi:schemaLocation' is a means by which
> a document author can signal A location for A schema with respect to
> which s/he warrents the instance at hand is schema-valid. It will
> often be appropriate for schema-aware processors to exploit this
> information. But it may not always be possible (the processor may
> be offline) or appropriate (the processor may have other
> schema-based processing in view) to do so. We have tried in the
> current draft to indicate that 'xsi:schemaLocation' is the
> preferred, inter-operable means by which instances signal schemas to
> processors, WITHOUT making this connection make-or-break mandatory.
>
> A moment's thought about experience with XML's instance->DTD linkage
> will perhaps suggest some benefits of this approach: as it stands,
> if I wish to validate an XML instance which references no external
> DTD, I have to edit it to incorporate a suitable DOCTYPE
> declaration. Even if the document has a DOCTYPE, if the URL it
> references is unavailable or out-of-date, I again must have recourse
> to a text editor to fix this. We've tried to do better for XML
> Schema. Another experience we've tried to learn from is the
> instance->stylesheet one, with similar lessons we believe.
I guess I don't see a conflict between the desire for flexibility and
the need to specify standard behavior for the primary purpose of the
schema mechanism. I don't think anyone is arguing that other uses of
schemas should be prohibited, and surely no one expects a processor to
validate against a schema if the schema isn't made available to it. I
see no problem with a processor providing options which mean "process
this XML document without validating it against its schema." I see no
problem with a processor providing options which means "use some
non-standard mechanism for processing this document against (or
identifying or locating) its schema." How would any of this preclude
saying, in effect, here is the standard mechanism for identifying the
schema against which a given XML instance is to be validated; when the
mechanism is used as described herein a processor which conforms to this
specification will behave as follows, in the absence of explicit
instructions to the contrary? I don't expect the spec to require that
the processor burst into flames if it can't locate the schema, but I
would like the spec to describe predictable behavior of a conformant
processor if I use the standard mechanism for identifying a schema which
is available.
--
Bob Kline
mailto:bkline@rksystems.com
http://www.rksystems.com
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|