Re: (PFWG) ACTION-211 Query re: SVG Request for @order for Access Module

Hi, Shane-

Looks pretty much like I expected, thanks.

I took the liberty of rewording and reordering it a bit to use the same 
terminology for both document-order and list-order, and to emphasize 
that the current focus applies to both orderings.  I've also indicated 
what happens if there are duplicate ids, which we know there shouldn't 
be, but which happens anyway.  [Insert proxy diatribe about how XML is 
evil and draconian and doesn't specify error recovery, and is harmful to 
the Real Web.]

Salt to taste:

<h3><code>order</code> = <code>"document* | list"</code></h3>

<p>The <aref>order</aref> attribute indicates how this <code>access</code>
element should determine the <em>navigation order</em> for its
<em>matching elements</em>.  The default value,
<code>document</code>, indicates that the items should be traversed in
document order.  The alternate value, <code>list</code>,
indicates that the <em>navigation order</em> of <em>matching elements</em>
is determined by the author-defined order of items in the list of
<aref>targetid</aref> or <aref>targetrole</aref> attribute values.</p>

<p>For the sake of determining <em>navigation order</em>, elements in the
 document that match the values in the <aref>targetid</aref> or
 <aref>targetrole</aref> attributes are called <em>matching elements</em>,
 and all elements that match the same value are members of an <em>element
 group</em>.  Note: since the <code>id</code> of an element must be unique
 within a valid XML document, in such documents, each <em>element
 group</em> based on <aref>targetid</aref> values must consist of only one
 <em>matching element</em>; in documents with duplicate <code>id</code>s,
 <em>element groups</em> based on <aref>targetid</aref> values may contain
 multiple values, just like those of <aref>targetrole</aref> values.</p>

<p>For each navigation operation, the <em>navigation order</em> for both
 <em>document-order</em> and <em>list-order</em> is sensitive to the 
current
 <em>focus</em> element.  For document-order, if no element currently has
 focus, the first <em>matching element</em> in the document is the focus
 target; if an element does have focus, the next <em>matching element</em>
 in the document is the focus target.  For list-order, the focus target
 <em>navigation order</em> is determined as follows:</p>

<ul>
    <li>If no matching element of this <code>access</code> element
    currently has <em>focus</em>, the focus target is the first
    element in document order that matches the first element group.
    If there is no such element, then the focus target is the
    first element that matches the second element group, and so on.</li>

    <li>If a matching element of this <code>access</code> element
    already has <em>focus</em>:
    <ol>
        <li>If there are additional matching elements of the same
        <em>element group</em> in document order, then focus is sent
        to the next matching element of the same element group.</li>

        <li>Otherwise, focus goes to the first matching element (in
        document order) of the next element group.</li>

        <li>If there are no remaining elements groups, then the search
        resumes from the first element group.</li>
    </ol>
    </li>
</ul>

<p>The location of the next <em>matching element</em> MUST be determined
each time the <code>access</code> element is triggered, since it is possible
that between events the contents of the document will have changed.</p>

Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF


Shane McCarron wrote (on 8/7/08 4:23 PM):
> 
> See if this makes more sense:
> 
> <h3><code>order</code> = <code>"document* | list"</code></h3>
> 
> <p>The <aref>order</aref> attribute indicates how this <code>access</code>
> element should determine the <em>navigation order</em> for its
> <em>matching elements</em>.  The default value,
> <code>document</code>, indicates that the items should be traversed in
> "document order": the next item in the document that matches any selection
> criterion will become the target.  The alternate value, <code>list</code>,
> indicates that <em>matching elements</em> are determined as follows:</p>
> 
> <ul>
>    <li>The values in the <aref>targetid</aref> or <aref>targetrole</aref>
>    are evaluated from beginning to end. Elements in the document
>    that match are called <em>matching elements</em>, and all elements that
>    match the same value are members of an <em>element group</em>.</li>
> 
>    <li>If no matching element of this <code>access</code> element
>    currently has <em>focus</em>, then focus is sent to the first
>    element in document order that matches the first element group.
>    If there is no such element, then the first element that matches the
>    second element group, and so on.</li>
> 
>    <li>If a matching element of this <code>access</code> element
>    already has <em>focus</em>:
>    <ol>
>        <li>If there are additional matching elements of the same
>        <em>element group</em>
>        in document order, then focus is sent to the next
>        matching element of the same element group.</li>
> 
>        <li>Otherwise, focus goes to the first matching element (in
>        document order) of the next element group.</li>
> 
>        <li>If there are no remaining elements groups, then the search
>        resumes from the first element group.</li>
>    </ol>
>    </li>
> </ul>
> 
> <p>The location of the next <em>matching element</em> MUST be determined
> each time the <code>access</code> element is triggered, since it is 
> possible
> that between events the contents of the document will have changed.</p>
> 
> 
> Shane McCarron wrote:
>>
>>
>>
>> Doug Schepers wrote:
>>>
>>> Is there some reason that the way I've explained it here won't work?
>> No - I had just never read that!  That, or a simple variation of it, 
>> would work fine.  In the teleconferences, we were discussing @order 
>> and that it contained a list of IDREFs or CURIEs.  That's where I got 
>> that, and it was stupid.  This makes much more sense.  I will see what 
>> I can do with it.
>>
> 

--

Received on Thursday, 7 August 2008 21:45:50 UTC