W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2000

Re: CR exit criteria for XLink/Schema imposed by XHTML/SMIL

From: Lloyd Rutledge <Lloyd.Rutledge@cwi.nl>
Date: Wed, 11 Oct 2000 16:50:55 +0200
Message-Id: <200010111450.QAA25777@mast.cwi.nl>
To: Eric van der Vlist <vdv@dyomedea.com>, www-xml-linking-comments@w3.org, www-xml-schema-comments@w3.org
cc: Philipp Hoschka <ph@w3.org>, tbl@w3.org, danc@w3.org, dv@w3.org

On Thu, Sep 21 2000 Eric van der Vlist wrote:

> Philipp Hoschka wrote:
> > 
> > As far as I understand, this would require one XSLT transformation
> > per language that states which attributes should be converted into
> > Xlinks. The schema-based solution only requires one Schema with
> > subtype-definitions that can be reused in many languages.
> You can design a single XSLT transformation working with different
> namespaces (but you have to know them in advance).
> Isn't it the same with XML Schema ?
> Wouldn't you have to define a schema for each namespace --even if you
> can "ref" attributes in a common one ?

I think the one XSLT transformation per namespace may work
theoretically, but there are enough "if's" around that we can't assume
it without a demonstration.  In the absence of this, we'd need one
XSLT transformation per language.  Which would be fine.  One could
write one for XHTML and get most of the Web covered.  One could write
one for the SMIL 2.0 Language Profile as well, and with both languages
covered get the out-of-CR requirement [1] passed.  And with this, the
ability to do it for any language would be demonstrated, and the means
to do so established.

One twist on the use of transforms is that XLink may be treated as
queried properties of the original formats.  This means that there has
to be a means of connecting the transformed-to XLink construct to the
construct or group of constructs in the XML structure of the original
document, be it in XHTML, SMIL 2.0 Language Profile, or whatever.
Without this, you'd recognize that there is a link, but you wouldn't
be able to say what part of the original document that link is.

Like Philipp, I'd also like to read about more details on this idea.

Another downside of transforms over schemas is that more processing
power would be required.  Right?

But this power comes because more is done.  My sophomoric and perhaps
flawed understanding of schemas is that one thing they can do to help
map legacy formats to XLink is attach properties to single constructs.
But what they can't do that transforms are designed for and that may
be needed for legacy XLinking is structural transform, rather than
just property transform/appending.

For example, there's the multiple URI attribute problem.  Some
elements in some formats have multiple attribute that are URI's that
should be recognized as links.  One example of this is the <img>
element in XHTML, which has both the "src" and "longdesc" URI
attributes.  You can't just schema an xl:href on top of those
attributes, since you can't have two href attributes in one xlink
element.  A structural transform, on the other hand, could create from
each of the attributes a separate XLink element, and copy each URI
attribute value to the xl:href attribute of the corresponding XLink
element, and create whatever other attributes are needed for each
XLink element.

And furthermore, to get back to the second paragraph of this post,
some situations may require that a transform, or some kind of process,
go in the other direction to associate each XLink element, and the
semantics they define, back with the original XHTML "href" and
"longdesc" attributes.

How does this sound?  Eric?  Linkers?  Schemers?  Transformers?


[1] http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JulSep/0169.html

Lloyd Rutledge  vox: +31 20 592 41 27       fax: +31 20 592 41 99
CWI             net: Lloyd.Rutledge@cwi.nl  Web: http://www.cwi.nl/~lloyd
Post:   PO Box 94079   |  NL-1090 GB Amsterdam  |  The Netherlands
Street: Kruislaan 413  |  NL-1098 SJ Amsterdam  |  The Netherlands
Received on Wednesday, 11 October 2000 10:51:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:49 UTC