Re: [XHTML2 requirements] +1 for labeledBy

[thread started at
  http://lists.w3.org/Archives/Public/wai-xtech/2002Dec/thread.html#18 ]


At 09:36 PM 2002-12-13, Jason White wrote:
>Al Gilman writes:
>  >
>  >
>  > At the XML2002 Conference I bumped into Emma Antunes who spontaneously
>  > raised as a problem the fact that the html:label can only be for one 
> control
>  > and the control can only have one such label.
>
>As of XHTML 2.0, according to the draft I read a few months back, the
>legacy HTML 4.0 form elements are eliminated completely in favour of
>XForms 1.0, which offers a different set of user interface elements as
>well as the capacity to bind distinct user interfaces to the XForms
>model.

That is true, but it doesn't affect the gathering of requirements.

True, xforms:label is not html4:label.  But it is hard-wired to its
parent parse-tree node.

People doing graphical interaction designs with form elements have found
the need to be able to qualify a control by references to multiple other
entities in the environment.  This is an html4:td.headers workalike
for form controls as they appear in a document in the webtop delivery
context.

A cursory glance into the XForms spec and XHTML 2.0 draft did not yield
a way of doing this that leapt out at me.  Not to say it isn't there,
but until we have an answer as to how one would do this in the new
language, we need to hold onto the "works like" description of what
is sought.

True, XForms can be bound into the host language of your choice.  But
that does not answer the question "Is XHTML 2.0 meeting out needs?"  If
the specification-defined binding of XForms into XHTML 2.0 doesn't meet
our needs, we are in trouble.

[floodgate warning]

Simon St.Laurent's presentation at XML2002 was titled "Getting
Out-of-Line: How  Embedded Markup Can Learn From its Detractors." It is
heavily based on a 1997 article by Ted Nelson:

  XML.com: Embedded Markup Considered Harmful [Oct. 02, 1997]
  http://www.xml.com/pub/a/w3j/s3.nelson.html

Unfortunately, the full abstract is only in the paper proceedings, not
on the website.  I will chase Simon for a web reference.

 From what I can tell from the abstract, Simon's conclusions would generally
support the idea that what is needed is a balanced allocation of relational
semantics among

  a) binding as a rider on the implicit 'any:elementType.parent' relationship,
    and more generally to fixed XPaths that can be constructed from the 
parse tree.

  b) binding to a direct reference arc, indicated locally, by one or the other
    party referring to the other party (cf. html4:td.headers, html4:label.for).
    This relationship may be above and beyond any sense which is consistent in
    its applicability to a give path-pattern.

  c) binding to a less directly indicated relationship, as for example a
    relationship indicated in a multi-pointer assertion not contained in
    any entity which is a party to the relationship.

This is a matter of appropriate allocation of efficiency in the processing,
not necessarily variations in the sense of the graph eventually recovered.
All we need to know about the graph to be communicated is that it is more
richly connected than a tree.  So we need more than method a) affords to
attain adequate expressiveness.  Sometimes it seems that we should skip b)
and just go straight to c).  One can be concerned that this introduces cost
and risk that will come back to bite us in the end.  Of course there is the
risk on the other hand that if we make what is easy be easy using method b)
and the hard is to be conveyed by method c) there is the chance that method
c) is under-implemented like html4:img.longdesc and a few others and we are
still out of luck.  But I don't think this last argument is actually going
to get people to implement interpretive gestures (classes of paths that they
can follow) that they aren't going to implement anyway.

It is not usually sufficient to have only one way to bind such a relational
semantic (such as xlink:link.arcrole is rdfs:about).  This is why we have
both SCOPE and HEADERS in HTML4.

But there are degenerate cases, and we need to understand how to implement
them efficiently.

Inline elements may be viewed as pure property-bearing containers in the
limit, not necessarily creating a notional entity in themselves.  If the
reason for the property is a 'thing' semantic rather than a 'stuff'
semantic, then there needs to be a stronger type notion than html4:span.
But this is not always the case.

One of Ted Nelson's points [as I read Simon's retelling] is that the 'thing'
bias built into XML is a convenience to start, but it bites you if you think
it is all-encompassing.  This is why I keep on harping on post-syntactic
semantics, for the rest of the infoset graph that we need but the parse tree
doesn't give us implicit bindings for.

Likewise, there is a strong case for multi-URI-reference attribute patterns
where the attribute name itself has a unique binding to an xlink:link.role
-equivalent relational semantic and a separate indication of role
would be only an avenue for the entry of noise.  See the
XLink : HLink debates.

Al

Received on Saturday, 14 December 2002 19:12:31 UTC