RE: LC-13 extending content models

Michael:

In fact, I have begun work on the SMIL 2.0 XML Schemas, and figured out most
the alternatives myself.

Unfortunately, it's not quite that simple, and in the SMIL 2.0 modular
schema, I think that I am going to have to use two of the mechanisms in
order to make things work. In fact, what I am doing is slightly different
from what you describe.

The reason is that our elements include each other; there is no strict top
down hierarchy. If B contains A, and A is extended, B must contain the
extended A. This also crosses module and functional area boundaries, so
there are way to many combinations to derive them all explicitly.

We also do not want to have to individually namespace qualify elements
within the smil 2.0 language document. One default NS declaration should do
it for everything.

So I've designed the schemas for the smil 2.0 languages around element
"prototypes" and attribute groups. The prototypes are basically the elements
with the basic attributes (which gets extended later by the profile schema).
The prototypes have empty content models. So the language profile schema has
to set up the entire content model of all the elements to make everything
work. This is how the .../SMIL20/Language namespace is defined.

In the smil20 namespace, want to enable reuse of smil20 elements in document
types with content models that we have no knowledge of, so we need to use
the ANY type. So I'm planning on having 2 namespaces with the same elements
and semantics, but a stricter definition and syntax checking of the content
model in the 
.../SMIL20/Language namespace as opposed to the .../SMIL20/ module
namespace.

BTW, I tried using redefine, but with no support for conditionals, this is
not very useful. I guess that I could have used the XML/DTD methods for
<!INCLUDE>, but that seemed rather dirty, so I avoided it. I think that XML
Schemas should either include support for conditional inclusion of code, or
declare that the XML mechanism should be used.

See, redefine only makes sense for us if I can use it to change content
models in a building block namespace, only for the purposes of the new
namespace that I am building from the building blocks. Being able to
redefine a name from a namespace on the fly within that namespace gets me
nothing since in the end the namespace needs to be definitive and static.
What would it mean if my document saw a different smil20 namespace than
yours? Isn't this a complete violation of the namespace specification?

I should point out that in working with schemas I have developed an
appreciation for their power and all the hard work that has gone into them.
I just think that it is important that XML Schemas include more support for
modularization than it does. Yes, I think that the answer below is
sufficient for advance into CR, but I do think that the director should be
aware of the difficulties in using XML Schemas for the modular design of
reusable technology and "langauge families" and I'd like to see more
experience with that as a requirement of XML Schemas coming out of CR. In
particular, it is important that someone write a modular XHTML to show that
it can be done in a useful and acceptable manner.

-Aaron

> -----Original Message-----
> From: C. M. Sperberg-McQueen [mailto:cmsmcq@acm.org]
> Sent: Thursday, October 05, 2000 7:23 PM
> To: Cohen, Aaron M
> Cc: W3C XML Schema Comments list
> Subject: LC-13 extending content models
> 
> 
> Dear Aaron Cohen:
> 
> The W3C XML Schema Working Group has spent the last several months
> working through the comments received from the public on the last-call
> draft of the XML Schema specification.  We thank you for the comments
> you made on our specification during our last-call comment period, and
> want to make sure you know that all comments received during the
> last-call comment period have been recorded in our last-call issues
> list (http://www.w3.org/2000/05/12-xmlschema-lcissues).
> 
> Among other issues, you raised the point registered as issue LC-13,
> which asks for confirmation that it is possible, using XML Schema, to
> extend elements defined in one module of a complex language by adding
> new children, in declarations contained in a second model of the
> language.
> 
> There are several ways in which schema authors can modify the contents
> of elements; which mechanism is appropriate depends on the
> circumstances.
> 
> For illustration, imagine that I wish to extend the content of element
> E (which has complex type T) by allowing it to contain one or more
> occurrences of element F.  At least the following mechanisms might
> be appropriate:
> 
>    - define complex type T2, an extension of type T, and
>      define element type E2, with complex type T2; declare
>      E2 to be in the substitution group of E (this allows
>      you to put E2 elements pretty much wherever E elements
>      are allowed, but does involve a different name in the
>      start- and end-tags
>    - define type T with an ANY wildcard (this allows F, but
>      also G and H and ...)
>    - define T as being derived from type U.  Make type U
>      represent the content model of E as it should be without
>      the optional module; make T be the content model of E
>      as it should be *with* the optional module.  In the
>      optional module, derive T from U appropriately.  If the
>      optional module is not included in the schema, include
>      an alternate module instead, which derives T from U
>      without any changes.
>    - define E and T in the normal way.  In the optional module,
>      include the schema document in which they are defined,
>      and within the inclusion element (named 'redefine', for
>      reasons that are about to become clear) include a new
>      definition of type T, with the appropriate changes.
>      This use of 'redefine' is legal only if the two
>      schema documents (the including and the included)
>      define constructs for the same namespace, and only
>      if the new / variant form of T is derived (in what
>      looks like a circularity) from the old form of T.
> 
> The first three of these mechanisms have been present in the language
> for some time, though their best use in circumstances like the ones
> you have in mind has only gradually become clearer.  The last item in
> the list, however, reflects a change introduced by the XML Schema WG
> in response to comments from you and others, which we believe will
> make it much simpler to define markup languages composed of modules
> which may be combined according to various simple rules.  We hope
> you find it useful.
> 
> I apologize for not being in a position, right now, to expound on
> these mechanisms, especially the last one, at greater length.  For
> further information and discussion, you may find the following papers
> useful.  They are unfortunately each in various stages of disarray,
> and each is now in need of revision to reflect the changes we have
> made in response to last-call comments in XML Schema.  I hope soon to
> resume work on a note on using XML Schema to construct modular markup
> languages, which may also be of use to you and your WG.
> 
>    http://www.w3.org/2000/04/20-xmlschema-dtdissues
>    http://www.w3.org/2000/04/26-csrules
> 
> It would be helpful to us to know whether you are satisfied with the
> decision taken by the WG on this issue, or wish your dissent from the
> WG's decision to be recorded for consideration by the Director of
> the W3C.
> 
> with best regards,
> 
> -C. M. Sperberg-McQueen
>   World Wide Web Consortium
>   Co-chair, W3C XML Schema WG
> 
> 
>

Received on Thursday, 5 October 2000 17:59:01 UTC