இதன் ஆசிரியர் சர் டிம் பெர்னர்ஸ்-லீ, URIகள், URLகள், HTTP, HTML மற்றும் உலகளாவிய வலை ஆகியவற்றைக் கண்டுபிடித்தவர் மற்றும் W3C இன் தற்போதைய தலைவர் ஆவார். இந்தக் கட்டுரை 1998 இல் எழுதப்பட்டது.

எந்த URI "அருமையானது" என்று கருதப்படுகிறது?
மாறாத ஒன்று.
URIகள் எவ்வாறு மாறுகின்றன?
URIகள் மாறாது: மக்கள் அவற்றை மாற்றுகிறார்கள்.

கோட்பாட்டளவில், மக்கள் URIகளை மாற்றுவதற்கு (அல்லது துணை ஆவணங்களை நிறுத்துவதற்கு) எந்த காரணமும் இல்லை, ஆனால் நடைமுறையில் அவை மில்லியன் கணக்கானவை.

கோட்பாட்டளவில், ஒரு டொமைன் பெயர் இடத்தின் பெயரளவு உரிமையாளர் உண்மையில் டொமைன் பெயர் இடத்தை சொந்தமாகக் கொண்டுள்ளார், எனவே, அதனுள் உள்ள அனைத்து URI களும். திவால்நிலை இல்லாததால், டொமைன் பெயர் உரிமையாளர் அந்தப் பெயரைத் தக்கவைத்துக்கொள்வதை எதுவும் தடுக்கவில்லை. மேலும், கோட்பாட்டளவில், உங்கள் டொமைன் பெயரின் கீழ் உள்ள URI இடம் முற்றிலும் உங்கள் கட்டுப்பாட்டில் உள்ளது, எனவே நீங்கள் விரும்பும் அளவுக்கு அதை நிலையானதாக மாற்றலாம். ஒரு ஆவணம் இணையத்திலிருந்து மறைந்து போவதற்கு ஒரே சரியான காரணம், டொமைன் பெயரைச் சொந்தமாக வைத்திருந்த நிறுவனம் வணிகத்திலிருந்து வெளியேறிவிட்டது அல்லது அதன் சேவையகத்தை இனி பராமரிக்க முடியாது என்பதுதான். அப்படியானால் ஏன் இவ்வளவு காணாமல் போன இணைப்புகள் உள்ளன? ஓரளவுக்கு, இது வெறுமனே தொலைநோக்கு பார்வையின்மை. நீங்கள் கேட்கக்கூடிய சில காரணங்கள் இங்கே:

தளத்தை மேம்படுத்துவதற்காக நாங்கள் அதை மறுசீரமைத்துள்ளோம்.

பழைய URIகள் இனி வேலை செய்யாது என்று நீங்கள் உண்மையிலேயே நினைக்கிறீர்களா? அப்படியானால், நீங்கள் மிகவும் மோசமான தேர்வை எடுத்துள்ளீர்கள். அடுத்த மறுவடிவமைப்புக்குப் பிறகு புதியவற்றை வைத்திருப்பதைப் பற்றி யோசித்துப் பாருங்கள்.

எங்களிடம் ஏராளமான விஷயங்கள் இருப்பதால், எது காலாவதியானது, எது உணர்திறன் வாய்ந்தது, எது இன்னும் பொருத்தமானது என்பதைக் கண்காணிக்க முடியாது, எனவே அதையெல்லாம் அணைப்பது நல்லது என்று நாங்கள் நினைத்தோம்.

எனக்கு அனுதாபம் மட்டுமே தெரியும். W3C ஒரு காலகட்டத்தில் ரகசியத்தன்மைக்காக காப்பகப்படுத்தப்பட்ட பொருட்களைப் பொதுவில் வெளியிடுவதற்கு முன்பு கவனமாகப் பிரித்தெடுக்க வேண்டியிருந்தது. முடிவை முன்கூட்டியே சிந்திக்க வேண்டும் - ஏற்றுக்கொள்ளக்கூடிய பார்வையாளர்கள், உருவாக்கும் தேதி மற்றும், வெறுமனே, காலாவதி தேதியை ஒவ்வொரு ஆவணத்திலும் பதிவு செய்வதை உறுதிசெய்யவும். இந்த மெட்டாடேட்டாவைப் பாதுகாக்கவும்.

சரி, கோப்புகளை நகர்த்த வேண்டியிருப்பதைக் கண்டறிந்தோம்...

