linkbat-devel Mailing List for Linux Knowledge Base and Tutorial (Page 2)
Brought to you by:
jimmo
Menu
▾
▴
linkbat-devel — Discussion of development related issues
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(47) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James M. <lin...@ji...> - 2002-11-30 20:04:00
|
Hi All! I have been thinking that it might be useful to have sub-types for the Content KUs. For example, you could have: fact, misconception, problem. A fact, is the standard Content KU and simply makes a statement. A misconception is also a statement of fact (for the most part) but the goal is to dispell a common misconception or misunderstanding. A problem is something can cause "problems". I am having trouble thinking of examples of "problems", but I think somewhere along the line it might be useful. Comments? Regards, Jim -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: Shanta M. <sh...@fo...> - 2002-11-30 15:55:43
|
No Not had time to work on this project. Disk quota exceeded problem deleted a few unused directories. Works now. On Sat, 2002-11-30 at 08:43, James Mohr wrote: > Hi All! > > Please review and email your comments this weekend. I would really like to > finalize the model and start working on the code. > > Shanta, have you made any changes to eXtropia pages since last weekend? I just > tried the link you privided and it eventually times out: > > http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat > > Regards, > > Jim -- Yours Truly Shanta McBain HTTP://computersystemconsulting.ca |
|
From: James M. <lin...@ji...> - 2002-11-30 15:13:20
|
Hi All! Please review and email your comments this weekend. I would really like to finalize the model and start working on the code. Shanta, have you made any changes to eXtropia pages since last weekend? I just tried the link you privided and it eventually times out: http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat Regards, Jim -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: James M. <lin...@ji...> - 2002-11-27 20:01:17
|
On Wednesday 27 November 2002 20:24, Hal F. Gottfried wrote: > How about storing the DATA in teXtML it's a native XML database From what I was able to find it looks propriatary/commercial and Windows-only. regards, jim -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: Hal F. G. <hgo...@pr...> - 2002-11-27 19:35:26
|
How about storing the DATA in teXtML it's a native XML database -----Original Message----- From: lin...@li... [mailto:lin...@li...] On Behalf Of James Mohr Sent: Wednesday, November 27, 2002 3:30 PM To: lin...@li... Subject: [Linkbat-devel] DB or not DB, that is the question Hi All! Well, I have been thinking about this and think that we will still need to store the data is some way for dynamic access. One place is for the questions and answers. We could *theoretically* create these pages in advance, but would still need a method to access them randomly, plus be able to select questions based on the current topic. So I see very little difference in reading a DB to create the questions dynamically as compared to creating some "artificial" database to store the pre-made pages so that we can access them randomly. Also, an eventual goal is to have a search mechanism that not only goes through the tutorial pages, but also through the KUs. So I think that a storage and index mechanisms is unavoidable, so I think that we need to go forward with the idea the KUs will be imported into a database. However, I still think that a lot of the pages **could** be created on the fly, such as the glossary terms and MoreInfo. Anyone got any comments about all this? Regards, jim -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info ------------------------------------------------------- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en _______________________________________________ Linkbat-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linkbat-devel --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002 |
|
From: James M. <lin...@ji...> - 2002-11-27 19:00:38
|
Hi All! Well, I have been thinking about this and think that we will still need to store the data is some way for dynamic access. One place is for the questions and answers. We could *theoretically* create these pages in advance, but would still need a method to access them randomly, plus be able to select questions based on the current topic. So I see very little difference in reading a DB to create the questions dynamically as compared to creating some "artificial" database to store the pre-made pages so that we can access them randomly. Also, an eventual goal is to have a search mechanism that not only goes through the tutorial pages, but also through the KUs. So I think that a storage and index mechanisms is unavoidable, so I think that we need to go forward with the idea the KUs will be imported into a database. However, I still think that a lot of the pages **could** be created on the fly, such as the glossary terms and MoreInfo. Anyone got any comments about all this? Regards, jim -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: Hal F. G. <hgo...@pr...> - 2002-11-26 21:07:39
|
Nope James, sounds good to me, I think you covered everything. I'm also reviewing all of the other mails that where sent to see if there is anything that needs my attention. BTW: I am Hal, an XML instructor with a IT training company. -----Original Message----- From: lin...@li... [mailto:lin...@li...] On Behalf Of James Mohr Sent: Tuesday, November 26, 2002 5:20 PM To: lin...@li... Subject: Re: [Linkbat-devel] Linkbat Dataflow Hi All! Sorry, I'm doing it again. I forget to keep a discussion with Hal Gottfried on the list. Hal and I have been discussing the XML implementation in the data files and he has said he can write the DTD when we get the model finalized. So, to sum up our discussions, we both seem to agree that accessing the data will be speeded up by a conversion to either CSV or a database. Hal made a couple of comments that me think that we could actually create a lot of the pages in advanced and not at run-time, thus speeding up things even more so. Since the data is static, once copied to the server, there is no reason to parse most of it on the fly. For example: - Content pages. They are parsed at runtime to create the links and popups for the glossary, links to other tutorial pages, etc. - Glossary pages. Created completely at run time and include links to other glossary terms and pages that references this glossary term. - MoreInfo pages. Created completely at run time and include links to other sites. I see no reason why these cannot be created in advance. We would just need to make sure that whatever display mechanism we use knows how to load the correct page. To me that's a heck of a lot easier than creating the pages on the fly. This brings up a **huge** question, which is particularly of interest to Shanta. If we create all of the pages in advance, there does to seem to be a need a pressing need for an SQL Database. The reason for it was the efficiency during data access. So, the question is whether we gain anything by creating one. In my mind, it doesn't matter if the pre-processing takes longer as it would with an SQL DB. How do the rest of you see this? Hal suggested including the PageID as an attriube to the <Type> tag and we were both thinking that we could the sub-type as an attribute of the <Type> tag. <Type id="45">Page</Type> <Type url="http://www.linux.org">MoreInfo</Type> <Type subtype="verb">Glossary</Type> This makes sense as the sub-type is a characteristic of the type and not the actual KU. For the questions, we have the issue of an empty <Reason> tag as a reminder to add something. It might be simpler to have the text of the Reason an attribute of the tag, like this: <reason answer="why this is correct" /> If it's empty we don't carry arounf the extra baggage. Did I forget anything important, Hal? Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info ------------------------------------------------------- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en _______________________________________________ Linkbat-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linkbat-devel --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002 |
|
From: James M. <lin...@ji...> - 2002-11-26 20:51:02
|
Hi All! Sorry, I'm doing it again. I forget to keep a discussion with Hal Gottfried on the list. Hal and I have been discussing the XML implementation in the data files and he has said he can write the DTD when we get the model finalized. So, to sum up our discussions, we both seem to agree that accessing the data will be speeded up by a conversion to either CSV or a database. Hal made a couple of comments that me think that we could actually create a lot of the pages in advanced and not at run-time, thus speeding up things even more so. Since the data is static, once copied to the server, there is no reason to parse most of it on the fly. For example: - Content pages. They are parsed at runtime to create the links and popups for the glossary, links to other tutorial pages, etc. - Glossary pages. Created completely at run time and include links to other glossary terms and pages that references this glossary term. - MoreInfo pages. Created completely at run time and include links to other sites. I see no reason why these cannot be created in advance. We would just need to make sure that whatever display mechanism we use knows how to load the correct page. To me that's a heck of a lot easier than creating the pages on the fly. This brings up a **huge** question, which is particularly of interest to Shanta. If we create all of the pages in advance, there does to seem to be a need a pressing need for an SQL Database. The reason for it was the efficiency during data access. So, the question is whether we gain anything by creating one. In my mind, it doesn't matter if the pre-processing takes longer as it would with an SQL DB. How do the rest of you see this? Hal suggested including the PageID as an attriube to the <Type> tag and we were both thinking that we could the sub-type as an attribute of the <Type> tag. <Type id="45">Page</Type> <Type url="http://www.linux.org">MoreInfo</Type> <Type subtype="verb">Glossary</Type> This makes sense as the sub-type is a characteristic of the type and not the actual KU. For the questions, we have the issue of an empty <Reason> tag as a reminder to add something. It might be simpler to have the text of the Reason an attribute of the tag, like this: <reason answer="why this is correct" /> If it's empty we don't carry arounf the extra baggage. Did I forget anything important, Hal? Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: Hal F. G. <hgo...@pr...> - 2002-11-25 03:03:38
|
I have been on the road, I'll read through all the emails this week. What are my tasks? -----Original Message----- From: lin...@li... [mailto:lin...@li...] On Behalf Of James Mohr Sent: Sunday, November 24, 2002 12:02 PM To: lin...@li... Subject: [Linkbat-devel] Linkbat Dataflow Hi All! I have included a diagram of how I envision the dataflow within linkbat. It is also available online (linkbat.sourceforge.net/dataflow.html). At the bottom we have the data management layer, which, as it's name implies, is where the management of the data occurs. That is new data, new KUs, new KU types, changes etc are inserted into the system at this level. Above that is the data access layer, which provides the data to the presentation layer. Between the data management and data access layers are the perl routines that read the XML files and convert the data into the appropriate files. Note that there are two lines from the XML files into the data access layer, one into CSV and one into SQL. My ultimate goal is to give the user a choice as to which format the data should be used. My perception is that it will be unavoidable to store the data in intermediate files during the conversion, or at the very least the data will be in a form in memory that allows for easy conversion to CSV. That is, the KUs and reference indexes will probably be stored in an array and it would be a simple matter of looping through the arrays and then writing out the data to text files. However, instead of writing the data to text files, it could simply be inserted into the database tables. Therefore, I could imagine a command line options that determines where the data is writen CSV file or DB. One important aspect of the code is adding data to the system. Once it is in the database, then adding new KUs becomes becomes a key issue. Each KU will need to have a unique ID, which I think should be added during the conversion to CSV/DB and not stored within the XML file. This will be used for the references between KUs. A see a problem there when we add data to the system since the new data will not have any knowledge of the KU IDs. I see one solution as a table that contrains the relationship between KU text and KU ID, which probably should also contain the KU type. So each row looks like this: KUID:KU_TEXT_FROM_XML_FILE:KU_TYPE When a new KU is added we can reference existing KUs using this table. However, how do we add the references from existing KUs to the new ones. We cannot simply add them to the existing database as the will not be in the original XML files. Therefore, I see the only way to add KUs is to redo the **complete** data import each time we add a new a KU. Comments? Ideas? In the transition from data access to presentation I see an "issue" with the different data sources. I would like to see the code that the presentation layer uses to be **independant** of the data source. That is, the presenation layer makes a request of the data access layer to deliver a specific piece or set of data and the data access layer takes care of the rest. For example, the presentation layer would call functions similar to this: get_single_content_ku(KU_UD) get_all_moreinfo_ku(TOPIC) get_all_related_moreinfo_ku(KU_ID) In each case the presentation layer wants a piece or set of data and asks the data access layer to deliver it. It is then the responsibility of the data access layer to determine if the data source and the proper method to access that data source in order to deliver the requested data. By standardizing the interface, I see it a lot easier to have different delivery methods. Each can load the necessary perl modules (for example) and simple call the appropriate functions. How the delivery process interacts with the web server is dependant on the delivery and web server. Comments? Ideas? Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.422 / Virus Database: 237 - Release Date: 11/20/2002 |
|
From: James M. <lin...@ji...> - 2002-11-24 15:32:28
|
Hi All! I have included a diagram of how I envision the dataflow within linkbat. It is also available online (linkbat.sourceforge.net/dataflow.html). At the bottom we have the data management layer, which, as it's name implies, is where the management of the data occurs. That is new data, new KUs, new KU types, changes etc are inserted into the system at this level. Above that is the data access layer, which provides the data to the presentation layer. Between the data management and data access layers are the perl routines that read the XML files and convert the data into the appropriate files. Note that there are two lines from the XML files into the data access layer, one into CSV and one into SQL. My ultimate goal is to give the user a choice as to which format the data should be used. My perception is that it will be unavoidable to store the data in intermediate files during the conversion, or at the very least the data will be in a form in memory that allows for easy conversion to CSV. That is, the KUs and reference indexes will probably be stored in an array and it would be a simple matter of looping through the arrays and then writing out the data to text files. However, instead of writing the data to text files, it could simply be inserted into the database tables. Therefore, I could imagine a command line options that determines where the data is writen CSV file or DB. One important aspect of the code is adding data to the system. Once it is in the database, then adding new KUs becomes becomes a key issue. Each KU will need to have a unique ID, which I think should be added during the conversion to CSV/DB and not stored within the XML file. This will be used for the references between KUs. A see a problem there when we add data to the system since the new data will not have any knowledge of the KU IDs. I see one solution as a table that contrains the relationship between KU text and KU ID, which probably should also contain the KU type. So each row looks like this: KUID:KU_TEXT_FROM_XML_FILE:KU_TYPE When a new KU is added we can reference existing KUs using this table. However, how do we add the references from existing KUs to the new ones. We cannot simply add them to the existing database as the will not be in the original XML files. Therefore, I see the only way to add KUs is to redo the **complete** data import each time we add a new a KU. Comments? Ideas? In the transition from data access to presentation I see an "issue" with the different data sources. I would like to see the code that the presentation layer uses to be **independant** of the data source. That is, the presenation layer makes a request of the data access layer to deliver a specific piece or set of data and the data access layer takes care of the rest. For example, the presentation layer would call functions similar to this: get_single_content_ku(KU_UD) get_all_moreinfo_ku(TOPIC) get_all_related_moreinfo_ku(KU_ID) In each case the presentation layer wants a piece or set of data and asks the data access layer to deliver it. It is then the responsibility of the data access layer to determine if the data source and the proper method to access that data source in order to deliver the requested data. By standardizing the interface, I see it a lot easier to have different delivery methods. Each can load the necessary perl modules (for example) and simple call the appropriate functions. How the delivery process interacts with the web server is dependant on the delivery and web server. Comments? Ideas? Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: James M. <lin...@ji...> - 2002-11-22 10:10:44
|
HI All! Luu is now done with the CSV->XML conversion code and he can now start working on the validation code. I see the validation as a two step processs, both in terms of coding and the actual work. The first thing is to make sure we have a valid XML file, based on the not-yet-defined DTD. Even without the DTD, the principles are clear (I hope). A validation/check programm would look to make sure that all tags that are supposed to have a match have one, all tags that are supposed to be there are there and so on. For example, we decided that each answer should have the Reason tag pair, even if was empty. If not, the validation program will report it. Specific tags can only have certain attributes, like the Command type cannot have url="" attribute. The second step, which I see for sometime in the future is a validation of the data. For example, a future version could check to make sure that references are made only to KUs that are defined elsewhere. That would require reading in all of the KUs first, and would basically be the same code as the parse without the ouput. However, the parsing code will need to know about all KUs before it begins to write the indexes/cross-references. If there is a reference to a KU that does not exist, what should it do, report it and move on. We **could** have an option that simply runs through the process without writing it, as well as an option to check first and then write if things are okay. Comments? What concerns me is that a validation will require a full parse of the file, similar to the parse/export routines (to CSV or DB). The question is how much of the code will be the same? I would hate Luu to work on code that is duplicated in the parse and export routines. Luu, one thing you might want to check is to see if there are any perl modules for XML validation on www.cpan.org. I found a number of XML modules when I looked a couple of weeks, ago, but I cannot remember if there was anything about validation. Rama, are you there? Have you had done anything yet. I realize that you don't have the finished XML files (I'll get them done this weekend thanks to Luu's code). I'm just curious what you have done. Maybe we can combine the work in order to reduce the amount code and the time. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: <sco...@wi...> - 2002-11-21 20:20:26
|
This one is good. :) staci ----------------------------------- Truth is like the sun: Sometimes it's hidden, and sometimes you wonder if it's really there at all, but if you don't believe, it goes right on as it always has. On Thu, 21 Nov 2002, James Mohr wrote: > HI All! > > For many of you I have your SourceForge addess for the mailing list. > (use...@us...) For others I have non-sourceforge addresses. > Personally, I think the non-sourceforge address is better so that it does not > have to get redirected. But, since the mailing list and the email addresses > are all handled by SF, it shouldn't really matter. In any event, let me know > which address you prefer for the mailing list and will make the necessary > changes. > > Regards, > > jimmo > > -- > --------------------------------------- > "Be more concerned with your character than with your reputation. Your > character is what you really are while your reputation is merely what others > think you are." -- John Wooden > --------------------------------------- > Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Linkbat-writers mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linkbat-writers > |
|
From: James M. <lin...@ji...> - 2002-11-21 10:14:20
|
On Wednesday 20 November 2002 21:18, Shanta McBain wrote: > This file is all ready converted to MySQL. > Add what ever field you like. > to see go to my devel site > > http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat > Create an account and log in to see the link to the table. Sorry, but I am missing the point of the question manager? I see a number of headings with no content. "View All Records" also show me nothing. Is this intended as the interface to add questions to the system? Unless this mechanism can insert the question into a KU in the XML file and make the necessary references I am missing the point. Just to give it a go, I tried to add a question and got this: Error Notice I am sorry, but there were some errors in your submission. Please correct the errors to continue... doUpdate failed: Changes CANNOT BE rolled back 0 completed actions removed from update queue Could not add record; DBI error: Duplicate entry '127' for key 1 at ../Modules/Extropia/Core/DataSource/DBI.pm line 143. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: James M. <lin...@ji...> - 2002-11-21 09:44:14
|
On Wednesday 20 November 2002 21:05, Luan Luu wrote:
> Hi All,
>
> The seperator ":" is good for now in my opinion, since the other
> characters, we will also have in some of the other data files.
True.
> The reason tag should be there and stay empty, not removed, because when
> you extract XML to DB, i guess we expect a REASON tag to be there.
OK. Fine with me. However, I just want to make sure that we have consistant
rules. That is, we say that even if the tag is empty it **must** be present
in all cases. If it's okay to leave it out sometimes and not others, people
will forget and it gets confusing as to when and where it is allowed.
> Is it possible the tyk.data file be modified a little bit? Like you
> mentioned, there are a couple of character in there which can not be
> convert into valid XML format, such as the alone '&' need to change to
> '&', in the line number 45. The othere '&' in the data file was
> already in converted format, so it is alright. only the previous one
> mentioned causes problem. Also, I tried to convert all the < and > into the
> '<' and '>' respectively. Is that ok?
I don't think that will be a problem (I hope). The fact that we need to use
special characters like this in the text is unavoidable as it's simply part
of Linux.
> You mentioned the Topics and TopicRef tag should be insert into all the
> data file? Where do you think it should be?
>
> For the new dyk.data.NEW you sent me, it would produce this.
>
> <KnowledgeUnit>
> <Attributes>
> <Type>Concept</Type>
> <Text>Linux can be started from any partition.</Text>
> </Attributes>
> <Pages>
> <PageRef primary="true">106</PageRef>
> </Pages>
> <Questions>
>
> </Questions>
> </KnowledgeUnit>
>
> Where should the topics and topicref goes?
Good question. My feeling is that the Questions should come last. However,
the order of the KU references is unimportant, right? That is, the pages
could come first and then the Topics or the Topics first and then the pages.
However, (again my feeling) the topics are important enough and will "always"
be there, so they should come after the attributes. You then end up with
this:
<KnowledgeUnit>
<Attributes>
<Type>Concept</Type>
<Text>Linux can be started from any partition.</Text>
</Attributes>
<Topics>
<TopicRef> topic1</TopicRef>
<TopicRef> topic2</TopicRef>
</Topics>
<Pages>
<PageRef primary="true">106</PageRef>
</Pages>
<Questions>
</Questions>
</KnowledgeUnit>
regards,
jimmo
--
---------------------------------------
"Be more concerned with your character than with your reputation. Your
character is what you really are while your reputation is merely what others
think you are." -- John Wooden
---------------------------------------
Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info
|
|
From: James M. <lin...@ji...> - 2002-11-21 09:31:19
|
Hi All! In principle it is considered bad "netiquette" to snip out portions of email, news posts, etc. without marking your reply (i.e. <snip>). However, I am not too picky and I think that in this closed group we can all accept that portions will be removed to save space and time. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: James M. <lin...@ji...> - 2002-11-21 09:27:42
|
On Thursday 21 November 2002 07:37, Navin Dhanuka wrote: > Under OS we should also cover Kernel Internals I do a fair bit of that already. However, there is a lot more that I want to include. > Linux-Windows Integration could be names as > GNU/Linux & MS Windows You're on the right track with that, but I think it is too long. Shar Houlihan suggested "Linux & Windows". That's short and sweet. > .. Switching your OS to Linux > .... Xwindow System (Gnome, KDE) > .... Browsers, Email-Clients (Opera, Netscape, Konqueror) > .... Word Processors & Spread Sheets (OpenOffice.org) > .... Games (Doom) These are on my "wish list" of topics to cover. Also, a number of these topics will automatically fall into the topics GUI, Applications and so forth, so we need to be careful not to repeat too much. Personally, I bite my tongue when talking about games. Although I do play occassional, computers are a tool. However, we (that I) need to keep in mind that many people see that the "work" they do with computers is secondary and playing games is primary. ;-) > .. Migrating your Network to Linux > .... Linux on Server & Win on Clients > .... Linux Everywhere I think this is the big "Integration" topic. Its more than just "migration" as we need to addess issue where you **cannot** move to Linux such as applications that do not exist on Windows or others on the network that do not want to move. I have a small section on Samba (in the networking chapter) that I want to expand. However, I am still undecided as to whether to move it into the Linux-Windows chapter. Comments? > .. File Systems > .... (ext2, xt3, reiserfs, xfs) vs (fat, fat32, ntfs) Same thing as apps. I discuss the filesystem in details under the Linux chapters and don't want to repeat it here (however, I only discuss ext2 but I want to cover the others). However, a comparision of the various filesystems along with Windows is a good idea. > Pogramming > ..Shell Scriting > ..C > ..Sed/AWK I'm missing what you are getting at. Are you suggesting a whole new chapter on Programming? I like that. sed, perl and awk are under "editing files" which has bothered me from the beginning. Maybe "editing" should be expanded to include emacs and maybe so other non-GUI editors. Or maybe also the GUI editors. Hmmmm. Comments? > >This is not the same as "Users" which refers to topics related to user > >accounts (passwords, permissions, allowing remote access, etc.) > > This will go under Administration topic Exactly. > > >Please let me hear from you as soon as possible. (Please, be sure to send > >to > >the list and not just to me!) I keep forgetting that, don't I? ;-) Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: James M. <lin...@ji...> - 2002-11-21 09:22:14
|
Hi All! I know this will sound stupid. But I want to make sure that we all understand what I am talking about. When I say SF, I am referering to SourceForge. So, when I say the "task list on SF", then people know that this is the "task list on SourceForge". By the way, do people know about all the wonderful things that SF let's us keep track of like to-do tasks, bugs, feature requests, etc. I have added a lot of tasks already, although most apply to just the content writers and editors. Also many of the code tasks might become unnessary. If you are not familiar with it log into SF and take a look. Everyone is listed as a "technician" which will allow you to see the items and assign them to yourselves. (If you want). Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: James M. <lin...@ji...> - 2002-11-21 08:51:54
|
HI All! For many of you I have your SourceForge addess for the mailing list. (use...@us...) For others I have non-sourceforge addresses. Personally, I think the non-sourceforge address is better so that it does not have to get redirected. But, since the mailing list and the email addresses are all handled by SF, it shouldn't really matter. In any event, let me know which address you prefer for the mailing list and will make the necessary changes. Regards, jimmo -- --------------------------------------- "Be more concerned with your character than with your reputation. Your character is what you really are while your reputation is merely what others think you are." -- John Wooden --------------------------------------- Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info |
|
From: Navin D. <nav...@ms...> - 2002-11-21 06:37:19
|
Hello, Under OS we should also cover Kernel Internals Linux-Windows Integration could be names as GNU/Linux & MS Windows .. Switching your OS to Linux .... Xwindow System (Gnome, KDE) .... Browsers, Email-Clients (Opera, Netscape, Konqueror) .... Word Processors & Spread Sheets (OpenOffice.org) .... Games (Doom) .. Migrating your Network to Linux .... Linux on Server & Win on Clients .... Linux Everywhere .. File Systems .... (ext2, xt3, reiserfs, xfs) vs (fat, fat32, ntfs) Pogramming ..Shell Scriting ..C ..Sed/AWK >This is not the same as "Users" which refers to topics related to user >accounts (passwords, permissions, allowing remote access, etc.) This will go under Administration topic >Please let me hear from you as soon as possible. (Please, be sure to send >to >the list and not just to me!) College lab will be off for 4-5 days, I will mail my complete list of topics , subtopics after that. Thanks..!! Navin Dhanuka _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail |
|
From: Shanta M. <sh...@fo...> - 2002-11-20 20:26:21
|
Ps I have already added a Category field in anticipation of Jim's idea of giving the user more questions in a category if they make errors. On Wed, 2002-11-20 at 12:18, Shanta McBain wrote: > On Wed, 2002-11-20 at 12:05, Luan Luu wrote: > > Hi All, > > > > The seperator ":" is good for now in my opinion, since the other characters, > > we will also have in some of the other data files. > > > > > The reason tag should be there and stay empty, not removed, because when you > > extract XML to DB, i guess we expect a REASON tag to be there. > > > > Is it possible the tyk.data file be modified a little bit? Like you > > mentioned, there are a couple of character in there which can not be convert > > into valid XML format, such as the alone '&' need to change to '&', in > > the line number 45. The othere '&' in the data file was already in > > converted format, so it is alright. only the previous one mentioned causes > > problem. Also, I tried to convert all the < and > into the '<' and '>' > > respectively. Is that ok? > > > > This file is all ready converted to MySQL. > Add what ever field you like. > to see go to my devel site > > http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat > Create an account and log in to see the link to the table. > > > > You mentioned the Topics and TopicRef tag should be insert into all the data > > file? Where do you think it should be? > > > > For the new dyk.data.NEW you sent me, it would produce this. > > > > <KnowledgeUnit> > > <Attributes> > > <Type>Concept</Type> > > <Text>Linux can be started from any partition.</Text> > > </Attributes> > > <Pages> > > <PageRef primary="true">106</PageRef> > > </Pages> > > <Questions> > > > > </Questions> > > </KnowledgeUnit> > > > > Where should the topics and topicref goes? > > > > thanks. > > > > Best Regards > > -Luu > > > > > > > > > > > > >From: James Mohr <lin...@ji...> > > >Reply-To: lin...@ji... > > >To: lin...@li... > > >Subject: [Linkbat-devel] Re: question on moreinfo.data (Everyone please > > >read) > > >Date: Tue, 19 Nov 2002 11:03:51 +0100 > > > > > >(Note this was sent to the list.) > > > > > >Hey everyone, the conversion is almost done (well, at least the code for > > >it). > > >Thanks Luu! However, there are some important questions to answer NOW, > > >before > > >we continue. PLEASE, please, please read this and give me your input. > > > > > >On Tuesday 19 November 2002 00:31, Luan Luu wrote: > > > > according the the moreinfo.data, the format: > > > > ID#:TYPE:DESCRIPTION:LOCATION > > > > > > > > the XML are > > > > > > > > <KnowledgeUnit> > > > > <Atrributes> > > > > <Type sub-type="[TYPE]" location="[LOCATION]">MoreInfo</Type> > > > > <Text>[DESCRIPTION]</Text> > > > > </Atrributes> > > > > </KnowledgeUnit> > > > > > > > > In the reference to the brackets, is the pointer the the type, location, > > > > and description like that? > > > > > >Perfect. The only question is whether we should actually do it that way or > > >not. That is, should the sub-type and location be attributes within the > > ><Type> tag or should they be seperate tags, i.e. <SubType> <Location>? > > > > > >By gut feeling is that they should be attributes within the <Type> tag. > > >They > > >not necessarily attributes of KU, but rather provide additional info for > > >the > > >type. > > > > > >Comments anyone? This needs to be answered before we continue. > > > > > > > is the url be absolute path with the http infront right? > > > > > >Yes. You will note that in the data file, they just begin with // and not > > >http://. This was because I made an unwise decision to use the colon (:) as > > >the field seperator. However, the colon appears frequently in Linux > > >(especially with URLs) so it became a problem. > > > > > >I was going to change to something like a pipe (|) which comes less > > >frequently. Regardless, we will have a problem since the odds are that > > >whatever character we use, it will appear in text somewhere in the data. > > > > > >Obviously this is not a problem when we import directly into a database. > > >However, as I said to Shanta, I don't have a problem with importing the > > >files > > >directly into a database for the first release. However, eventually I want > > >the system to be independant of the data source (CSV, database) and > > >independant of the presentation (eXtropia, other portal). Therefore, we > > >need > > >to consider a new seperator. > > > > > >Suggestions? > > > > > > > Inside the tyk xml question tags, there is a topicRef tag, which is the > > > > reference of the PAGE_ID. So, do you want to put the Page_id in the > > > > topicRef tags or the actual topic name in the page.data ? > > > > > >The TopicRef is a references to a topic, such as Administration, > > >Networking, > > >Security, etc. This is just text. There are PageRef tags and these contains > > >the page *name* from page.data. However, I am nop longer sure we should do > > >it > > >that way (see below). This needs to be changed in tykToXML.pl. > > > > > >Keep in mind that the questions will exist only within a KU. This KU will > > >have > > >a primary page so we automatically have the primary page for the question. > > >However, the question could reference multiple topics. > > > > > >We have a problem with some of the questions where an angle bracket is one > > >of > > >the answer ("What symbol is used to "pipe" two commands together?") This > > >means we have two angle brackets together (<< or >>) which could confuse > > >the > > >XML parser. There are only a few and we can change them by hand. We just > > >need > > >to be aware of them. > > > > > >Also watch the format of the answers, even for the T/F questions: > > > > > > <Correct> > > > <Text>T</Text> > > > <Reason>why this answer is correct</Reason> > > > </Correct> > > > > > >not just > > > > > ><Correct>T</Correct> > > > > > >I think that as much as possible it is better to have the same format for > > >all > > >types of questions. More than likely, "fill in the blank" type questions > > >won't have an <Incorrect> answer, but I still want to have a <Reason> tag > > >to > > >provide an explanation why the answer is correct. > > > > > >However, since we do not yet have the reasons, I think you should simply > > >leave > > >as <Reason></Reason>. I think if we leave the text as "put your reason why > > >is > > >correct/incorrect. " we might forget to change it and then displaying that > > >text would look silly. If the <Reason> tag is empty, we can just ignore it. > > >OR we could simply not include the <Reason> tag at this point. What do you > > >think? > > > > > >With the Glossary KUs please create a <GlossaryTerms> container with the > > >GlossaryRefs to the other terms. These are the numbers at the end of each > > >line in glossary.data. They are the ID numbers of the other glossary terms. > > >Therefore, instead of reading in each line from glossary.data and > > >processing > > >it, you will need to read it all at once and put it into an array, then > > >parse > > >that array. > > > > > >EVERYONE PLEASE READ AND COMMENT: > > >Currently the glossary.idx file contains a list of pages that contain each > > >glossary item. This is created by an external script and is **not** done > > >when > > >the glossary item is loaded. That would take way too much time. The > > >question > > >is whether we should have PageRefs within the Glossary KU. > > > > > >Personally, I do not think so. We can create the index of glossary-page_id > > >along with everything else. If we include the page ID/page name within the > > >Glossary KU and add a new glossary item, then we would need to go looking > > >for > > >all of the pages that have that glossary term. Obviously we need to search > > >for the pages to add the <Glossary> tag within the page. However, I just > > >see > > >it as unnecessary work to add PageRefs withing the Glossary KU since we can > > >create the index by other, more efficient means. > > > > > > > > >EVERYONE PLEASE READ AND COMMENT: > > >It just hit me that we might be building a trap for ourselves. If we use > > >the > > >full path instead of the ID number, we will have problems if we ever rename > > >the file, move it to a different directory, etc. I **expect** to be moving > > >files to different directories real soon! I want to change the order of the > > >files and their locations. As we get more content, I can imagine that we > > >change locations again. > > > > > >I see three options: > > > > > >Use the full-path as the PageRef: > > >- Easy to find/insert the reference we want > > >- Tracking down the actual page from a KU is easy > > >- In the display code we don't need to do a look up to display the page. > > >- PROBLEM: moving/renaming the file. Since the XML files are text, we can > > >use > > >sed/perl to make a global change. > > > > > >Use just the page name without the path: > > >- Once the file name is defined, it is less likely that the page name will > > >be > > >changed. > > >PROBLEM: We must have *completely unique* page names. We cannot have a > > >"Known > > >Problems" in the Network section AND in the Printing section. They must be > > >named "Known Problems-Network" and "Known Problems-Printing" (or something > > >like that). > > > > > >Use the ID as the PageRef: > > >- Remains constant, independant of the actual name of the file. > > >- PROBLEM: Need to do a look-up to find the correct file. However, since > > >page.data is current sorted by chapter/section, I have found that it is > > >not > > >al that hard. For the existing moreinfo and DYK entries one PageRef can be > > >inserted automatically. Still, if we want to include more PageRefs, we will > > >hve to do it by hand and look up the ID, but we will have to look it up any > > >way to get the full path. So whether we lookup and insert the page name or > > >the page ID it's the same amount of work. > > > > > >I still like the idea of using the full-path and NOT and ID number. You > > >need > > >to do a look-up anyway to find the ID or the correct text for the full > > >path. > > >Tracking down the original page from the XML file is straight forward. > > >Making > > >a change would be a simple matter of running a sed/perl script. We could > > >even > > >write it in advance and it becomes a part of our "utility" package: > > > > > >rename_page.pl [-f filename] original_name new_name > > > > > >It then scans all PageRefs in the named file and changes them accordingly. > > > > > >Using an ID number bothers me because makes the construct dependant on an > > >external file or we are imposing a structure on it unnecessarily. > > >Therefore, > > >the knowledge base is not self-contained. > > > > > >EVERYONE PLEASE READ AND COMMENT: > > >We have a similar problem with the MoreInfoRefs for the Page KUs. Currently > > >they are referenced by their ID number and Luu did the same thing in her > > >code. However, once again, I am not happy with idea of using ID numbers > > >instead of text. So, do we reference the text of the MoreInfo KUs?? > > > > > >I have pretty much decided to go through the existing data files and add up > > >to > > >three topics. I will add these to the **end** of each line for all of the > > >data files. So, Luu, could you change the code to create a <Topics> > > >container > > >and <TopicRefs> for all of the data files? Note that I will probably not > > >list > > >three topics for everything. Therefore, the code will need to be smart > > >enough > > >to recognized this. Since you are probably asleep already I can work on it > > >today and send you at least one file with the topics, so you will see the > > >format. > > > > > >Regards, > > > > > >jimmo > > >-- > > >--------------------------------------- > > >"Be more concerned with your character than with your reputation. Your > > >character is what you really are while your reputation is merely what > > >others > > >think you are." -- John Wooden > > >--------------------------------------- > > >Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info > > > > > > > > >------------------------------------------------------- > > >This sf.net email is sponsored by: To learn the basics of securing > > >your web site with SSL, click here to get a FREE TRIAL of a Thawte > > >Server Certificate: http://www.gothawte.com/rd524.html > > >_______________________________________________ > > >Linkbat-devel mailing list > > >Lin...@li... > > >https://lists.sourceforge.net/lists/listinfo/linkbat-devel > > > > > > _________________________________________________________________ > > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > > http://join.msn.com/?page=features/featuredemail > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: > > Battle your brains against the best in the Thawte Crypto > > Challenge. Be the first to crack the code - register now: > > http://www.gothawte.com/rd521.html > > _______________________________________________ > > Linkbat-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linkbat-devel > -- > Shanta McBain <sh...@fo...> > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > Battle your brains against the best in the Thawte Crypto > Challenge. Be the first to crack the code - register now: > http://www.gothawte.com/rd521.html > _______________________________________________ > Linkbat-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linkbat-devel -- Shanta McBain <sh...@fo...> |
|
From: Shanta M. <sh...@fo...> - 2002-11-20 20:19:41
|
On Wed, 2002-11-20 at 12:05, Luan Luu wrote: > Hi All, > > The seperator ":" is good for now in my opinion, since the other characters, > we will also have in some of the other data files. > > The reason tag should be there and stay empty, not removed, because when you > extract XML to DB, i guess we expect a REASON tag to be there. > > Is it possible the tyk.data file be modified a little bit? Like you > mentioned, there are a couple of character in there which can not be convert > into valid XML format, such as the alone '&' need to change to '&', in > the line number 45. The othere '&' in the data file was already in > converted format, so it is alright. only the previous one mentioned causes > problem. Also, I tried to convert all the < and > into the '<' and '>' > respectively. Is that ok? > This file is all ready converted to MySQL. Add what ever field you like. to see go to my devel site http://webcthelpdesk.com/cgi-bin/Linkbat/linkbat.cgi?site=Linkbat Create an account and log in to see the link to the table. > You mentioned the Topics and TopicRef tag should be insert into all the data > file? Where do you think it should be? > > For the new dyk.data.NEW you sent me, it would produce this. > > <KnowledgeUnit> > <Attributes> > <Type>Concept</Type> > <Text>Linux can be started from any partition.</Text> > </Attributes> > <Pages> > <PageRef primary="true">106</PageRef> > </Pages> > <Questions> > > </Questions> > </KnowledgeUnit> > > Where should the topics and topicref goes? > > thanks. > > Best Regards > -Luu > > > > > > >From: James Mohr <lin...@ji...> > >Reply-To: lin...@ji... > >To: lin...@li... > >Subject: [Linkbat-devel] Re: question on moreinfo.data (Everyone please > >read) > >Date: Tue, 19 Nov 2002 11:03:51 +0100 > > > >(Note this was sent to the list.) > > > >Hey everyone, the conversion is almost done (well, at least the code for > >it). > >Thanks Luu! However, there are some important questions to answer NOW, > >before > >we continue. PLEASE, please, please read this and give me your input. > > > >On Tuesday 19 November 2002 00:31, Luan Luu wrote: > > > according the the moreinfo.data, the format: > > > ID#:TYPE:DESCRIPTION:LOCATION > > > > > > the XML are > > > > > > <KnowledgeUnit> > > > <Atrributes> > > > <Type sub-type="[TYPE]" location="[LOCATION]">MoreInfo</Type> > > > <Text>[DESCRIPTION]</Text> > > > </Atrributes> > > > </KnowledgeUnit> > > > > > > In the reference to the brackets, is the pointer the the type, location, > > > and description like that? > > > >Perfect. The only question is whether we should actually do it that way or > >not. That is, should the sub-type and location be attributes within the > ><Type> tag or should they be seperate tags, i.e. <SubType> <Location>? > > > >By gut feeling is that they should be attributes within the <Type> tag. > >They > >not necessarily attributes of KU, but rather provide additional info for > >the > >type. > > > >Comments anyone? This needs to be answered before we continue. > > > > > is the url be absolute path with the http infront right? > > > >Yes. You will note that in the data file, they just begin with // and not > >http://. This was because I made an unwise decision to use the colon (:) as > >the field seperator. However, the colon appears frequently in Linux > >(especially with URLs) so it became a problem. > > > >I was going to change to something like a pipe (|) which comes less > >frequently. Regardless, we will have a problem since the odds are that > >whatever character we use, it will appear in text somewhere in the data. > > > >Obviously this is not a problem when we import directly into a database. > >However, as I said to Shanta, I don't have a problem with importing the > >files > >directly into a database for the first release. However, eventually I want > >the system to be independant of the data source (CSV, database) and > >independant of the presentation (eXtropia, other portal). Therefore, we > >need > >to consider a new seperator. > > > >Suggestions? > > > > > Inside the tyk xml question tags, there is a topicRef tag, which is the > > > reference of the PAGE_ID. So, do you want to put the Page_id in the > > > topicRef tags or the actual topic name in the page.data ? > > > >The TopicRef is a references to a topic, such as Administration, > >Networking, > >Security, etc. This is just text. There are PageRef tags and these contains > >the page *name* from page.data. However, I am nop longer sure we should do > >it > >that way (see below). This needs to be changed in tykToXML.pl. > > > >Keep in mind that the questions will exist only within a KU. This KU will > >have > >a primary page so we automatically have the primary page for the question. > >However, the question could reference multiple topics. > > > >We have a problem with some of the questions where an angle bracket is one > >of > >the answer ("What symbol is used to "pipe" two commands together?") This > >means we have two angle brackets together (<< or >>) which could confuse > >the > >XML parser. There are only a few and we can change them by hand. We just > >need > >to be aware of them. > > > >Also watch the format of the answers, even for the T/F questions: > > > > <Correct> > > <Text>T</Text> > > <Reason>why this answer is correct</Reason> > > </Correct> > > > >not just > > > ><Correct>T</Correct> > > > >I think that as much as possible it is better to have the same format for > >all > >types of questions. More than likely, "fill in the blank" type questions > >won't have an <Incorrect> answer, but I still want to have a <Reason> tag > >to > >provide an explanation why the answer is correct. > > > >However, since we do not yet have the reasons, I think you should simply > >leave > >as <Reason></Reason>. I think if we leave the text as "put your reason why > >is > >correct/incorrect. " we might forget to change it and then displaying that > >text would look silly. If the <Reason> tag is empty, we can just ignore it. > >OR we could simply not include the <Reason> tag at this point. What do you > >think? > > > >With the Glossary KUs please create a <GlossaryTerms> container with the > >GlossaryRefs to the other terms. These are the numbers at the end of each > >line in glossary.data. They are the ID numbers of the other glossary terms. > >Therefore, instead of reading in each line from glossary.data and > >processing > >it, you will need to read it all at once and put it into an array, then > >parse > >that array. > > > >EVERYONE PLEASE READ AND COMMENT: > >Currently the glossary.idx file contains a list of pages that contain each > >glossary item. This is created by an external script and is **not** done > >when > >the glossary item is loaded. That would take way too much time. The > >question > >is whether we should have PageRefs within the Glossary KU. > > > >Personally, I do not think so. We can create the index of glossary-page_id > >along with everything else. If we include the page ID/page name within the > >Glossary KU and add a new glossary item, then we would need to go looking > >for > >all of the pages that have that glossary term. Obviously we need to search > >for the pages to add the <Glossary> tag within the page. However, I just > >see > >it as unnecessary work to add PageRefs withing the Glossary KU since we can > >create the index by other, more efficient means. > > > > > >EVERYONE PLEASE READ AND COMMENT: > >It just hit me that we might be building a trap for ourselves. If we use > >the > >full path instead of the ID number, we will have problems if we ever rename > >the file, move it to a different directory, etc. I **expect** to be moving > >files to different directories real soon! I want to change the order of the > >files and their locations. As we get more content, I can imagine that we > >change locations again. > > > >I see three options: > > > >Use the full-path as the PageRef: > >- Easy to find/insert the reference we want > >- Tracking down the actual page from a KU is easy > >- In the display code we don't need to do a look up to display the page. > >- PROBLEM: moving/renaming the file. Since the XML files are text, we can > >use > >sed/perl to make a global change. > > > >Use just the page name without the path: > >- Once the file name is defined, it is less likely that the page name will > >be > >changed. > >PROBLEM: We must have *completely unique* page names. We cannot have a > >"Known > >Problems" in the Network section AND in the Printing section. They must be > >named "Known Problems-Network" and "Known Problems-Printing" (or something > >like that). > > > >Use the ID as the PageRef: > >- Remains constant, independant of the actual name of the file. > >- PROBLEM: Need to do a look-up to find the correct file. However, since > >page.data is current sorted by chapter/section, I have found that it is > >not > >al that hard. For the existing moreinfo and DYK entries one PageRef can be > >inserted automatically. Still, if we want to include more PageRefs, we will > >hve to do it by hand and look up the ID, but we will have to look it up any > >way to get the full path. So whether we lookup and insert the page name or > >the page ID it's the same amount of work. > > > >I still like the idea of using the full-path and NOT and ID number. You > >need > >to do a look-up anyway to find the ID or the correct text for the full > >path. > >Tracking down the original page from the XML file is straight forward. > >Making > >a change would be a simple matter of running a sed/perl script. We could > >even > >write it in advance and it becomes a part of our "utility" package: > > > >rename_page.pl [-f filename] original_name new_name > > > >It then scans all PageRefs in the named file and changes them accordingly. > > > >Using an ID number bothers me because makes the construct dependant on an > >external file or we are imposing a structure on it unnecessarily. > >Therefore, > >the knowledge base is not self-contained. > > > >EVERYONE PLEASE READ AND COMMENT: > >We have a similar problem with the MoreInfoRefs for the Page KUs. Currently > >they are referenced by their ID number and Luu did the same thing in her > >code. However, once again, I am not happy with idea of using ID numbers > >instead of text. So, do we reference the text of the MoreInfo KUs?? > > > >I have pretty much decided to go through the existing data files and add up > >to > >three topics. I will add these to the **end** of each line for all of the > >data files. So, Luu, could you change the code to create a <Topics> > >container > >and <TopicRefs> for all of the data files? Note that I will probably not > >list > >three topics for everything. Therefore, the code will need to be smart > >enough > >to recognized this. Since you are probably asleep already I can work on it > >today and send you at least one file with the topics, so you will see the > >format. > > > >Regards, > > > >jimmo > >-- > >--------------------------------------- > >"Be more concerned with your character than with your reputation. Your > >character is what you really are while your reputation is merely what > >others > >think you are." -- John Wooden > >--------------------------------------- > >Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info > > > > > >------------------------------------------------------- > >This sf.net email is sponsored by: To learn the basics of securing > >your web site with SSL, click here to get a FREE TRIAL of a Thawte > >Server Certificate: http://www.gothawte.com/rd524.html > >_______________________________________________ > >Linkbat-devel mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linkbat-devel > > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > Battle your brains against the best in the Thawte Crypto > Challenge. Be the first to crack the code - register now: > http://www.gothawte.com/rd521.html > _______________________________________________ > Linkbat-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linkbat-devel -- Shanta McBain <sh...@fo...> |
|
From: Luan L. <lu...@ho...> - 2002-11-20 20:05:47
|
Hi All,
The seperator ":" is good for now in my opinion, since the other characters,
we will also have in some of the other data files.
The reason tag should be there and stay empty, not removed, because when you
extract XML to DB, i guess we expect a REASON tag to be there.
Is it possible the tyk.data file be modified a little bit? Like you
mentioned, there are a couple of character in there which can not be convert
into valid XML format, such as the alone '&' need to change to '&', in
the line number 45. The othere '&' in the data file was already in
converted format, so it is alright. only the previous one mentioned causes
problem. Also, I tried to convert all the < and > into the '<' and '>'
respectively. Is that ok?
You mentioned the Topics and TopicRef tag should be insert into all the data
file? Where do you think it should be?
For the new dyk.data.NEW you sent me, it would produce this.
<KnowledgeUnit>
<Attributes>
<Type>Concept</Type>
<Text>Linux can be started from any partition.</Text>
</Attributes>
<Pages>
<PageRef primary="true">106</PageRef>
</Pages>
<Questions>
</Questions>
</KnowledgeUnit>
Where should the topics and topicref goes?
thanks.
Best Regards
-Luu
>From: James Mohr <lin...@ji...>
>Reply-To: lin...@ji...
>To: lin...@li...
>Subject: [Linkbat-devel] Re: question on moreinfo.data (Everyone please
>read)
>Date: Tue, 19 Nov 2002 11:03:51 +0100
>
>(Note this was sent to the list.)
>
>Hey everyone, the conversion is almost done (well, at least the code for
>it).
>Thanks Luu! However, there are some important questions to answer NOW,
>before
>we continue. PLEASE, please, please read this and give me your input.
>
>On Tuesday 19 November 2002 00:31, Luan Luu wrote:
> > according the the moreinfo.data, the format:
> > ID#:TYPE:DESCRIPTION:LOCATION
> >
> > the XML are
> >
> > <KnowledgeUnit>
> > <Atrributes>
> > <Type sub-type="[TYPE]" location="[LOCATION]">MoreInfo</Type>
> > <Text>[DESCRIPTION]</Text>
> > </Atrributes>
> > </KnowledgeUnit>
> >
> > In the reference to the brackets, is the pointer the the type, location,
> > and description like that?
>
>Perfect. The only question is whether we should actually do it that way or
>not. That is, should the sub-type and location be attributes within the
><Type> tag or should they be seperate tags, i.e. <SubType> <Location>?
>
>By gut feeling is that they should be attributes within the <Type> tag.
>They
>not necessarily attributes of KU, but rather provide additional info for
>the
>type.
>
>Comments anyone? This needs to be answered before we continue.
>
> > is the url be absolute path with the http infront right?
>
>Yes. You will note that in the data file, they just begin with // and not
>http://. This was because I made an unwise decision to use the colon (:) as
>the field seperator. However, the colon appears frequently in Linux
>(especially with URLs) so it became a problem.
>
>I was going to change to something like a pipe (|) which comes less
>frequently. Regardless, we will have a problem since the odds are that
>whatever character we use, it will appear in text somewhere in the data.
>
>Obviously this is not a problem when we import directly into a database.
>However, as I said to Shanta, I don't have a problem with importing the
>files
>directly into a database for the first release. However, eventually I want
>the system to be independant of the data source (CSV, database) and
>independant of the presentation (eXtropia, other portal). Therefore, we
>need
>to consider a new seperator.
>
>Suggestions?
>
> > Inside the tyk xml question tags, there is a topicRef tag, which is the
> > reference of the PAGE_ID. So, do you want to put the Page_id in the
> > topicRef tags or the actual topic name in the page.data ?
>
>The TopicRef is a references to a topic, such as Administration,
>Networking,
>Security, etc. This is just text. There are PageRef tags and these contains
>the page *name* from page.data. However, I am nop longer sure we should do
>it
>that way (see below). This needs to be changed in tykToXML.pl.
>
>Keep in mind that the questions will exist only within a KU. This KU will
>have
>a primary page so we automatically have the primary page for the question.
>However, the question could reference multiple topics.
>
>We have a problem with some of the questions where an angle bracket is one
>of
>the answer ("What symbol is used to "pipe" two commands together?") This
>means we have two angle brackets together (<< or >>) which could confuse
>the
>XML parser. There are only a few and we can change them by hand. We just
>need
>to be aware of them.
>
>Also watch the format of the answers, even for the T/F questions:
>
> <Correct>
> <Text>T</Text>
> <Reason>why this answer is correct</Reason>
> </Correct>
>
>not just
>
><Correct>T</Correct>
>
>I think that as much as possible it is better to have the same format for
>all
>types of questions. More than likely, "fill in the blank" type questions
>won't have an <Incorrect> answer, but I still want to have a <Reason> tag
>to
>provide an explanation why the answer is correct.
>
>However, since we do not yet have the reasons, I think you should simply
>leave
>as <Reason></Reason>. I think if we leave the text as "put your reason why
>is
>correct/incorrect. " we might forget to change it and then displaying that
>text would look silly. If the <Reason> tag is empty, we can just ignore it.
>OR we could simply not include the <Reason> tag at this point. What do you
>think?
>
>With the Glossary KUs please create a <GlossaryTerms> container with the
>GlossaryRefs to the other terms. These are the numbers at the end of each
>line in glossary.data. They are the ID numbers of the other glossary terms.
>Therefore, instead of reading in each line from glossary.data and
>processing
>it, you will need to read it all at once and put it into an array, then
>parse
>that array.
>
>EVERYONE PLEASE READ AND COMMENT:
>Currently the glossary.idx file contains a list of pages that contain each
>glossary item. This is created by an external script and is **not** done
>when
>the glossary item is loaded. That would take way too much time. The
>question
>is whether we should have PageRefs within the Glossary KU.
>
>Personally, I do not think so. We can create the index of glossary-page_id
>along with everything else. If we include the page ID/page name within the
>Glossary KU and add a new glossary item, then we would need to go looking
>for
>all of the pages that have that glossary term. Obviously we need to search
>for the pages to add the <Glossary> tag within the page. However, I just
>see
>it as unnecessary work to add PageRefs withing the Glossary KU since we can
>create the index by other, more efficient means.
>
>
>EVERYONE PLEASE READ AND COMMENT:
>It just hit me that we might be building a trap for ourselves. If we use
>the
>full path instead of the ID number, we will have problems if we ever rename
>the file, move it to a different directory, etc. I **expect** to be moving
>files to different directories real soon! I want to change the order of the
>files and their locations. As we get more content, I can imagine that we
>change locations again.
>
>I see three options:
>
>Use the full-path as the PageRef:
>- Easy to find/insert the reference we want
>- Tracking down the actual page from a KU is easy
>- In the display code we don't need to do a look up to display the page.
>- PROBLEM: moving/renaming the file. Since the XML files are text, we can
>use
>sed/perl to make a global change.
>
>Use just the page name without the path:
>- Once the file name is defined, it is less likely that the page name will
>be
>changed.
>PROBLEM: We must have *completely unique* page names. We cannot have a
>"Known
>Problems" in the Network section AND in the Printing section. They must be
>named "Known Problems-Network" and "Known Problems-Printing" (or something
>like that).
>
>Use the ID as the PageRef:
>- Remains constant, independant of the actual name of the file.
>- PROBLEM: Need to do a look-up to find the correct file. However, since
>page.data is current sorted by chapter/section, I have found that it is
>not
>al that hard. For the existing moreinfo and DYK entries one PageRef can be
>inserted automatically. Still, if we want to include more PageRefs, we will
>hve to do it by hand and look up the ID, but we will have to look it up any
>way to get the full path. So whether we lookup and insert the page name or
>the page ID it's the same amount of work.
>
>I still like the idea of using the full-path and NOT and ID number. You
>need
>to do a look-up anyway to find the ID or the correct text for the full
>path.
>Tracking down the original page from the XML file is straight forward.
>Making
>a change would be a simple matter of running a sed/perl script. We could
>even
>write it in advance and it becomes a part of our "utility" package:
>
>rename_page.pl [-f filename] original_name new_name
>
>It then scans all PageRefs in the named file and changes them accordingly.
>
>Using an ID number bothers me because makes the construct dependant on an
>external file or we are imposing a structure on it unnecessarily.
>Therefore,
>the knowledge base is not self-contained.
>
>EVERYONE PLEASE READ AND COMMENT:
>We have a similar problem with the MoreInfoRefs for the Page KUs. Currently
>they are referenced by their ID number and Luu did the same thing in her
>code. However, once again, I am not happy with idea of using ID numbers
>instead of text. So, do we reference the text of the MoreInfo KUs??
>
>I have pretty much decided to go through the existing data files and add up
>to
>three topics. I will add these to the **end** of each line for all of the
>data files. So, Luu, could you change the code to create a <Topics>
>container
>and <TopicRefs> for all of the data files? Note that I will probably not
>list
>three topics for everything. Therefore, the code will need to be smart
>enough
>to recognized this. Since you are probably asleep already I can work on it
>today and send you at least one file with the topics, so you will see the
>format.
>
>Regards,
>
>jimmo
>--
>---------------------------------------
>"Be more concerned with your character than with your reputation. Your
>character is what you really are while your reputation is merely what
>others
>think you are." -- John Wooden
>---------------------------------------
>Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: To learn the basics of securing
>your web site with SSL, click here to get a FREE TRIAL of a Thawte
>Server Certificate: http://www.gothawte.com/rd524.html
>_______________________________________________
>Linkbat-devel mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linkbat-devel
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
|
|
From: Shanta M. <sh...@fo...> - 2002-11-20 19:45:28
|
Humm Not sure why it is not picking up the CSSView. Have to go now so I will work on it again later. May be just my browser. Shanta On Wed, 2002-11-20 at 11:18, Shanta McBain wrote: > the took 1.5 Hours to convert from CSV to MySQL and create a base app to > access the data. > > eXtropia hacking at its best. Not every things gos that well though. > > -- > Shanta McBain <sh...@fo...> > > > > ------------------------------------------------------- > This sf.net email is sponsored by: > Battle your brains against the best in the Thawte Crypto > Challenge. Be the first to crack the code - register now: > http://www.gothawte.com/rd521.html > _______________________________________________ > Linkbat-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linkbat-devel -- Shanta McBain <sh...@fo...> |
|
From: Shanta M. <sh...@fo...> - 2002-11-20 19:21:08
|
Try question manager in the Admin add links I will add one to the admin links. Shanta On Wed, 2002-11-20 at 12:31, James Mohr wrote: > On Wednesday 20 November 2002 19:33, Shanta McBain wrote: > > Hi All > > > > I have created the Questions table here is the details contained in the > > Client news link on the left side bar this is only visible to > > Linkbat_admin. I also have not converted this to the Linkbat View yet so > > you will not get a left side bar or style sheets. (this is written with > > View from the web) > > I have three links labled "Client news". None of them provide any questions. > (At least nothing I have found.) > > > > > Added Questions table > > > > Please note new addition in admin add table on the left side bar. This > > link is to the table of questions. see details. > > > > The Question number no longer match the original table as the first > > field in the MySQL table was set to auto incriminate so the table was > > populated with a different set of numbers than the csv file. If this is > > critical I can redo it. turning of auto inc then turning it on after > > install. > > The actual question numbers (i.e. question IDs) are not important. What is > important is the included page ID. This provides the link back to the page > where the this question came from. > > > > > Another note of importance is the category field . The drop list of > > entries are contained in a table and filled via a ActionHandler. This > > allows admin to add new categories by placing them in the table. I am > > currently updating this system and will add the changes soon. This will > > consist of an add form in the admin add links and a ActionHandler tuned > > to Linkbats needs. > > I am missing the point of a form to input questions. I understand that this is > something that eXtropia can do, but unless this mechanism can insert the > question into a KU in the XML file and make the necessary references I am > missing the point. > > regards, > > jimmo > > -- > --------------------------------------- > "Be more concerned with your character than with your reputation. Your > character is what you really are while your reputation is merely what others > think you are." -- John Wooden > --------------------------------------- > Be sure to visit the Linux Tutorial: http://www.linux-tutorial.info > > > ------------------------------------------------------- > This sf.net email is sponsored by: > Battle your brains against the best in the Thawte Crypto > Challenge. Be the first to crack the code - register now: > http://www.gothawte.com/rd521.html > _______________________________________________ > Linkbat-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linkbat-devel -- Shanta McBain <sh...@fo...> |
|
From: Shanta M. <sh...@fo...> - 2002-11-20 19:19:04
|
the took 1.5 Hours to convert from CSV to MySQL and create a base app to access the data. eXtropia hacking at its best. Not every things gos that well though. -- Shanta McBain <sh...@fo...> |
