Re: XForms 3.2.2 Linking Attributes

From: <AndrewWatt2001@aol.com>

> I would like to be significantly clearer about which "problem" the
proposed
> "solution" actually addresses.

Principally the restriction of one URI per element.

> If I read your comment correctly, some other language has implicit
> significant design constraints on XForms. Is that a fair conclusion?

No, that would be a misreading.

> Which languages, current or future, require more than one URI on an XForms
> element?

Who knows? That is one of the challenges of designing markup languages
intended for integration. However we don't want them to be restricted in
their ability to use or integrate XForms. We want a future-proof XForms.

> To achieve which functionality?

Whichever necessary.

> Would an XLink extended link provide the "missing" functionality?

You miss the point. We want markup languages to be able to integrate with
XForms without having to redesign their, or our, content models. You
probably saw the discussion on www-svg recently that pointed out that you
can't turn every element in SVG into a link because xlink:href is already in
use on some elements. You would have to redesign SVG. That's the sort of
thing we're talking about. We don't want that to prevent integration.

Try it yourself with the <instance> element, and you'll hopefully see where
it breaks.

> Which XForms elements depend on more than one URI being present on an
element
> in a host language?

You miss the point. In designing a language for integration with other
languages, you do not know a priori which other languages might use your
language, nor what URIs (or any other data types) they might bring with
them. This is why there is no attribute of type ID in XForms, for instance,
just the requirement that the host language add one to each element. There
is of course a limit to how far you can go with this sort of shielding, but
we want to push that limit out as far as possible.

> In passing, how does bypassing XLink on the XForms
> element affect the presence of zero, one or more URIs on an element in a
host
> language?

In the combined language, not the host language. XLink restricts you to one
xlink:xref per element, so we 'give' that to the host language to use as it
sees fit and use another syntactic expression of the URI in XForms. However
we still use the relevant XLink semantic properties to define the meaning.

> Could you please provide concrete examples of where / when you envisage
that
> the points you mention might be a tangible issue for XForms?

It's a design issue. See above.

> Would I be correct in surmising that one possible constraining language is
> XHTML 2.0?

No. That would be missing the point.

> > We anticipate the publication within two weeks of the first public
working
> > draft of a specification for layering XLink properties onto attributes
> > without using the XLink syntax.
>
> This seems unsatisfactory to me. To propose that XForms proceed to
Candidate
> Recommendation on the implicit basis of a document which has not yet
reached
> first public Working Draft stage seems unwise. It almost suggests that a
fait
> accompli is the unstated aim.

Not at all! Whether or not the new document gets released, or even accepted,
XForms can still work, in the same way that a conformant XHTML user agent is
not required to implement CSS even though XHTML defines its standard
presentation in terms of CSS. The new document will just provide a mechanism
that generalises what we have in particular, and extend XLink use to a wider
class of documents than those limited to the restricted syntactic style
envisaged by the XLink designers. I expect XLink lovers will be pleased,
because like removing <font> from HTML and replacing it with font properties
in CSS, you will be able to achieve exactly the same effect, and more, and
yet not have to commit your document to one particular formulation. It will
even be possible to make RDF semantically XLink compatible!

> As Ann Navarro likely will have informed you there are several unanswered
> questions on a discussion on XML-Dev relating to XLink and XHTML 2.0. I
was
> left with the impression that further information would be provided on
those
> points on your return from leave. Much of that discussion was bogged down
> because of the absence of a public draft stating the case about supposes
> inadequacies of XLink, perhaps the paper you now refer to.

The major inadequacies of XLink for the current discussion are the
restriction of one URI per element.

> I know that many will read the document with interest when it emerges. It
> would be a courtesy if you could let www-forms and XML-Dev know when that
> paper is publicly available.

Of course.

Best wishes,

Steven Pemberton
Co-chair W3C Forms Working Group

Received on Wednesday, 28 August 2002 05:39:00 UTC