- 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
-----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 UTC