இது மிகவும் பரிதாபகரமான சாக்குகளில் ஒன்றாகும். ஒரு பொருளின் URIக்கும் கோப்பு அமைப்பில் அதன் உண்மையான இருப்பிடத்திற்கும் இடையிலான உறவை நிர்வகிக்க வலை சேவையகங்கள் உங்களை அனுமதிக்கின்றன என்பதை பலர் உணரவில்லை. URI இடத்தை ஒரு சுருக்கமான, சரியாக ஒழுங்கமைக்கப்பட்ட இடமாக கற்பனை செய்து பாருங்கள். பின்னர் அதை செயல்படுத்த நீங்கள் உண்மையில் பயன்படுத்தும் எந்த யதார்த்தத்திற்கும் அதை வரைபடமாக்குங்கள். பின்னர் அதைப் பற்றி வலை சேவையகத்திடம் சொல்லுங்கள். அதைச் சரியாகச் செய்ய உங்கள் சொந்த சேவையகத்தின் ஒரு பகுதியைக் கூட எழுதலாம்.

ஜான் இனி இந்தக் கோப்பைப் பராமரிப்பதில்லை, இப்போது ஜேன் பராமரிக்கிறார்.

URI-ல ஜானின் பெயர் இருந்ததா? இல்லை, கோப்பு அவருடைய டைரக்டரியில தான் இருந்ததா? சரி, எனக்குப் புரியுது.

இதற்கு முன்பு நாங்கள் ஒரு CGI ஸ்கிரிப்டைப் பயன்படுத்தினோம், ஆனால் இப்போது நாம் ஒரு பைனரி நிரலைப் பயன்படுத்துகிறோம்.

ஸ்கிரிப்ட்களால் உருவாக்கப்படும் பக்கங்கள் "cgibin" அல்லது "cgi" டொமைனில் இருக்க வேண்டும் என்ற ஒரு பைத்தியக்காரத்தனமான யோசனை உள்ளது. இது உங்கள் வலை சேவையகத்தை நீங்கள் எவ்வாறு இயக்குகிறீர்கள் என்பதற்கான பொறிமுறையை அம்பலப்படுத்துகிறது. பொறிமுறையை மாற்றவும் (உள்ளடக்கத்தைப் பாதுகாக்கும் போது கூட), அச்சச்சோ - உங்கள் அனைத்து URI களும் மாறும்.

உதாரணமாக தேசிய அறிவியல் அறக்கட்டளையை (NSF) எடுத்துக் கொள்ளுங்கள்:

NSF ஆன்லைன் ஆவணங்கள்

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

ஆவணங்களைப் பார்க்கத் தொடங்கும் முதல் பக்கம் சில ஆண்டுகளுக்குப் பிறகு அப்படியே இருக்காது என்பது தெளிவாகிறது. cgi-bin, oldbrowse и pl — இவை அனைத்தும் இப்போது நாம் அதை எப்படிச் செய்கிறோம் என்பது பற்றிய சில தகவல்களை வழங்குகிறது. ஒரு ஆவணத்தைத் தேட நீங்கள் பக்கத்தைப் பயன்படுத்தினால், முதலில் அதே மோசமான முடிவைப் பெறுவீர்கள்:

குறியாக்கவியல் மற்றும் குறியீட்டு கோட்பாடு குறித்த பணிக்குழுவின் அறிக்கை

http://www.nsf.gov/cgi-bin/getpub?nsf9814

ஆவணத்தின் குறியீட்டுப் பக்கத்திற்கு, HTML ஆவணம் மிகவும் சிறப்பாகத் தெரிந்தாலும்:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

இங்கே, pubs/1998 தலைப்பு, பழைய 1998 ஆவண வகைப்பாடு திட்டம் நடைமுறையில் உள்ளது என்பதற்கான ஒரு நல்ல குறிப்பை எதிர்கால காப்பக சேவைக்கு வழங்கும். 2098 இல் ஆவண எண்கள் வித்தியாசமாகத் தோன்றினாலும், இந்த URI இன்னும் செல்லுபடியாகும் என்றும், அது NSF அல்லது காப்பகத்தைப் பராமரிக்கும் வேறு எந்த அமைப்பையும் பாதிக்காது என்றும் என்னால் கற்பனை செய்ய முடிகிறது.

URLகள் நிரந்தரமாக இருக்க வேண்டும் என்று நான் நினைக்கவில்லை - URNகள் இருந்தன.

இது URN விவாதத்தின் மோசமான பக்க விளைவுகளில் ஒன்றாக இருக்கலாம். சிலர், தொடர்ந்து பெயர்வெளிகளைப் பற்றிய ஆராய்ச்சி, தொங்கும் குறிப்புகளைப் பற்றி அலட்சியமாக இருக்க அனுமதிக்கிறது என்று நினைக்கிறார்கள், ஏனெனில் "URNகள் அதையெல்லாம் சரிசெய்யும்." நீங்கள் அந்த நபர்களில் ஒருவராக இருந்தால், நான் உங்களை ஏமாற்றுகிறேன்.

