SVG WG Last Call review of XLink 1.1

Hello www-xml-linking-comments,

Hello XML Core Working Group

The SVG WG has reviewed
http://www.w3.org/TR/2005/WD-xlink11-20050707/
in the context of
http://www.w3.org/TR/xlink10-ext/
and has the following observations:

1) General

Thank you for producing a clear set of requirements that describe the
1.1 work, and then meeting those requirements. This is a useful revision
to the specification. We have some detailed comments, please see below.

2) Making simple XLinks an application-level default

As http://www.w3.org/TR/xlink10-ext/ notes,

  "When XLink 1.0 was developed, it seemed reasonable to depend on DTD
  validation to provide this default value when it was a burden to
  authors to enter it by hand"

While noting in passing that the assignment of default attribute values
is independent of validation, we agree both that it seemed reasonable at
the time (and this is exactly what the SVG 1.0 and 1.1 DTDs did) and
also agree that it gives problems because of the optional fetching of
the external DTD subset and the annoyance of putting it in the internal
DTD subset.

Therefore, the wording at
http://www.w3.org/TR/2005/WD-xlink11-20050707/#markup-reqs
is very useful:

  "2. it does not have a type attribute from the XLink namespace and it
  adheres to the conformance constraints imposed by the XLink simple
  element type, as prescribed in this specification."

However, this text is contradicted in several places as noted below.

2.1) type attribute still sometimes required

It seems that if the href attribute is *not* supplied, which is allowed
by XLink 1.1, the type="simple" must be supplied - is that intentional?
SVG WG is okay with this restriction, if it was intended, but would
prefer not to have this restrivtion.


2.2) Specification text contradictory

4.1 XLink Attribute Usage Patterns
http://www.w3.org/TR/2005/WD-xlink11-20050707/#d0e594

states, for simple links

  "At least one of type or href must be specified".

However,

http://www.w3.org/TR/2005/WD-xlink11-20050707/#link-types

states

  "The value of the type attribute must be supplied."

We assume the latter is an editorial oversight and this should in fact be
something like:

  The value of the type attribute must be supplied, unless a simple link
  is required and an href is supplied.

Similarly in
http://www.w3.org/TR/2005/WD-xlink11-20050707/#simple-links

  "The XLink element for simple links is any element with an attribute
  in the XLink namespace called type with a value of "simple""

is incorrect and is contradicted by the example that follows it. We
suggest that it should be something like

  The XLink element for simple links is any element with either a) an
  attribute in the XLink namespace called href and no attribute in the
  XLink namespace called type, or b) an attribute in the XLink namespace
  called type with a value of "simple".

2.3) DTD fragment contradicts spec

The following DTD sample from the specification

<!ATTLIST commandname
  xlink:type      (simple|none)   #REQUIRED
  xlink:href      CDATA           #IMPLIED>

seems to give the impression that type is required. We suggest replacing
this with a more expressive RelaxNG snippet which states that if href is
supplied, the type attribute is optional. The relevant portion of
Appendix D may be suitable:

simple = element * {
    (simple.type | href.att | (simple.type, href.att)),
     foreign.att*, role.att?, arcrole.att?, title.att?,
     show.att?, actuate.att?,
     (anyElement | text)*
    }

2.4) Example incorrect in 5.2
The example with the caption

  Example: Sample simple-Type Element Declarations and Instance

http://www.w3.org/TR/2005/WD-xlink11-20050707/#simple-links

is incorrect.

  xlink:role      NMTOKEN         #FIXED "http://www.example.com/linkprops/student"

xlink:role
E The defaultValue "http://www.example.com/linkprops/student" of
attribute "xlink:role" is not legal as for the lexical constraints of
this attribute type.

This should be CDATA not NMTOKEN

3) Reserving all attributes in the XLink namespace.

This is a useful clarification.


4) Allowing IRIs.

4.1) Inadvertent text from XLink 1.1

In section 5.4 Locator Attribute (href)
http://www.w3.org/TR/xlink/#link-locators

  "The value of the href attribute must be an IRI reference as defined
  in [IETF RFC 3987] or must result in an IRI reference after the
  escaping procedure described below is applied."

That text is incorrect, and seems to be the result of a search and
replace of URI for IRI. The whole point is that the escaping is not
required in the XML instance, and is defined by the IRI specification.
The text should in fact be, simply,

  The value of the href attribute must be an IRI reference as defined
  in [IETF RFC 3987].

So
   http://example.org/L'été
which is an IRI, not
  http://example.org/L'%C3%A9t%C3%A9
which is the corresponding URI

See below (4.3) for suggested wording that includes this text.

4.2) Escaping space

