OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] After XQuery, are we done?

[ Lists Home | Date Index | Thread Index ]

So, essentially, pull the just-in-time linking we build 
into our procedural code out and expose it as declarative 

For example, in markup, we see things like

<asp:radiobuttonlist id="optUpdateScope" style="Z-INDEX: 120; LEFT: 230px; 
    POSITION: absolute; TOP: 380px" runat="server" ForeColor="ActiveCaption"

    Height="32px" Width="111px">
	 <asp:ListItem Value="This Table" Selected="True">This
	 <asp:ListItem Value="All Tables" Selected="True">All

or variants based on the control type.   They might be passing a value such
as shown, 
or a URI, etc.   Or in code something like

ArrayList topicList = new ArrayList();
topicList.Add ("Edit Table Description");
topicList.Add ("Edit Field Description");
topicList.Add ("Edit Table Caption");
topicList.Add ("Edit Field Caption");
topicList.Add ("Edit Field Example");
topicList.Add("Empty Table Description");
topicList.Add("Empty Field Description");
topicList.Add("Empty Table Caption");
topicList.Add("Empty Field Caption");
cboEditTopic.DataSource = topicList;

I see the point of being able to expose relationships to Google 
as in the asp example above.  Otherwise we are substituting 
n-way links for controls.  Six of one, half a dozen...


From: 'Liam Quin' [mailto:liam@w3.org]

On Thu, Oct 21, 2004 at 02:45:32PM -0500, Bullard, Claude L (Len) wrote:
> Even when we played with n-way links, linkbases, etc., most of the
> implementations I saw were pop-up menus and the like with a query
> returning a set of values then used to initialize the control. Given
> what we have for controls, is there something better about an n-way
> link beyond using Add.Item, SelectedItem.Text, etc. other than having
> a platform independent way to say that without having to know which
> GUI we are designing for?

Yes.  Google can't follow procedural links, and isn't likely to.
Procedural (ECMAscript) links are hard to manage and maintain.  They're
hard to reason about.  They're hard for archiving bots to follow.
They're often not made accessible, because the Web designer made them
rather than the browser/UA developer.  They can be hard to
internationalise.  Or internationalize in other places :-)

All the usual reasons why standards can help.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS