Re: Implementations/Non-Implementations of xs:redefine?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eliot Kimber writes:

> I think DITA shines a spotlight on [the dark corners of xs:redefine
> interop]. In particular, any two topic specializations used in the
> same environment (which will be all realistic uses of DITA, which,
> out-of-the-box, defines three specializations of the base topic
> type) will re-use the same base schema modules and apply *different*
> redefines.
>
> I think that's exactly the main issue Mike is describing: schemas B
> and C (e.g., topic-type-specific "shell" schemas) both redefine groups
> defined in schema A (the base "topic" topic type schema module).

I'm not sure I understand.  Do you mean that user 1 and/or document 1
need schema B, which redefines schema A, while user 2 and/or document
2 need schema C, which redefines schema A?  Or do you mean that some
users/documents need schemas B _and_ C, both of which redefine schema
A?

The former is fine, it's only the latter which is tricky and, in fact,
I would say, an error (because B and C will produce distinct
definitions of some top-level items. . .).

> In a CMS system that's trying to manage these topics, I can imagine a
> serious problem if it expects to be able keep a single, invariant
> version of the "topic" module in memory or reflected in its internal
> schema or whatever.

Yes, well, doing the wrong thing with multiple versions is a sign of a
bad CMS, regardless of how the multiple versions arise. . .

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFHhM+UkjnJixAXWBoRAkNqAJ9FngZC/8Wt0J1YITRvOKQSkdZniACfUD65
n/SXw0kvud95chhZrjGexxo=
=liMQ
-----END PGP SIGNATURE-----

Received on Wednesday, 9 January 2008 13:43:57 UTC