In section 5.4 Locator Attribute (href)
http://www.w3.org/TR/xlink/#link-locators

  "However, for backwards compatibility, XLink 1.1 processors must
  escape one additional character, the space. All occurrences of a space
  in the value of an href attribute must be replaced by %20."

This seems to mix levels. Its actually in the IRI reference that space
must be escaped, not in the resulting URI (where it will get escaped
anyway, as happens now).

So
  <simple xlink:href="http://example.org/My%20Little%20Pony.jpg">
not
  <simple xlink:href="http://example.org/My Little Pony.jpg">

and (IRI with escaped space)
   http://example.org/L'été%20suivante
not (IRI)
  http://example.org/L'été suivante
nor (URI)
  http://example.org/L'%C3%A9t%C3%A9%20suivante

So its not 'escape one additional character', because IRI to URI already
requires escaping the space. Furthermore, the 'class of product' is the
content, not the processor.

4.3) Suggested text for section 5.4 Locator Attribute (href)

To accommodate the corrections from 4.1 and 4.2 we suggest that instead
of these two paragraphs:

  The value of the href attribute must be an IRI reference as defined in
  [IETF RFC 3987] or must result in an IRI reference after the escaping
  procedure described below is applied. (By design, all URIs (Uniform
  Resource Identifiers) as defined in [IETF RFC 3986] are also IRIs.)

  XLink 1.0 described a procedure for escaping characters found in the
  href attribute value that were not allowed in URIs. For XLink 1.1,
  those details are normatively described in Section 3.1 of [IETF RFC
  3987]. However, for backwards compatibility, XLink 1.1 processors must
  escape one additional character, the space. All occurrences of a space
  in the value of an href attribute must be replaced by %20.

we suggest

  The value of the href attribute must be an IRI reference as defined in
  [IETF RFC 3987]. (By design, all URIs (Uniform Resource Identifiers)
  as defined in [IETF RFC 3986] are also IRIs.) For backwards
  compatibility, all occurrences of a space in the value of an href
  attribute must be replaced by %20 in conformant XLink 1.1 content.

and then say (this next part *is* about processors)

  Note: XLink 1.0 described a procedure for allowing an IRI as the value
  of an href attribute and converting it to a URI by escaping characters
  found in the href attribute value that were not allowed in URIs. XLink
  1.1 processors must convert IRIs to URIs as described in in Section
  3.1 of [IETF RFC 3987] before dereferencing them, if the transport
  does not accept IRIs directly.

4.4)  Checking

  Because it is impractical for any application to check that a value is
  a URI reference, this specification follows the lead of [IETF RFC
  3986] in this matter and imposes no such conformance testing
  requirement on XLink applications.

Since the value of href is an IRI reference, not a URI reference, this
should presumably say

  Because it is impractical for any application to check that a value is
  an IRI reference, this specification follows the lead of section 6.1
  of [IETF RFC 3987] in this matter and imposes no such conformance
  testing requirement on XLink applications.

Section 6.1 of RFC 3987 says "(Note: In accordance with URI practice,
generic IRI software cannot and should not check for such limitations.)"

4.5) Relative IRIs

The current text is

  If the URI reference is relative, its absolute version must be
  computed by the method of [XML Base] before use.

Presumably URI reference should be IRI reference. In addition, section
6.5. Relative IRI References of RFC 3987 should be pointed to. We
suggest

   If the IRI reference is relative, its absolute version must be
  computed by the method of [XML Base] and section 6.5 of [IETF RFC
  3987] before dereferencing.

4.6) Fragments

The current text is

  For locators into XML resources, the format of the fragment identifier
  (if any) used within the URI reference is specified by the XPointer
  specification [XPTR].

[XPTR] points to
    http://www.w3.org/TR/2001/WD-xptr-20010108/
whose latest version is
    http://www.w3.org/TR/xptr/
which says that it is superceded by
    http://www.w3.org/TR/xptr-framework/
    http://www.w3.org/TR/xptr-element/
    http://www.w3.org/TR/xptr-xmlns/
    http://www.w3.org/TR/xptr-xpointer/

We suggest this wording

  For locators into XML resources, the format of the fragment identifier
  (if any) used within the URI reference is specified by the XPointer
  Framework specification [XPTR Framework].

5) Providing Sample XML Schema and RELAX NG Grammars.

These are useful additions, thank you for including them.

6) Attribute Value Defaulting
In section 4.3 Attribute Value Defaulting
http://www.w3.org/TR/2005/WD-xlink11-20050707/#defaulting

please point out that relying on processing of the external DTD subset
is non-interoperable as fetching it is optional for non-validating
processors.

  

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Saturday, 3 September 2005 03:50:29 UTC