One other thing... it is interesting to note the URL for TBLs article: <cut-and-paste> I started investigating this issue by reading Tim Berner-Lee's article on the subject (See http://www.w3.org/Provider/Style/URI.html). Tim makes some interesting recommendations </cut-and-paste>
best, -Rob Robert Koberg wrote: > Hi Diana, > > I am for subject/topics rather than dates. Dates are good for > something that will produced once and never edited again (like news > articles). I think the nature of cocoon-docs would require a good > percentage of the documents to be edited and released several times in > their life. If content needs to be edited after a release and then > re-released, what date do you use? The latest date? This screws up > search engines and peoples bookmarks. Proper naming of the folders and > pages (using captialization where appripriate and/or underscores) > would be much more attractive and understandable, though more work > needs to go into the naming process. > > best, > -Rob > > > Diana Shannon wrote: > >> Given the goal of a clean URI space, I'm seeking your input on a file >> naming convention for Cocoon's soon-to-be-contributed How-Tos, >> Tutorials, Examples, etc. documents. My assumption is that getting >> this right on the first go-around will help to eliminate a number of >> potential problems related to internal site linking. >> >> I started investigating this issue by reading Tim Berner-Lee's >> article on the subject (See >> http://www.w3.org/Provider/Style/URI.html). Tim makes some >> interesting recommendations for "good" and "bad" HTTP URIs. Here's a >> summary of what I find relevant to Cocoon: >> >> BAD: subject/topic (e.g. install, markup, action) >> REASON: too subj¡º??to varying interpretations, likely to change in >> meaning over time, need to reuse in the future >> >> BAD: extension (e.g. .html, .xml, .pl) >> REASON: delivery mechanisms will change >> >> BAD: author's name >> REASON: authorship may change over time, multiple authors >> >> GOOD: dates (e.g. 020430) >> REASON: The date when the URI is issued will not change. Helps to >> separate requests which use a new system from those which use an old >> system. >> >> Following these guidelines, we might use some variant of: >> www.apache.org/cocoon/faqs/02050308 >> www.apache.org/cocoon/howtos/02060315 >> >> Questions >> 1. Is this overkill for the needs of projects like Cocoon, given the >> short life of documents tied to software release cycle? Is it simply >> a matter of usability vs. longevity concerns? Tim states that it is >> "the duty of a Webmaster to allocate URIs which [he/she] will be able >> to stand by in 2 years, in 20 years, in 200 years." Do you agree with >> that? Jakob Nielson's article on a similar subject >> (http://www.useit.com/alertbox/990321.html) projects the remaining >> useful lifetime of any domain to be a mere ten years. Do we really >> need to be concerned beyond the lifetime of a particular software >> release, particularly with time-sensitive docs like FAQs, How-Tos, etc.? >> >> 2. I assume we need to continue the use of extensions for static site >> versions deployed in environments which lack clever Apache- or >> Cocoon-based mapping mechanisms. >> >> 3. Numbers in URIs remain cryptic and uninviting to me. Perhaps I'm >> hopelessly corrupt from years of bad habits, but I *like* topics in >> filenames, for example: >> www.apache.org/cocoon/faqs/config_jboss.html >> www.apache.org/cocoon/howtos/develop_source.html >> >> However, this approach won't work so well with docs having similar >> topics. And my dream is that we will have *100s* of docs to manage. >> >> So my current thinking is to assume that a request like: >> www.apache.org/cocoon/howtos/02050312.html >> will map to a file named >> 02050312.xml >> with a file naming convention based on >> <two-digit year><two-digit month><two-digit day><two-digit hour>.xml >> stored in >> src/documentation/xdocs/howtos >> >> The above assumes these contributions will be included in >> documentation that appears on Cocoon's web site. Do you agree? >> >> Comments? >> >> Diana >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, email: [EMAIL PROTECTED] >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