நான் பார்த்த பெரும்பாலான URN திட்டங்கள், தேதி மற்றும் உங்கள் விருப்பப்படி ஒரு சரம் அல்லது உங்கள் விருப்பப்படி ஒரு சரம் கொண்ட ஒரு அதிகார அடையாளங்காட்டியைப் போல இருக்கும். இது HTTP URIகளைப் போலவே இருக்கும். வேறு வார்த்தைகளில் கூறுவதானால், உங்கள் நிறுவனம் நீண்டகால URNகளை உருவாக்க முடியும் என்று நீங்கள் நினைத்தால், உங்கள் HTTP URIகளுக்கு அவற்றைப் பயன்படுத்துவதன் மூலம் அதை இப்போது நிரூபிக்கவும். HTTP-யில் உங்கள் URI நிலையற்றதாக மாற்றும் எதுவும் இல்லை. உங்கள் நிறுவனம் மட்டுமே. ஒரு ஆவணத்தின் URN-ஐ தற்போதைய கோப்பு பெயருடன் வரைபடமாக்கும் ஒரு தரவுத்தளத்தை உருவாக்கவும், மேலும் கோப்புகளை மீட்டெடுக்க வலை சேவையகம் அதைப் பயன்படுத்த அனுமதிக்கவும்.

நீங்கள் இந்த நிலையை அடைந்துவிட்டீர்கள் என்றால், சில மென்பொருளை உருவாக்க உங்களுக்கு நேரம், பணம் மற்றும் தொடர்புகள் இல்லையென்றால், நீங்கள் பின்வரும் சாக்குப்போக்கைச் சொல்லலாம்:

நாங்கள் விரும்பினோம், ஆனால் எங்களிடம் சரியான கருவிகள் இல்லை.

இப்போது, நான் இதை ஒத்துக்கொள்கிறேன். நான் முழுமையாக ஒப்புக்கொள்கிறேன். நீங்கள் செய்ய வேண்டியது என்னவென்றால், வலை சேவையகம் ஒரு நிலையான URI ஐ உடனடியாக செயலாக்க கட்டாயப்படுத்தி, உங்கள் தற்போதைய, பைத்தியக்கார கோப்பு முறைமையில் தற்போது சேமிக்கப்பட்டுள்ள இடத்தில் கோப்பை திருப்பி அனுப்ப வேண்டும். நீங்கள் அனைத்து URI களையும் கோப்பில் ஒரு சரிபார்ப்பாக சேமித்து, தரவுத்தளத்தை தொடர்ந்து புதுப்பித்த நிலையில் வைத்திருக்க விரும்புகிறீர்கள். ஒரே ஆவணத்தின் வெவ்வேறு பதிப்புகள் மற்றும் மொழிபெயர்ப்புகளுக்கு இடையிலான உறவுகளைப் பாதுகாக்க விரும்புகிறீர்கள், மேலும் சீரற்ற பிழை காரணமாக கோப்பு சிதைவிலிருந்து பாதுகாக்க ஒரு சுயாதீனமான செக்சம் பதிவையும் பராமரிக்க விரும்புகிறீர்கள். மேலும் வலை சேவையகங்கள் இந்த அம்சங்களை பெட்டியிலிருந்து வெளியே கொண்டு வருவதில்லை. நீங்கள் ஒரு புதிய ஆவணத்தை உருவாக்க விரும்பும் போது, உங்கள் ஆசிரியர் உங்களிடம் ஒரு URI ஐக் குறிப்பிடச் சொல்கிறார்.

URI-ஐ மாற்றாமல் URI இடத்தில் உரிமையை மாற்றும் திறன், ஆவண அணுகல், காப்பக நிலை பாதுகாப்பு போன்றவற்றை நீங்கள் கொண்டிருக்க வேண்டும்.

இது மிகவும் மோசமானது. ஆனால் நாங்கள் அதை சரிசெய்வோம். W3C இல், பதிப்புகளைக் கண்காணிக்க நாங்கள் Jigedit (எடிட்டிங் செய்வதற்கான ஒரு Jigsaw சர்வர்) ஐப் பயன்படுத்துகிறோம், மேலும் ஆவண உருவாக்க ஸ்கிரிப்ட்களை நாங்கள் பரிசோதித்து வருகிறோம். நீங்கள் கருவிகள், சேவையகங்கள் மற்றும் கிளையண்டுகளை உருவாக்கினால், தயவுசெய்து இந்த சிக்கலில் கவனம் செலுத்துங்கள்!

இந்த நியாயப்படுத்தல் பல W3C பக்கங்களுக்கும் பொருந்தும், இதில் இதுவும் அடங்கும்: எனவே நான் சொல்வது போல் செய்யுங்கள், நான் செய்வது போல் அல்ல.

இது ஏன் என்னை தொந்தரவு செய்ய வேண்டும்?

உங்கள் சர்வரில் URI-ஐ மாற்றும்போது, பழைய URI-க்கு யார் இணைப்பார்கள் என்பதை நீங்கள் ஒருபோதும் முழுமையாக உறுதியாகச் சொல்ல முடியாது. இவை வழக்கமான வலைப்பக்கங்களிலிருந்து வரும் இணைப்புகளாகவோ, உங்கள் பக்கத்திற்கான புக்மார்க்குகளாகவோ அல்லது நண்பருக்கு அனுப்பப்பட்ட கடிதத்தின் ஓரங்களில் URI எழுதப்பட்டிருக்கலாம்.

