Re: [Moderator Action] Re: XForms WD 20020821 - 3.2.2 What are linking attributes for?

Moderator: sent to www-forms@w3.org and www-forms-editor@w3.org 
  ----- Original Message ----- 
  From: AndrewWatt2001@aol.com 
  To: steven.pemberton@cwi.nl ; www-forms@w3.org ; www-forms-editor@w3.org ; w3c-forms@w3.org ; xforms@yahoogroups.com 
  Sent: Friday, August 30, 2002 2:12 PM
  Subject: [Moderator Action] 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