Cart
[Home] [By Thread] [By Date] [Recent Entries]
ht@c... 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@j... 856-983-4400 x4911 xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