யாராவது ஒரு இணைப்பைக் கிளிக் செய்து அது உடைந்துவிட்டால், அவர்கள் பொதுவாக சர்வர் உரிமையாளர் மீதான நம்பிக்கையை இழக்கிறார்கள். தங்கள் இலக்கை அடைய முடியாமல் போனதால் அவர்கள் உணர்ச்சி ரீதியாகவும், உடல் ரீதியாகவும் ஏமாற்றமடைகிறார்கள்.

பலர் தொடர்ந்து இணைப்புகள் உடைந்ததாக புகார் கூறுகின்றனர், மேலும் சேதம் வெளிப்படையாக இருக்கும் என்று நம்புகிறேன். ஆவணம் காணாமல் போன சர்வரின் பராமரிப்பாளருக்கு ஏற்பட்ட நற்பெயருக்கு ஏற்பட்ட சேதமும் வெளிப்படையாக இருக்கும் என்று நம்புகிறேன்.

எனவே நான் என்ன செய்ய வேண்டும்? URI வடிவமைப்பு

இரண்டு வருடங்கள், 20 வருடங்கள் அல்லது 200 வருடங்களில் பயன்படுத்தக்கூடிய URIகளை ஒதுக்குவது வலை நிர்வாகியின் பொறுப்பாகும். இதற்கு சிந்தனை, அமைப்பு மற்றும் உறுதிப்பாடு தேவை.

URI-களில் ஏதேனும் தகவல் மாறும்போது அவையும் மாறுகின்றன. நீங்கள் அவற்றை எவ்வாறு வடிவமைக்கிறீர்கள் என்பது மிக முக்கியம். (என்ன, URI வடிவமைப்பு? நான் URI-களை வடிவமைக்க வேண்டுமா? ஆம், நீங்கள் அதைப் பற்றி சிந்திக்க வேண்டும்.) வடிவமைப்பு என்பது அடிப்படையில் URI-க்கு வெளியே எந்த தகவலையும் விட்டுவிடுவதாகும்.

ஆவண உருவாக்க தேதி - URI வழங்கும் தேதி - ஒருபோதும் மாறாத ஒன்று. புதிய அமைப்பைப் பயன்படுத்தும் கோரிக்கைகளை பழைய அமைப்பைப் பயன்படுத்துபவர்களிடமிருந்து பிரிக்க இது மிகவும் பயனுள்ளதாக இருக்கும். இது ஒரு URI க்கு ஒரு நல்ல தொடக்கப் புள்ளியாகும். ஒரு ஆவணத்தில் ஒரு தேதி முத்திரையிடப்பட்டிருந்தால், ஆவணம் எதிர்காலத்தில் பொருத்தமானதாக இருந்தாலும் கூட, அது ஒரு நல்ல தொடக்கமாகும்.

ஒரே விதிவிலக்கு, ஒரு முழு நிறுவனத்திற்கோ அல்லது அதன் பெரும்பகுதிக்கோ, வேண்டுமென்றே "சமீபத்திய" பதிப்பாக இருக்கும் ஒரு பக்கம் மட்டுமே.

http://www.pathfinder.com/money/moneydaily/latest/

