Re: XForms WD 20020821 - 3.2.2 What are linking attributes for?

In a message dated 30/08/2002 11:59:19 GMT Daylight Time, 
steven.pemberton@cwi.nl writes:


> > - which is only allowed a single root element -
> > then it follows that it is not allowed to embed two documents since that
> > would break the "single root element" rule.
> 
> Well, your premise is wrong, but even if it had been right your conclusion
> would still be wrong, because no one is suggesting embedding two documents.


I see. 

But wasn't the supposed "need" to reference more than one URI a principal 
reason for the XForms WG's abhorrence of XLink?

> 
> > That being the case it seems to refute Steven Pemberton's suggestion that
> it
> > may be necessary to link to more than one document.
> 
> You haven't yet got it, I'm afraid. I'm wary of giving concrete examples
> because I fear you would start arguing the details of the concrete example
> rather than seeing it as an expression of the general problem, which is not
> solvable except on a case by case basis if you adopt another approach than
> ours. I suggest you re-read my earlier mail and try to understand better
> what I was saying.
> 
> Best wishes,
> 
> Steven Pemberton
> Co-chair, W3C Forms Working Group
> 
> 

Steven,

I assume you are referring to 
http://lists.w3.org/Archives/Public/www-forms-editor/2002Aug/0026.html, the 
full text of which is copied here for ease of reference.

<quote>
[I had written]
> 2. If the [src] attribute has XLink-compliant behaviour why isn't it inthe 
XLink
> namespace with XLink attribute names?
[Steven Pemberton replied]
Since XLink makes syntactic restrictions on markup using it (only one URL per 
element) it makes it very difficult for markup like XForms, that is designed 
to be integrated into other languages, to use it, since there is no way of 
knowing a priori if any potential host language already has URIs on relevant 
elements, or requires other URIs on elements being integrated into it.

Therefore to bypass this problem, we use XLink semantic properties, but not 
syntactic properties.

We anticipate the publication within two weeks of the first public 
workingdraft of a specification for layering XLink properties onto 
attributeswithout using the XLink syntax.
Best wishes,Steven PembertonCo-Chair, W3C Forms working group
</quote>

I assume you are referring to the paragraph beginning "Since XLink ...".

It seems to me that, in part, you are confusing URIs on XForms elements with 
anchors (or similar constructs) on HTML/XHTML elements. But let's put that 
potential confusion to one side.

To me that paragraph makes no case for an avoidance of XLink but rather makes 
a case FOR using XLink (with XPointer).

Let me explain.

You claim that the lack of more than one URI per element in XLink is a 
problem. But the src attribute in XForms has precisely the same limitation - 
of a single URI on an XForms element - as far as I can see. If the src 
attribute is of type xsd:anyURI how is it possible for a src attribute to 
reference more than one URI?

I assume that you are not suggesting that XForms elements should have more 
than one src attribute per element, since that would not be well-formed XML.

So using src instead of xlink:href seems to solve nothing.

Further, you indicate that "since there is no way of knowing a priori if any 
potential host language already has URIs on relevant elements, or requires 
other URIs on elements being integrated into it.". 

Are you thinking in the box of HTML/XHTML anchors? Isn't it the constraints 
of that model that XLink/XPointer are designed to solve?

Using XLink with XPointer will solve that problem since there is no need to 
depend on a document author adding anchors (or any non-HTML//XHTML) 
equivalents.

As I read your comments they fail to make a case for the avoidance of XLink 
and, indeed, make a strong implicit case for the use of XLink with XPointer.

Regards

Andrew Watt