cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <...@koberg.com>
Subject Re: file naming convention
Date Fri, 03 May 2002 12:03:00 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message