இது Money இதழில் வரும் கடைசி Money Daily பத்தி. இந்த URI-க்கு தேதி தேவையில்லை என்பதற்கான முக்கிய காரணம், பத்திரிகையை விட அதிகமாக இருக்கும் URI-ஐ பராமரிக்க எந்த காரணமும் இல்லை. Money Daily என்ற கருத்து Money மறைந்து போகும்போது மறைந்துவிடும். உள்ளடக்கத்துடன் இணைக்க விரும்பினால், காப்பகங்களில் அதைத் தனித்தனியாக இணைக்க வேண்டும்:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(நன்றாக இருக்கிறது. pathfinder.com இருக்கும் வரை "பணம்" என்பது ஒரே பொருளையே குறிக்கும் என்று கருதுகிறது. "98" என்ற நகல் மற்றும் தேவையற்ற ".html" உள்ளது, ஆனால் மற்றபடி வலுவான URI போல் தெரிகிறது.

எதை ஒதுக்கி வைக்க வேண்டும்?

அவ்வளவுதான்! உருவாக்கத் தேதியைத் தவிர, URI-யில் எந்தத் தகவலையும் வைப்பது ஏதோ ஒரு வகையில் சிக்கலைக் கொண்டுவருவதாகும்.

ஆசிரியரின் பெயர்புதிய பதிப்புகள் தோன்றும்போது படைப்புரிமை மாறக்கூடும். மக்கள் நிறுவனங்களை விட்டு வெளியேறி மற்றவர்களுக்கு விஷயங்களைக் கடத்துகிறார்கள்.
பொருள்இது மிகவும் கடினம். முதலில் இது எப்போதும் நன்றாகத் தெரிகிறது, ஆனால் அது ஆச்சரியப்படும் விதமாக விரைவாக மாறுகிறது. இதைப் பற்றி நான் கீழே விரிவாகப் பேசுவேன்.
நிலையை"பழையது," "வரைவு," போன்ற கோப்பகங்கள், "சமீபத்தியம்" மற்றும் "சிறந்தது" என்று குறிப்பிடாமல், எல்லா கோப்பு முறைமைகளிலும் தோன்றும். ஆவணங்களின் நிலை மாறுகிறது - இல்லையெனில், வரைவுகளை உருவாக்குவதில் எந்த அர்த்தமும் இருக்காது. ஒரு ஆவணத்தின் சமீபத்திய பதிப்பிற்கு, அதன் நிலை எதுவாக இருந்தாலும், நிலையான அடையாளங்காட்டி தேவைப்படுகிறது. நிலையை பெயரிலிருந்து தனித்தனியாக வைத்திருங்கள்.
அணுகல்W3C-யில், தளத்தை ஊழியர்கள், உறுப்பினர்கள் மற்றும் பொதுமக்களுக்காகப் பிரிவுகளாகப் பிரித்துள்ளோம். இது நன்றாகத் தெரிகிறது, ஆனால் ஆவணங்கள் ஊழியர்களின் குழு யோசனைகளாகத் தொடங்கி, உறுப்பினர்களுடன் விவாதிக்கப்பட்டு, பின்னர் பொதுவில் கிடைக்கும். ஒவ்வொரு முறையும் ஒரு ஆவணம் பரந்த விவாதத்திற்காகத் திறக்கப்படும்போது, அதற்கான பழைய இணைப்புகள் அனைத்தும் உடைந்துவிட்டால் அது மிகவும் அவமானகரமானது! இப்போது நாம் ஒரு எளிய தேதிக் குறியீட்டிற்கு நகர்கிறோம்.
கோப்பு நீட்டிப்பு. இது மிகவும் பொதுவான நிகழ்வு. "cgi", ".html" கூட எதிர்காலத்தில் மாறும். நீங்கள் 20 ஆண்டுகளில் இந்தப் பக்கத்திற்கு HTML ஐப் பயன்படுத்தாமல் இருக்கலாம், ஆனால் இன்றைய இணைப்புகள் இன்னும் வேலை செய்யும். W3C தளத்தில் உள்ள நியமன இணைப்புகள் () நீட்டிப்பைப் பயன்படுத்துவதில்லை.அது எப்படி செய்யப்படுகிறது?).
மென்பொருள் வழிமுறைகள்"நாம் பயன்படுத்தும் மென்பொருளைப் பாருங்கள்" என்று கத்தும் "cgi," "exec," மற்றும் URI-யில் உள்ள பிற சொற்களைத் தேடுங்கள். யாராவது தங்கள் முழு வாழ்க்கையையும் Perl CGI ஸ்கிரிப்டுகளுக்கு அர்ப்பணிக்க விரும்புகிறீர்களா? இல்லையா? பின்னர் .pl நீட்டிப்பை அகற்றவும். வழிமுறைகளுக்கு சேவையகத்தின் கையேட்டைப் படியுங்கள்.
வட்டின் பெயர். வாங்க! ஆனா நான் அப்படிப்பட்ட விஷயங்களைப் பார்த்திருக்கேன்.

எனவே எங்கள் தளத்திலிருந்து சிறந்த உதாரணம் வெறும்

http://www.w3.org/1998/12/01/chairs

…W3C தலைவர்களின் கூட்டத்தின் நிமிடங்கள் குறித்த அறிக்கை.

தலைப்புகள் மற்றும் தலைப்புகளின் வகைப்பாடு

இந்த ஆபத்தைப் பற்றி நான் இன்னும் விரிவாகப் பேசுவேன், ஏனெனில் இது தவிர்க்க மிகவும் கடினமான விஷயங்களில் ஒன்றாகும். பொதுவாக, உங்கள் ஆவணங்களை அவை செய்யும் வேலையின் அடிப்படையில் வகைப்படுத்தும்போது தலைப்புகள் URI களில் சேர்க்கப்படும். ஆனால் இந்த முறிவு காலப்போக்கில் மாறும். பகுதிகளின் பெயர்கள் மாறும். W3C இல், பிரிவின் உண்மையான உள்ளடக்கத்தைப் பிரதிபலிக்கும் வகையில், MarkUP ஐ Markup ஆகவும், பின்னர் HTML ஆகவும் மாற்ற விரும்பினோம். மேலும், பெரும்பாலும் ஒரு தட்டையான பெயர்வெளி இருக்கும். 100 ஆண்டுகளில், நீங்கள் எதையும் மீண்டும் பயன்படுத்த விரும்ப மாட்டீர்கள் என்பதில் உறுதியாக இருக்கிறீர்களா? எங்கள் குறுகிய ஆயுட்காலத்தில், "வரலாறு" மற்றும் "ஸ்டைல்ஷீட்களை" மீண்டும் பயன்படுத்த ஏற்கனவே விரும்பினோம், எடுத்துக்காட்டாக.

