[
Lists Home |
Date Index |
Thread Index
]
- From: Michael Rossi <mrossi@crusher.jcals.csc.com>
- To: xml-dev@ic.ac.uk
- Date: Thu, 30 Dec 1999 12:46:28 -0500
ht@cogsci.ed.ac.uk wrote:
>
> 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.
Could you elaborate on this Henry, maybe with a brief example? Either my
brain's on holiday a little early or, not being privvy to the working group
discsussions, maybe I've missed some helpful comments.
> '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.
Again, I'd like an elaboration if you would. Are you saying that even
though an instance claims validity against a given schema, a processing
application may wish to validate or process it against a different schema?
Validation against a different schema may be explained by your response to
the above, but for what other processing would an application hope to use a
non-instance specified schema besides validation? I'm just not seeing the
practicality yet. Thanks.
> 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.
I'd have to agree with Bob Kline's comments on this:
> 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.
We're having similar debates in a working group of the Workflow
Management Coalition right now, flexibility vs. standardization. Personally,
I'd say if you've decided to standardize something than standardize it. If
all you're saying is "feel free to do this part however you like" than you
don't have a standard. Besides, as Bob also alluded to, if vendor's want to
MS a spec they're going to do it anyway. It's then their responsibility to
push the value of the proprietary "extensions".
Michael A. Rossi
mailto:mrossi@jcals.csc.com
856-983-4400 x4911
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)
|