Re: XML-Schema Requirements for SMIL

> From: Cohen, Aaron M (aaron.m.cohen@intel.com)
> Date: Mon, Apr 03 2000

Sorry for the delay in responding... better late than never, I hope...

> Dear XML Schema folks:
> 
> It has recently been brought to my attention that the current draft of
> XML-Schemas does not provide a mechanism for incrementally building up an
> attribute set on an element, perhaps from several separate modules
> containing attributes,

I believe the attribute group mechanism provides this.
http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#Attribute_Group_Definition

> and also for adding attributes to elements already
> declared.

I presume you're talking about this idiom...

"6.1. Defining additional attributes
[...]
 This works because XML permits the definition or
        extension of the attribute list for an element at any point in a
DTD. "
--
http://www.w3.org/TR/2000/WD-xhtml-building-20000105/developing.html#s_dev_attrs

The Schema spec provides an analog of this idiom; if you
want your element declarations to allow other attributes this way,
just include
	<anyAttribute namespace="##any" processContents="strict"/>

cf
http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#element-anyAttribute


I would actually recommend ##other rather than ##any; requiring
"mixed in attributes" to be declared as coming from another
namespace seens more appropriate than allowing unqalified
attributes or attributes from the same namespace.


> This is essential for modularizing SMIL with XML Schemas, and is something
> that can (and has) already be done with DTD's.

Well... it can be done with a specific set of conventions layered on top
of DTDs, using parameter entities. It cannot be done for arbitrary
combinations of DTDs. And the XHTML modularization mechanisms are
susceptible to name collisions between modules.

cf
http://www.w3.org/TR/2000/WD-xhtml-building-20000105/developing.html#s_dev_attrs

> Maybe my information is
> incorrect, or my understanding is faulty, so I am sending this to make you
> aware of our needs, and asking for guidance in applying XML Schemas in this
> manner. If my information and understanding are correct, then please
> consider this a requirement for the SMIL modules to have associated XML
> Schemas. I am under the impression that XHTML has very similar needs, and my
> impression is based in part on my exchanges with some of the XHTML folks.
> 
> A concrete example will probably make our needs clear.

Yes, thanks.

> So I'll discuss our
> modularization needs in the context of a vastly simplified view of SMIL.
> 
> SMIL timing is a set of reusable modules that can be used to incorporate
> timing relationships into XML languages.

I started drafting a schema for SMIL animation; see:

http://www.w3.org/XML/2000/04schema-hacking/smil-animation.xsd
revision 1.1
date: 2000/05/04 19:35:09

aka
http://www.w3.org/XML/2000/04schema-hacking/smil-animation.xsd.txt

> This language could be "SMIL", or
> "XHTML", or something else. We provide time containers, which are grouping
> elements that contain other elements and provide semantics for the timing
> relationships between the grouped elements. We also provide attributes that
> are added to elements to allow authors to specify explicit timing
> relationships.
> 
> For example, SMIL includes the parallel time container, <par>, which allows
> for several things to be played at once. To play an audio and video clip and
> the same time (assuming that the language, like SMIL 1.0,  includes elements
> to express playing each of these):
> 
> <par>
> <video .../>
> <audio .../>
> </par>
> 
> Note that the elements could be from some other language, such as XHTML.
> Here's how two paragraphs of text might be displayed at the same time:
> <par>
> <p>First Paragraph.</p>
> <p>Second Paragraph.</p>
> </par>
> 
> This becomes much more powerful when the elements that are timed can have
> their own timing-specific attributes. For this discussion, we'll only have
> two. 'begin' tells when to start displaying something, and 'dur' specifies
> the duration, or how long to display it. Building off the XHTML example:
> <par>
> <p begin="0s" dur="1s">First Paragraph.</p>
> <p begin="2s" dur="1s">Second Paragraph.</p>
> </par>
> 
> This displays the first paragraph immediately for 1 second, then there is
> one second where nothing is displayed, and then at time=2s, the second
> paragraph is displayed for 1 second.
> 
> This admittedly very simple example gets to the root of what we need to be
> able to accomplish with XML Schemas. The <p> element is already defined in a
> module by XHTML. For a language designer to be able to incorporate or
> combine timing with elements already defined, we need to be able to extend
> the attribute set of an element defined in a different module.

Or, alternatively, you need the definition of the P element to allow
attributes declared elsewhere (as noted above, this is the default
in XML 1.0)