இது ஒரு வலைத்தளத்தை ஒழுங்கமைக்க ஒரு கவர்ச்சிகரமான வழியாகும் - மேலும் முழு வலை உட்பட எதையும் ஒழுங்கமைக்க உண்மையிலேயே கவர்ச்சிகரமான வழியாகும். இது ஒரு சிறந்த நடுத்தர கால தீர்வாகும், ஆனால் நீண்ட காலத்திற்கு இது கடுமையான குறைபாடுகளைக் கொண்டுள்ளது.

காரணத்தின் ஒரு பகுதி அர்த்தத்தின் தத்துவத்தில் உள்ளது. மொழியில் உள்ள ஒவ்வொரு வார்த்தையும் தொகுப்பின் சாத்தியமான பொருளாகும், மேலும் ஒவ்வொரு நபருக்கும் அதன் அர்த்தம் குறித்து வெவ்வேறு கருத்துக்கள் இருக்கலாம். நிறுவனங்களுக்கு இடையிலான உறவுகள் ஒரு மரத்தை விட வலையைப் போலவே இருப்பதால், வலையை ஏற்றுக்கொள்பவர்கள் கூட மரத்தின் வேறுபட்ட பிரதிநிதித்துவத்தைத் தேர்வு செய்யலாம். ஒரு பொதுவான தீர்வாக படிநிலை வகைப்பாட்டின் ஆபத்துகள் பற்றிய எனது (பெரும்பாலும் மீண்டும் மீண்டும்) பொதுவான அவதானிப்புகள் இவை.

அடிப்படையில், நீங்கள் ஒரு URI-யில் ஒரு தலைப்புப் பெயரைப் பயன்படுத்தும்போது, நீங்கள் ஒரு குறிப்பிட்ட வகைப்பாட்டிற்கு உங்களை அர்ப்பணித்துக் கொள்கிறீர்கள். எதிர்காலத்தில் நீங்கள் வேறு ஒரு விருப்பத்தைத் தேர்வுசெய்யலாம், பின்னர் URI ஊழலுக்கு ஆளாக நேரிடும்.

URI இன் ஒரு பகுதியாகப் பொருள் பகுதியைப் பயன்படுத்துவதற்கான காரணம், URI இடத்தின் துணைப் பிரிவுகளுக்கான பொறுப்பு பொதுவாக ஒப்படைக்கப்படுகிறது, பின்னர் அந்த துணைப் பகுதிக்கு பொறுப்பான நிறுவன அலகின் பெயர் - பிரிவு, குழு அல்லது வேறு எதுவாக இருந்தாலும் - உங்களுக்குத் தேவை. இது URI ஐ நிறுவன கட்டமைப்பிற்கு நங்கூரமிடுகிறது. URI மேலும் இடதுபுறமாக இருக்கும்போது, ஒரு தேதியால் பாதுகாக்கப்படும்போது மட்டுமே இது பொதுவாக பாதுகாப்பானது: 1998/pics என்பது உங்கள் சேவையகத்திற்கு "1998 இல் படங்கள் என்று நாங்கள் என்ன சொன்னோம்" என்று அர்த்தப்படுத்தலாம், "1998 இல் நாங்கள் இப்போது படங்கள் என்று அழைப்பதன் மூலம் நாங்கள் என்ன செய்தோம்" என்று அர்த்தப்படுத்துவதில்லை.

டொமைன் பெயரை மறந்துவிடாதீர்கள்.

இது URI இல் உள்ள பாதைக்கு மட்டுமல்ல, சேவையக பெயருக்கும் பொருந்தும் என்பதை நினைவில் கொள்ளுங்கள். வெவ்வேறு விஷயங்களுக்கு தனித்தனி சேவையகங்கள் இருந்தால், பல, பல இணைப்புகளை உடைக்காமல் இந்தப் பிரிப்பை மாற்றுவது சாத்தியமற்றது என்பதை நினைவில் கொள்ளுங்கள். சில உன்னதமான "இன்று நாம் பயன்படுத்தும் மென்பொருளைப் பாருங்கள்" தவறுகள் "cgi.pathfinder.com," "secure," மற்றும் "lists.w3.org" போன்ற டொமைன் பெயர்கள். இவை சர்வர் நிர்வாகத்தை எளிதாக்க வடிவமைக்கப்பட்டுள்ளன. ஒரு டொமைன் உங்கள் நிறுவனத்திற்குள் ஒரு துறையை பிரதிநிதித்துவப்படுத்துகிறதா, ஒரு ஆவண நிலை, ஒரு அணுகல் நிலை அல்லது ஒரு பாதுகாப்பு நிலையை பிரதிநிதித்துவப்படுத்துகிறதா என்பதைப் பொருட்படுத்தாமல், பல ஆவண வகைகளுக்கு ஒன்றுக்கு மேற்பட்ட டொமைன் பெயர்களைப் பயன்படுத்துவதற்கு முன்பு மிகவும் கவனமாக இருங்கள். திசைதிருப்பல் மற்றும் ப்ராக்ஸியைப் பயன்படுத்தி ஒரு புலப்படும் வலை சேவையகத்திற்குள் பல வலை சேவையகங்களை மறைக்க முடியும் என்பதை நினைவில் கொள்ளுங்கள்.

