W3C home > Mailing lists > Public > www-xml-linking-comments@w3.org > January to March 2006

Re: XLink 1.1: Schema issues

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Tue, 24 Jan 2006 16:48:12 +0000
To: Webb Roberts <webb.roberts@gtri.gatech.edu>
Cc: www-xml-linking-comments@w3.org
Message-ID: <f5b3bjda7xv.fsf@erasmus.inf.ed.ac.uk>

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

Webb Roberts writes:

> Regarding http://www.w3.org/TR/2005/WD-xlink11-20050707/

Thanks for your comments.

> I feel that the schema provided in appendix C has issues, and should
> be revised.  The specification clearly specifies a number of
> attributes that should appear within the XLink namespace.  I beleive
> that those should be the ONLY artifacts defined within the XLink
> namespace by a sample schema.  Any other required or supporting
> types or elements should be placed in an auxiliary namespace, as
> defined by a separate schema.

I'm afraid I don't understand why this would change the situation in
any significant way.  The normative prose of the spec. defines the
syntax and semantics of the named attributes in the XLink namespace.
The non-normative DTD, W3C XML Schema and RelaxNG schema specify the
permitted syntax of those attributes.  All three of them define other
names, incidental to their primary purpose.  Anyone using or referring
to these three schemas will depend on _all_ the definitions therein,
whatever namespace (or none) they are in.

> Any other interpretation will result in schema implementations
> depending on non-specified artifacts, creating an unnecessary
> binding between normative specification and specific schemas.

Any e.g. W3C XML Schema document which imports a copy of Appendix C
will depend on its contents, whether they are in the XLink namespace
or not. . .

> For example, if I create a set of schemas, and I depend on type
> "xlink:roleType", then I am depending on non-normative artifacts.

But if you depended only on xlink:role _as a top-level attribute
declaration_ I might run into exactly the same problem if, for
example, a subsequent release of the non-normative schema moved all
the attribute declarations into appropriately-structured attribute
group definitions.

> Substitution of other, specification-compliant schema implementations
> will cause my schemas to break.  It digs a big hole.  A better schema
> implmentation would specify ONLY normative components in the
> spec-defined namespace, and relegate all other content to an
> explicitly non-normative namespace.

The whole appendix is non-normative. . .

> I would recommend using anonymous types to define all attributes
> defined by the specification.  I do not believe named supporting
> types are necessary.  I would be willing to write a schema draft, if
> necessary.

With respect, I think this would substantially _reduce_ the value of
the appendix.  By using named types, the possibility of defining your
own e.g. title-equivalent element which is in the substitution group
of xlink:title but with a type definition which is a restriction of
xlink:titleEltType is supported, which would not be possible if the
utility types were not named.

> Note that this solution also obviates the requirement to import the
> xml namespace.

I don't understand -- some way of allowing xml:lang where the
spec. allows it is still required.

I appreciate your desire to see this appendix be of maximal value, but
I think having named type definitions and abstract named element
declarations is the best way to achieve this.

Please let us know if you are satisfied with this answer,

thanks,

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)

iD8DBQFD1lpMkjnJixAXWBoRAt3PAJ9KnPPCsv6VSQI2v4ezLF8SBmhLKwCeOke7
fJNFFioee0fvQc4na62inD0=
=bytJ
-----END PGP SIGNATURE-----
Received on Tuesday, 24 January 2006 16:48:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:46 GMT