[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [regrep] [Namespace Manager Proposal] FW: XMLNDR [Broken URL] RE: XMLNDR PURLs, Handles, URLs, URNs & Namespaces
Link is now restored:
http://lists.oasis-open.org/archives/regrep/200201/msg00061.html
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
O: 703-902-6923
C: 202-251-0731
Visit us online@ http://www.boozallen.com
> -----Original Message-----
> From: Robin Cover [mailto:robin@oasis-open.org]
> Sent: Saturday, September 03, 2005 9:09 PM
> To: Chiusano Joseph
> Cc: ebXML Regrep
> Subject: Re: [regrep] [Namespace Manager Proposal] FW: XMLNDR
> [Broken URL] RE: XMLNDR PURLs, Handles, URLs, URNs & Namespaces
>
> On Fri, 2 Sep 2005, Chiusano Joseph wrote:
>
> > Back in January 2002 I submitted a proposal to our list for a
> > "Namespace Manager" function. The archive link is forever gone, and
> > Robin Cover asked me to send him a summary of the
> highlights of that
> > proposal. I am sending this to refresh our collective
> memories of this
> > proposal, as we look toward version 4.0 (hint hint;)
> >
> > Ironically (as you can see from the right side of the
> e-mail subject)
> > I sent the archive URL in support of a discussion on persistent
> > identifiers on the "U.S. Federal XML Naming and Design Rules"
> > listserv, and subsequently discovered that it was a broken link.:p
> >
> > To those in the U.S.: Happy Labor Day weekend.
> >
> > Joe
> >
> > Joseph Chiusano
> > Booz Allen Hamilton
> > O: 703-902-6923
> > C: 202-251-0731
> > Visit us online@ http://www.boozallen.com
> [... see
> http://lists.oasis-open.org/archives/regrep/200509/msg00010.html ]
>
> Joe and TC,
>
> 1) It does appear that some 2000-2500 messages (est.) are now missing
> from the TC's email list archive, for years 2002 and earlier
>
> 2) I have communicated my concern to the OASIS administration, hopeful
> that we can have the resources restored to their canonical URIs
> within a short time. Subsequent to posting my note referenced in
> "3)", I observed that at least some of the messages are stored
> on the WayBack machine, including Joe's lost posting from
> the regrep
> archive
>
> 3) I have conveyed a message of [unofficial] apology to the
> FED-XML-NDR
> community within which this discovery of AWOL resources was
> discovered:
>
>
> https://fed-xml-ndr.core.gov/servlets/ReadMsg?list=listserv&msgNo=449
>
> 4) In principle, I think OASIS is committed to the practice of
> "not breaking links" to resources for which the organization has
> published dereferenceable URIs. What may be needed is a policy
> which implements, in tangible business terms, a strategy to
> ensure that links are not broken, to monitor the websites for
> resources gone AWOL, and to repair inadvertently broken links.
>
> 5) The larger discussion about "broken links" on the FED-XML-NDR list
> prompted me to write up a renewed appeal for technologists to
> insist upon instititional commitments to the preservation of
> public resources and the preservation of links to resources
> identified with dereferenceable URIs.
>
> I append a portion of this note below, asking for the participation
> of members on the ebXML Regrep TC, in any forum where you
> participate, in raising consciousness about the role (I believe)
> we play in correcting this widespread problem of resource
> deterioration. The deplorable situation will change, it
> seems to me,
> only when all of us demand commitment, policy, and vigilance on the
> part of jurisdictions and institutions responsible for persistent
> resources and links.
>
> If the perspective adopted in the note below is defensible (you
> be the judge! - but it's optional reading), there is fundamentally
> no excuse, in mid 2005, for broken links. Radically revising our
> common expectations and calling public institutions to account for
> data loss are probably prerequisite to seeing substantial changes.
> Shrugging our shoulders and saying "That's the Web" is no solution.
>
> Thanks,
>
> Robin Cover
>
> ================= Note on resource "persistence" follows:
>
> [...]
>
> As a matter of personal judgment, I believe there is now
> consensus technical opinion that accessible Web technologies,
> informed by sound principles of Web Architecture [2], are now
> *more than adequate* to support both resource and link
> persistence: institutions (as URI owners) that exhibit,
> through public behavior, doubt about the adequacy of this
> available technology, are apparently:
>
> a) uninformed [e.g., unaware that HTTP and free server software
> provide the means to manage resource/link persistence]
> b) unwilling to commit (axiologically) to core principles and
> values about resource/link persistence
> c) unwilling to commit resources to ensure resource/link
> persistence
> d) incompetent in one or more ways possibly related to "a)" - "c)"
> e) did I miss anything in a-e ? Maybe also: "inattentive"
> as a sub-species of a-c
>
> Although the terminology used to describe URI persistence is
> a bit problematic sometimes [3], I believe there is now
> general agreement with principles articulated in the W3C Web
> Architecture document, viz.,
>
> [We share a] "social expectation that once a URI identifies
> a particular resource, it should continue indefinitely to
> refer to that resource."
>
> combined with resource persistence (a dereferenced URI gets
> you the resource consistently and predictably):
>
> "A URI owner SHOULD provide representations of the identified
> resource consistently and predictably."
>
> These values and principles were expressed in a poorly-titled
> [4] document "Cool URIs don't change", written in 1998 [5].
>
> The core assertion is captured in the first forty-eight words
> of that 1998 TBL memo:
>
> "What makes a cool URI?
> A cool URI is one which does not change.
> What sorts of URI change?
> URIs don't change: people change them.
> There are no reasons at all in theory for people to change
> URIs (or stop maintaining documents), but millions of
> reasons in practice."
>
> The plausible excuses for breaking links commonly offered by
> people in 1998 are now, in 2005, simply lame excuses:
>
> * "We just reorganized our website to make it better."
> * "We have so much material that we can't keep track of what is
> out of date and what is confidential and what is valid and
> so we thought we'd better just turn the whole lot off."
> * "Well, we found we had to move the files..."
> * "We used to use a cgi script for this and now we use a binary
> program."
> * "I didn't think URLs have to be persistent - that was URNs."
> * "We would like to, but we just don't have the right tools."
>
> Since 1998, web resources, tools, and technologies have
> improved dramatically, making it easier than ever to support
> the preservation and integrity of Web-accessible resources.
>
> * the cost of disk storage has plummeted faster than for
> semiconductors, according to Kryder's Law ("Moore's Law for
> Storage"), -- the "doubling of processor speed every 18 months
> is a snail's pace compared with rising hard-disk capacity"
> One can get a 300 gigabyte Barracuda for just $150 [6].
>
> * HTTP (1.0, 1.1) [7] is now widely supported by open source (free,
> publicly available) server software which provides web site
> administrators (as URI owners) with rich tools for managing
> predictable, stable, and "indefinite/persistent" support
> for published URIs, even in the face of moving web sites
> or otherwise re-architecting enterprise web server
> topologies. See for example the free Apache Server [8], which
> has binaries for UNIXes and Win32, with support for rule-based
> URL rewriting, mapping URLs to filesystem locations, content
> negotiation, use of virtual hosts, etc. [9]
>
> * generic web analysis and monitoring tools now make it easy to
> detect the existence of broken links; their statistical modules
> help interpret the results for web site administrators, providing
> early notification when something has gone wrong
>
> In the context of this FED-XML-NDR discussion, within earshot
> of some very important (government) policy-makers, I am
> thrilled to read statements of general concern about "Broken
> URLs." It's a plague and a scourge upon the Web, as is
> commonly lamented.
> Part of the solution, I believe, is to reshape public
> expectations based upon the conviction that there are NO (or
> few) valid excuses for breaking links. Institutions that
> elect to use BAD software ('broken as designed') which cannot
> even be configured to maintain persistent links/resources
> should be called to public account. Institutions
> (jurisdictions) that demonstrate negligible commitment to
> preservation of resources and links should likewise be called
> to public account. IMO.
>
> In addition to individual and institutional commitment to
> resource persistence, it will help to design architectures
> within which the preservation of resources and links is
> consciously planned for, and optimized, rather than ignored.
> I'm happy for Owen Ambur's statements of support, and for
> Todd Vincent's words, "The system I have been describing
> accomplishes this requirement." [10]
>
> As as aside, I have noted the increasing popularity of RDDL
> (Resource Directory Description Language) as a method of
> providing something informative when designers want to create
> http (scheme) URI namespace names that do not directly
> resolve under HTTP/DNS to the XML Schema (resource). The RDDL
> "namespace document" is a simple [enhanced] XHTML document
> that lives at the end of a dereferenced http URI namespace,
> convening information about the nature and purpose(s) of the
> resource associates with the namespace URI, including
> typically, (URI-reference) hyperlinks to schemas,
> specifications, editor contacts, etc.
>
> See http://xml.coverpages.org/rddl.html
>
> Thanks,
>
> Robin Cover
> [speaking only personally and unofficially] XML Cover Pages
> http://xml.coverpages.org/
>
> * please send corrections to this message via email:
> robin@oasis-open.org
>
> ========= References:
>
> [1]
> https://fed-xml-ndr.core.gov/servlets/ReadMsg?list=listserv&msgNo=448
>
> https://fed-xml-ndr.core.gov/servlets/ReadMsg?list=listserv&msgNo=445
>
> https://fed-xml-ndr.core.gov/servlets/ReadMsg?list=listserv&msgNo=442
>
>
> https://fed-xml-ndr.core.gov/servlets/ReadMsg?list=listserv&msgNo=443
>
> "I just found out that the URL I provided is now broken;
> I will try and find out from OASIS how to retrieve it from
> their architectures (it's broken in the OASIS ebXML
> Registry listserv public archives as well). Sorry for the
> inconvenience."
>
> [2] URI persistence
> Architecture of the World Wide Web, Volume One
> W3C Recommendation 15 December 2004
> http://www.w3.org/TR/webarch/#URI-persistence
>
> [3] "persistence" in connection with "link", "URI", "resource",
> and "representation" is potentially a confusing term because
> it does not clearly specify what "persists." The phrases
> "stability," "predictability," and "consistent" are used
> in the W3C Web Architecture document to address the notion
> of persistence. "Policy and commitment on the part of the
> URI owner" are also foundational concepts. Excerpt:
>
> "confidence in interactions via the Web depends on stability
> and predictability. For an information resource, persistence
> depends on the consistency of representations...Although
> persistence in this case [Representation Management] is
> observable as a result of representation retrieval, the term
> URI persistence is used to describe the desirable property
> that, once associated with a resource, a URI should continue
> indefinitely to refer to that resource...
>
> Good practice: Consistent representation. A URI owner SHOULD
> provide representations of the identified resource
> consistently and predictably.
>
> URI persistence is a matter of policy and commitment on the
> part of the URI owner...
>
> HTTP [RFC 2616] has been designed to help manage URI persistence.
> For example, HTTP redirection (using the 3xx response codes)
> permits servers to tell an agent that further action needs to
> be taken by the agent in order to fulfill the request
> (for example, a new URI is associated with the resource)...
> In addition, content negotiation also promotes consistency, as
> a site manager is not required to define new URIs when adding
> support for a new format specification
>
> For more discussion about URI persistence, see "Cool URIs
> don't change" 1998, by Tim BL [at]
> http://www.w3.org/Provider/Style/URI.html
>
> A "consistent representation" that provides stability and
> predictability for a URI-dereferenceable resource means
> not only indefinite association of a URI with a resource,
> but indefinite support for retrieval via dereferencing.
>
> In this context we are not concerned with URIs that are
> not initially intended by URI owners as identifiers for
> dereferenceable resources, per:
> http://www.w3.org/TR/webarch/#representation-management
> Representation Management: "Just because representations
> are available does not mean that it is always desirable
> to retrieve them..."
>
> [4] the authors of the W3C Web Architecture document
> acknowledge that the title "Cool URIs don't change"
> is infelicitous: "Note that the title is somewhat misleading.
> It is not the URIs that change, it is what they identify."
> http://www.w3.org/TR/webarch/#Cool
>
> [5] "Cool URIs don't change" 1998, by Tim BL
> http://www.w3.org/Provider/Style/URI.html
>
> [6] cost of disk/mass storage
> http://en.wikipedia.org/wiki/Kryder%27s_Law
> http://en.wikipedia.org/wiki/Moore's_law
> http://www.storagereview.com/
>
> ST3300831AS 300GB Barracuda $150 [2005-09-03, online]
> 8-gigabyte 1-inch microdrives 60-gigabyte 1.8-inch Slim Bling
> hard drive
>
> http://tinyurl.com/extmh
> Kryder's Law, by Chip Walter
> The doubling of processor speed every 18 months is a snail's
> pace compared with rising hard-disk capacity, and Mark Kryder
> plans to squeeze in even more bits... By 1998, when Kryder
> joined Seagate to form its advanced research center, the DSSC
> had set an even loftier target: crowd 100 gigabits into a
> square inch by the early 21st century. In 2005, just seven
> years later, Seagate began shipping 110-gigabit drives.
> Inside of a decade and a half, hard disks had increased their
> capacity 1,000-fold, a rate that Intel founder Gordon Moore
> himself has called "flabbergasting."
>
> [7] http://www.ietf.org/rfc/rfc2616.txt
> http://www.w3.org/1999/07/HTTP-PressRelease July 07, 1999
> "World Wide Web Consortium Supports HTTP/1.1 Reaching IETF
> Draft Standard"
>
>
> [8] http://httpd.apache.org/
> Apache HTTP Server Project "The Number One HTTP Server on
> the Internet"
>
> The Apache HTTP Server Project is a collaborative software
> development effort aimed at creating a robust,
> commercial-grade, featureful, and freely-available source
> code implementation of an HTTP (Web) server... Apache has
> been the most popular web server on the Internet since
> April of 1996. The February 2005 Netcraft Web Server Survey
> found that more than 68% of the web sites on the Internet
> are using Apache, thus making it more widely used than all
> other web servers combined."
>
> [9] http://httpd.apache.org/docs/2.0/misc/rewriteguide.html
> http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html
> URL Rewriting Guide
>
> A versatile and powerful set of tools for: forcing the use of
> canonical hostnames; creating a homogeneous and consistent
> URL layout over all WWW servers on a Intranet webcluster;
> redirecting *just* all homedirs on one webserver to another
> webserver; redirect homedir URLs to another webserver when
> the requesting user does not stay in the local domain;
> filesystem reorganization; redirecting failing requests on
> webserver A to webserver B; extended redirection supporting
> character escaping mechanisms; time-dependent rewriting;
> load balancing; on-the-fly content-regeneration; seamless
> transformation from static to dynamic; mass virtual hosting;
> use of an external rewriting engine; etc
>
> http://httpd.apache.org/docs/2.0/content-negotiation.html
> Content Negotiation
>
> http://httpd.apache.org/docs/2.0/urlmapping.html
> Mapping URLs to Filesystem Locations
>
> http://httpd.apache.org/docs/2.0/vhosts/
> Apache Virtual Host documentation
>
> [10] statements from Owen Ambur and Todd Vincent
> https://fed-xml-ndr.core.gov/servlets/ReadMsg?list=listserv&msgNo=444
> https://fed-xml-ndr.core.gov/servlets/ReadMsg?list=listserv&msgNo=446
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]