W3C home > Mailing lists > Public > public-egov-ig@w3.org > April 2009

RE: Group Note FPWD is done

From: Sharron Rush <srush@knowbility.org>
Date: Sun, 19 Apr 2009 12:28:25 -0500
To: "eGov IG" <public-egov-ig@w3.org>
Cc: "Jose M. Alonso" <josema@w3.org>
Message-Id: <20090419165133.1096658363@prnetwtsv020.primusnetworks.com>
Hello editors,

Sorry to be posting so often, but am trying to get up to speed within 
the group.

I have a procedural question.  How does the IG log the comments that 
we receive about the current Working Draft?  Do we maintain a 
database and if so, do we note how each comment is resolved?  I have 
been going back through the list to review comments that have been 
received so far and wonder who responds and what the process 
is.  Perhaps it is on the wiki, and if so, I apologize for not being 
able to find it.

Many thanks for any guidance you can provide.


At 10:38 PM 4/16/2009, Hugh Barnes wrote:
> > -----Original Message-----
> > From: public-egov-ig-request@w3.org
> > [mailto:public-egov-ig-request@w3.org] On Behalf Of Jose M. Alonso
> > Sent: Monday, 2 March 2009 8:09 PM
> > To: eGov IG
> > Subject: Group Note FPWD is done
> >
> > All,
> >
> > It has been a very intense weekend. Some of us, namely Kevin,
> > John and
> > me have been working until the very last minute on developing the
> > final draft. We have worked on the document until yesterday night,
> > then called it done.
> >
>I have only recently caught up with the list backlog. This looks 
>like the beginnings of an excellent resource. I agree, as some have 
>suggested, that it might need to be slightly differently pitched to 
>most W3C documents, in order to make the most impact on its target audience.
> > Final document is a snapshot of the current Editor's Draft
> > [1] and we
> > are requesting publication on March 10; comments will be welcomed
> > until April 26.
> >
>Something I'd like to see emphasised more is good practice around 
>URIs (generally URLs in this context). They are given a few 
>mentions, and those parts are really very well written (and bear repeating):
>"Transposed to namespaces and URIs this is quick sand on which to 
>build an essential information infrastructure using the 
>Web.</p><p>To give an example of the consequences of this churn, 
>governments have difficulty maintaining persistent URIs even to 
>documents. Increasing volumes of official reports and documents are 
>published on the Web alone making the long term availability of 
>those resources an important issue. In this context 'link rot' is 
>not just an inconvenience of the user, it undermines public 
>accountability as documents cease to be available." [1]
>I would only add to this that inability to persist resources and 
>manage URLs inhibits willingness to link between government 
>agencies. This is a loss for users who wants a seamless government 
>website experience and don't care which agency (or even government) 
>hosts the information they seek. Government departments need to deep 
>link more and with minimal risk consideration.
>A small working group within Queensland Government has produced some 
>guidelines for minting and managing URLs because we believe they are 
>pivotal to an effective web presence. The guidelines are accompanied 
>by a business case and a solution specification. Though we have 
>received some level of in-principle endorsement, I don't believe our 
>mindshare is strong. We still struggle to convey the importance of 
>the concepts. Important underpinning government-wide resources like 
>legislation remain difficult to link to. (This also makes it 
>near-impossible for us to populate the AGLS.mandate element.)
>So I suggest a (sub)section giving the topic more prominence. It 
>would probably fit well within 
>The section should cover:
>* that resources must be addressable canonically and persistently, 
>including the appropriate and correct provision of fragment identifiers [2]
>* the importance of trust in encouraging inward links and use of exposed data
>* why URLs should be readable, logical, internally consistent, and 
>truncatable (provides yet another interface to your data)
>* managing and persisting URLs through HTTP rather than client-side 
>techniques like JavaScript
>It might also cover:
>* why HTTP redirects should only be made where the resource is 
>essentially the same (I see a lot of redirects from a "deep" 
>resource to a section entry page at its new location)
>* why risk-averse indirect linking practices (e.g. interstitial 
>pages, inplace warnings ("[external website]"), JavaScript warnings 
>[3], spawning new windows, referrer URLs) are harmful and do little 
>except inconvenience users
>I realise all that may be too much detail for an overview document. 
>I cautiously offer to help with a draft. Only "cautiously" because I 
>can't guarantee availability.
>Hugh Barnes
>Resource Discovery Officer
>Disability Services Queensland / Department of Communities
>+61 7 324-74533
>[1] http://www.w3.org/2007/eGov/IG/Group/docs/note#modalities
>[2] The draft itself is exemplary in providing identifiers as anchor 
>points (e.g. [1] itself), but unfortunately these only cover the 
>extent of the section headings. I think this is a legacy W3C template remnant.
>[3] for example, links out of 
>which is cited in the draft as [AU-OGD], and perhaps shouldn't be 
>for this reason.
>"Queensland celebrates its 150th anniversary in 2009. Check out 
>what's on today at www.q150.qld.gov.au."
>********************************* DISCLAIMER *********************************
>The information contained in the above e-mail message or messages 
>(which includes any attachments) is confidential and may be legally 
>privileged.  It is intended only for the use of the person or entity 
>to which it is addressed.  If you are not the addressee any form of 
>disclosure, copying, modification, distribution or any action taken 
>or omitted in reliance on the information is unauthorised.  Opinions 
>contained in the message(s) do not necessarily reflect the opinions 
>of the Queensland Government and its authorities.  If you received 
>this communication in error, please notify the sender immediately 
>and delete it from your computer system network.
>No virus found in this incoming message.
>Checked by AVG - www.avg.com
>Version: 8.0.238 / Virus Database: 270.11.59/2063 - Release Date: 
>04/16/09 16:38:00
Received on Sunday, 19 April 2009 17:29:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:40 UTC