I mocked up this example...

http://www.w3.org/XML/2000/04schema-hacking/h+s.html

=========
<html
 xmlns="http://www.w3.org/1999/xhtml"
 xmlns:xsi='http://www.w3.org/1999/XMLSchema-instance'
 xmlns:t='http://www.w3.org/2000/TR/smil-animation10'
 xsi:schemaLocation="http://www.w3.org/1999/xhtml html.xsd
         http://www.w3.org/2000/TR/smil-animation10 smil-animation.xsd
                "
  >
<head><title>Example of mixing HTML and SMIL timing</title></head>
<body><h1>Some stuff</h1>

<!-- example from 
http://www.w3.org/TR/NOTE-HTMLplusTIME -->

<p t:begin="1">
         This is a paragraph of text that appears after one second
     </p>
     <p t:begin="2">
         This is a paragraph of text that appears after two seconds
     </p>
     <p t:begin="3">
         This is a paragraph of text that appears after three seconds
     </p>

</body>
</html>
=========

(The schemaLocation gobbledygook is only necessary until schemas
for XHTML and SMIL are available by dereferencing
their namespace identifiers)

then in html.xsd:
(i.e.  http://www.w3.org/XML/2000/04schema-hacking/html.xsd)

 <element name='p'>
  <complexType content='mixed'>
   <anyAttribute namespace="##other" processContents="strict"/>
    [...]
  </complexType>
 </element>

and in smil-animation.xsd :

   <attribute name='begin' type='string'/>
   <attribute name='dur' type='string'/>
   <attribute name='end' type='string'/>
   <attribute name='restart'>
    <simpleType base='string'>
     <enumeration value='always'/>
     <enumeration value='never'/>
     <enumeration value='whenNotActive'/>
    </simpleType>
   </attribute>
   <attribute name='repeatCount' type='string'/>
   <attribute name='repeatDur' type='string'/>
   <attribute name='fill'>
    <simpleType base='string'>
     <enumeration value='remove'/>
     <enumeration value='freeze'/>
    </simpleType>
   </attribute>

You can check the results using
	http://cgi.w3.org/cgi-bin/xmlschema-check
i.e.
http://cgi.w3.org/cgi-bin/xmlschema-check?docAddrs=http%3A%2F%2Fwww.w3.org%2FXML%2F2000%2F04schema-hacking%2Fh%2Bs.html


I have used qualified names for the "mixed in" attributes, per
this principle:

	"The syntax must unambiguously associate an identifier in
	a document with the related schema without requiring inspection
	of that or another schema."

	-- http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210#Ambiguity

The schema spec allows you to violate that principle by using
<anyAttribute namespace="##any"/> on the P element
declaration, and and attributeForm="unqualified" in the smil-animation
schema, but I don't recommend that.

> For this
> particular example, the language designer needs an XML Schema method of
> adding the begin and dur attributes defined in a SMIL XML Schema module to
> the <p> element defined in an XHTML Schema module.

I believe I have demonstrated this above.


> It is not sufficient to
> just be able to declare the members of an attribute set from several places
> when the element is initially defined.
> 
> The same thing goes for the content model of the elements. It may be
> necessary to extend the permissible child element set of a module beyond how
> it was initially defined. SMIL Boston is planning on using "levels" of
> modules. As the functionality goes up in higher levels, we add some elements
> to the set of allowed children. As above, we'll also add new attributes to
> existing elements in order to make them more powerful in the higher level
> modules.
> 
> Furthermore, we will use the above process to define our next version of the
> SMIL Language, and also to define a language/profile that combines XHTML and
> SMIL timing structure (as well as some other aspects of SMIL), and to define
> a baseline "SMIL-Basic". So you can see that the use case that we are asking
> for is a key element in SMIL being a successful and reusable technology. The
> DTD experts in the group are comfortable that we can produce DTD's that
> reflect this structure, and we would also like to have a set XML Schemas
> before SMIL becomes a Recommendation. To this end, we need confirmation that
> it can be done with XML Schemas, and guidance in how to proceed.

Does the explanation above provide enough confirmation and guidance?

> I've been
> told to expect a note on modularization using XML Schemas. Will our use
> cases be covered in that note?

I'm not sure.

> Please feel free to contact me with any questions you may have about
> anything that I have said here.
> 
> Thank you,
> Aaron Cohen, Intel
> Chair of the SYMM Working Group


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 12 May 2000 18:17:54 UTC