ஓ, உங்கள் டொமைன் பெயரைப் பற்றி யோசித்துப் பாருங்கள். உங்கள் தயாரிப்பு வரிசையை மாற்றி சோப்பு தயாரிப்பதை நிறுத்திய பிறகு, நீங்கள் soap.com உடன் இணைக்கப்பட விரும்ப மாட்டீர்கள் (தற்போது soap.com வைத்திருப்பவர்களுக்கு மன்னிப்பு).

முடிவுக்கு

2, 20, 200, அல்லது 2000 ஆண்டுகளுக்கு URI-களைப் பராமரிப்பது அவ்வளவு எளிதானது அல்ல என்பது தெளிவாகத் தெரிகிறது. இருப்பினும், இணையம் முழுவதும், வலை நிர்வாகிகள் எதிர்காலத்தில் இந்தப் பணியைத் தங்களுக்கு உண்மையிலேயே கடினமாக்கும் முடிவுகளை எடுக்கிறார்கள். பெரும்பாலும், இதற்குக் காரணம், விஷயங்கள் மாறும்போது இணைப்புகளுக்கு என்ன நடக்கும் என்பதைக் கருத்தில் கொள்ளாமல், தற்போதைய தருணத்தில் மட்டுமே சிறந்த தளத்தை வழங்க வடிவமைக்கப்பட்ட கருவிகளைப் பயன்படுத்துவதே ஆகும். இருப்பினும், விஷயம் என்னவென்றால், அதிகமாக, அதிகமாக மாறலாம், மேலும் உங்கள் URI-கள் அப்படியே இருக்க முடியும், அப்படியே இருக்க வேண்டும். நீங்கள் அவற்றை எவ்வாறு உருவாக்குகிறீர்கள் என்பதைப் பற்றி கவனமாகச் சிந்தித்தால் மட்டுமே இது சாத்தியமாகும்.

மேலும் காண்க:

இதே தலைப்பில் ஜேக்கப் நீல்சனின் கண்டனம்

சப்ளிமெண்ட்ஸ்

கோப்பு நீட்டிப்புகளை எவ்வாறு அகற்றுவது...

... தற்போதைய கோப்பு அடிப்படையிலான வலை சேவையகத்தில் உள்ள ஒரு URI இலிருந்து?

உதாரணமாக, நீங்கள் Apache ஐப் பயன்படுத்துகிறீர்கள் என்றால், உள்ளடக்கத்தை பேச்சுவார்த்தை நடத்த அதை உள்ளமைக்கலாம். நீங்கள் கோப்பு நீட்டிப்பை (எ.கா., .png) கோப்பில் சேமிக்கிறீர்கள் (எ.கா., என் நாய்.png), ஆனால் அது இல்லாமலேயே நீங்கள் ஒரு வலை வளத்துடன் இணைக்க முடியும். பின்னர் அப்பாச்சி அந்த பெயர் மற்றும் எந்த நீட்டிப்பையும் கொண்ட அனைத்து கோப்புகளுக்கான கோப்பகத்தையும் சரிபார்க்கிறது, மேலும் ஒரு தொகுப்பிலிருந்து (எடுத்துக்காட்டாக, GIF மற்றும் PNG) சிறந்த ஒன்றைத் தேர்வுசெய்யலாம். மேலும் வெவ்வேறு கோப்பு வகைகளை வெவ்வேறு கோப்பகங்களில் வைக்க வேண்டிய அவசியமில்லை; உண்மையில், நீங்கள் செய்தால் உள்ளடக்க பேச்சுவார்த்தை வேலை செய்யாது.

உள்ளடக்க பேச்சுவார்த்தைக்காக உங்கள் சேவையகத்தை உள்ளமைக்கவும்.
நீட்டிப்புகள் இல்லாமல் எப்போதும் URIகளுடன் இணைக்கவும்.

நீட்டிப்புகளுடன் கூடிய இணைப்புகள் இன்னும் செயல்படும், ஆனால் உங்கள் சேவையகம் தற்போதைய மற்றும் எதிர்கால வடிவங்களிலிருந்து சிறந்த வடிவமைப்பைத் தேர்ந்தெடுப்பதைத் தடுக்கும்.

