Martin hi
> Not sure about this. Can we presume that all DSDL tools will
> be XInclude aware? I think not. Do we want to require all
> DTLL-aware tools to also be XInclude-aware?
I'd got the impression that we were assuming Xinclude support would be
pervasive. But maybe this is incorrect (the diagrams in Part 1 may be
responsible).
> Is it invalid to
> have both a DTLL specific inclusion mechanism and a separate
> XInclude one?
No.
> (For example, does the <include> element in
> RELAX NG actually preclude the use of an XInclusion
> declaration being used to include additional information
> within the schema?)
Well, RELAX NG has an include element with a href attribute; Schematron
has an include element with a src attribute. AFAICS Schematron doesn't
stipulate treatment of text encoding, relative URL resolution, or
whether the included fragment must be well formed (as opposed to
balanced). Neither mentions what happens in the case of a namespace
prefix clash.
My take on this in that the Xinclude experience teaches us that properly
specifying this kind of thing is harder than it looks - so why re-invent
the wheel?
Could we say that Part 5 has its own include element, but that it must
be interpretted identically to (say) Xinclude's include element, or
RELAX NG's ?
I don't think it would be right to have yet another kind of include
(with a different spec.) in DSDL.
- Alex.
-- DSDL members discussion list To unsubscribe, please send a message with the command "unsubscribe" to dsdl-discuss-request@dsdl.org (mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)Received on Tue Feb 28 00:16:54 2006
This archive was generated by hypermail 2.1.8 : Wed Apr 12 2006 - 14:48:02 UTC