(உண்மையில், mydog, mydog.png и mydog.gif - செல்லுபடியாகும் வலை வளங்கள், mydog — என்பது உலகளாவிய உள்ளடக்க வகையின் ஒரு வளமாகும், மேலும் mydog.png и mydog.gif — ஒரு குறிப்பிட்ட உள்ளடக்க வகையின் வளங்கள்).

நிச்சயமாக, நீங்கள் உங்கள் சொந்த வலை சேவையகத்தை எழுதுகிறீர்கள் என்றால், வரம்பற்ற தரவுத்தள வளர்ச்சி குறித்து எச்சரிக்கையாக இருந்தாலும், நிலையான அடையாளங்காட்டிகளை அவற்றின் தற்போதைய வடிவத்திற்கு வரைபடமாக்க ஒரு தரவுத்தளத்தைப் பயன்படுத்துவது நல்லது.

ஹால் ஆஃப் ஷேம் - கதை 1: சேனல் 7

1999 முழுவதும், பனிப்பொழிவு காரணமாக பள்ளிகள் மூடப்பட்டதை நான் பக்கத்தில் கண்காணித்தேன். http://www.whdh.com/stormforce/closings.shtmlடிவி திரையின் அடிப்பகுதியில் தகவல் தோன்றும் வரை என்னால் காத்திருக்க முடியவில்லை! எனது முகப்புப் பக்கத்திலிருந்து அதை இணைத்தேன். 2000 ஆம் ஆண்டின் முதல் பெரிய பனிப்புயல் தாக்கியது, நான் பக்கத்தைப் பார்த்தேன். அது கூறியது:

— இதுவரை.
தற்போது மூடல்கள் எதுவும் இல்லை. வானிலை எச்சரிக்கைகள் வழங்கப்பட்டால் தயவுசெய்து திரும்பி வாருங்கள்.

அது இருக்க முடியாது, அது ஒரு வலுவான புயல். தேதி இல்லாதது வேடிக்கையாக இருக்கிறது. ஆனால் நீங்கள் தளத்தின் பிரதான பக்கத்திற்குச் சென்றால், "மூடப்பட்ட பள்ளிகள்" என்று பெயரிடப்பட்ட ஒரு பெரிய பொத்தான் உள்ளது, அது ஒரு பக்கத்திற்கு வழிவகுக்கிறது. http://www.whdh.com/stormforce/ மூடப்பட்ட பள்ளிகளின் நீண்ட பட்டியலுடன்.

பட்டியலைப் பெறுவதற்கான அமைப்பை அவர்கள் மாற்றியிருக்கலாம் - ஆனால் அவர்கள் URI ஐ மாற்ற வேண்டிய அவசியமில்லை.

ஹால் ஆஃப் ஷேம் - கதை 2: மைக்ரோசாஃப்ட் நெட் மீட்டிங்

இணையத்தை நாம் சார்ந்திருப்பது அதிகரித்து வருவதால், ஒரு புத்திசாலித்தனமான யோசனை வெளிப்பட்டுள்ளது: உற்பத்தியாளரின் வலைத்தளத்திற்கான இணைப்புகளை பயன்பாடுகளில் உட்பொதித்தல். இது அடிக்கடி பயன்படுத்தப்பட்டு பெரிதும் தவறாகப் பயன்படுத்தப்படுகிறது, ஆனால் நீங்கள் URL ஐ மாற்ற முடியாது. மறுநாள், நான் Help/Microsoft on the Web/Free stuff இன் கீழ் Microsoft Netmeeting 2 கிளையண்டிலிருந்து ஒரு இணைப்பை முயற்சித்தேன், அப்போது 404 பிழை ஏற்பட்டது - ஒரு சர்வர் பதில் கிடைக்கவில்லை. ஒருவேளை அவர்கள் இப்போது அதை சரிசெய்திருக்கலாம்...

வரலாற்று குறிப்பு: 20 ஆம் நூற்றாண்டின் பிற்பகுதியில், இது எழுதப்பட்டபோது, "cool" என்பது குறிப்பாக இளைஞர்களிடையே, நாகரீகம், தரம் அல்லது பொருத்தத்தைக் குறிக்கும் ஒரு அங்கீகாரச் சொல்லாக இருந்தது. ஒரு வழியைக் கண்டுபிடிக்கும் அவசரத்தில், URI பெரும்பாலும் பயன்பாடு அல்லது நீண்ட ஆயுளை விட "coolness" ஆல் இயக்கப்படுகிறது. இந்தக் குறிப்பு குளிர்ச்சிக்கான தேடலுக்குப் பின்னால் உள்ள ஆற்றலைத் திருப்பிவிடும் முயற்சியாகும்.

ஆதாரம்: www.habr.com