OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

legaldocml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE:[legaldocml] URGENT: Summary of Naming Convention - D3

Dear Monica and Fabio,


If you think that my position regarding the use of "/" and "__" turns the IRI convention on its head, is too non orthodox and leads to the definition of a maverick standard, please leaves this problem down.


I can perflectly live with one specific syntax for the hierarchy of components (between "!" and "~", like "annex_5/appendix_2") and another syntax for portion/fragment (after ~, "art_5__para_1"), especially taking into account the deadline explained by Monica and the significant effort to modify this at this stage of the project.


In this case, we skip the discussion on the "PENDING ISSUES sub-fragments:" and focus on the other points.



Kind regards




Véronique Parisse

AUBAY Luxembourg

Orco House
38, Parc d’activités - L-8308 Capellen
Standard : +352 2992501
Fax : +352 299251


De : legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] de la part de PARISSE, Véronique [V.PARISSE@aubay.lu]
Envoyé : jeudi 12 novembre 2015 10:47
À : monica.palmirani; legaldocml@lists.oasis-open.org
Objet : [legaldocml] RE:[legaldocml] URGENT: Summary of Naming Convention - D3

Hello Monica and everybody

see my comment hereafter


But before, I have something that I want to add in the specification (but we don't have the time to discussed it yesterday) :


Akoma Ntoso documents are divided into containers : <preface>, <preamble>, the main content of the document, <conclusions> and <attachments>.

The <preface>, <preamble> <attachments> and <conclusions> elements are available in all types of documents. 
But the "main content of a document" is marked by different kind of  elements, depending on the type of the akoma ntoso documents (the content are differently structured).  For single document (so, not a document collection), we have: <body>, <mainBody>, <amendmentBody>, <debateBody>, <judgmentBody>. 

I propose that, for all these elements (<body>, <mainBody>, <amendmentBody>, <debateBody>, <judgmentBody>), the Akn naming convention provide a common prefix (for example, « body »), so that we can use it for selecting the whole body of an act

For the rest, see my comments below (in blue)



Kind regards



Véronique Parisse
AUBAY Luxembourg
Orco House
38, Parc d’activités - L-8308 Capellen
Standard : +352 2992501
Fax : +352 299251

De : legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] de la part de monica.palmirani [monica.palmirani@unibo.it]
Envoyé : jeudi 12 novembre 2015 8:56
À : legaldocml@lists.oasis-open.org
Objet : [legaldocml] URGENT: Summary of Naming Convention - D3

Dear all,

thanks for the yesterday TC meeting.

I would like to summarize the decision taken and to consolidate the
pending issues in order to close the D3 remotely before the next TC
meeting scheduled Nov. 25th.

We agree on this syntax where (see the Adobe Connect minutes below):

/akn/eu/act/2015/123~art_12 - simple situation
/akn/eu/act/2015/123!main/~art_12 - main is optional

also, I don't think that the / is necessary before the ~

=> /akn/eu/act/2015/123!main~art_12

/akn/eu/act/2015/123!main/annex_1/annex_5~art_12 - complex situation
/akn/eu/act/2015/123!annex_1/annex_5~art_12  (main optional)


/akn/eu/act/2015/123/fr@2015~art_12 - simple situation
/akn/eu/act/2015/123/fr@2015!main/~art_12 - main is optional
/akn/eu/act/2015/123/fr@2015!main~art_12 - main is optional
/akn/eu/act/2015/123/fr@2015!main/annex_1/annex_5~art_12 - complex
situation with components


/akn/eu/act/2015/123/fr@2015!annex_1/annex_5~art_12 (main is optional)
/akn/eu/act/2015/123/fr@2015/eupub!main/annex_1/annex_5~art_12 - complex
situation with components and optional metadata of the _expression_ (eupub)


/akn/eu/bill/2015/123/fr@ver_final!annex_1/annex_5~art_12 (version "final" of the bill for example when a proposal for an act is adopted by the Commission) 

/akn/eu/act/2015/123/fr@2015~art_12.xml - simple situation
/akn/eu/act/2015/123/fr@2015!main/~art_12.xml - main is optional

/akn/eu/act/2015/123/fr@2015!main~art_12.xml - main is optional
/akn/eu/act/2015/123/fr@2015!main/annex_1/annex_5~art_12.xml - complex
situation with components


/akn/eu/act/2015/123/fr@2015!annex_1/annex_5~art_12.xml (main optional)

complex situation with components and optional metadata of the
_expression_ (eupub)

/akn/eu/act/2015/123/fr@2015/eupub!annex_1/annex_5~art_12.xml- (main optional)

Another point

For the fragment/portion, we explain the mapping between the structure and the name used in the reference ("art" for article, "chp" for chapter, name of the element in general, how is make the numbering, ...)

For the component, we need also to specify where we find the information (which part of metadata correspond to the name of the component (annex, appendix, schedule, ... : is it the name attribute of the akn document element ? is it the metadata subType, other ?), 

We need also to explain how to design a component that has no component name (for example, documents that are attached and not included, like the agreement attached to a decision act).
Finally, we need also to provide some examples for documentCollection (where you have two type of component : one inside the main body and one inside the attachment).

PENDING ISSUES sub-fragments:


To clarify my position


I think that it is dommage that the "/" separator is used for two type of information in the structure of the IRI

- separate different metadata (for example, in "eu/act", the slash separate different type of information ( the country and the type of the act).

- mark the hierarchy (for example, annex_1/appendix_3/attachment_2 ...)


On another point, we have another syntax for marking a hierarchy : "__"  So why can we not do this :



Alternatively, if you consider that "__" is not enough esthetic, then we can continue to use the "/" meltingpot, but EVERYWHERE, so


Consider that it is the syntax of referencing but it can never be considered as the "exact value" of the eId attribute, because, as it was clearly explained yesterday, the "eId" value is completely dependant on the organisation of the manifestation and whether you physically group or not  the component manifestations in the same xml document (in fact, eId is constained by the XML syntax and rules on the unicity of the attribute) but of course, the author of a citation has not to take this into account.

So, the naming convention of the reference is more generic and cannot be build on the real organisation of the manifestations.


Much more, the naming convention of the reference must, for my point of view, be considered as a generic syntax allowing to find information in documents independently of its format: I can use the akn naming convention to reference fragment/portion in pdf or word document (in fact, I do it for referencing portion/fragment in a Formex document that has a completely different syntax for the naming of the text structure.  So, I establish a mapping between these two syntaxes).


So, choice between the / or the __ (my preference is for the "__") but please, adopt it everywhere a hierarchy is expressed (for component hierarchy also),

Of course, we need to align the syntax of the eId accordingly (hoping that "/" is allowed for eId ;-) ).

Veronique proposal:

Other proposal:

Take also in consideration the fragment after the format:



Please start the discussion in mailing list because I want to close all
the deliverable within the year 2015 and the correspondent
It is urgent and necessary for the success of the standard.




The Minutes of yesterday from Adobe Connect: 11th Nov. 2015

   Monica Palmirani:hi Grant
   Grant Vergottini:Hi Monica
   Monica Palmirani:https://www.oasis-open.org/apps/org/workgroup/legaldocml/event.php?event_id=41129
   Monica Palmirani:hello
   Monica Palmirani:Hello Fabio
   Fabio Vitali:ciao
   Fabio Vitali:As soon as Sylvia ecords her attendance, we have quorum
   Fabio Vitali:so we can start
   MonicaPalmirani:/akn/eu/act/2015/123/fr@/eupub~$/art_12.akn#art_12   (Art. 12 of this component)
   Fabio Vitali:yes
   Grant Vergottini:yes
   Monica Palmirani:- /akn/eu/act/2015/123/fr@/eupub!$~art_12.akn#art_12  (Art. 12 of this component)
   parisse:but not the doc
   Monica Palmirani:- /akn/eu/act/2015/123/fr@/eupub~Annex_3/Annex_1/art_12.akn#art_12  (Art. 12 of component Annex 1 of Annex 3)
   Monica Palmirani:- /akn/eu/act/2015/123/fr@/eupub!Annex_3/Annex_1~art_12.akn#art_12  (Art. 12 of component Annex 1 of Annex 3)
   Grant Vergottini:I prefer the first
   Grant Vergottini:yes
   Grant Vergottini:yes
   parisse:[http://www.authority.org]/akn/sl/act/2004-02-13/2~art_3 with the same syntax as for the # [http://www.authority.org]/akn/sl/act/2004-02-13/2#art_3
   Fabio Vitali:No Veronique, it is NOT the same syntax.
   parisse:why and how the user know that ?
   Fabio Vitali:For one, the # goes always at the end of the string, while the ~something comes before the format
   Fabio Vitali:Second: the ~ is part of the request, the # is not part of the request,
   Fabio Vitali:you can put BOTH
   parisse:this is what I want to change : the ~is also always at the end
   Fabio Vitali:Please no. The format is at the end
   parisse:not for me
   parisse:the format is at the same position as for the #
   parisse:why to change ?
   parisse:the only difference is that all the "string" is sent to the server
   Grant Vergottini:I'm sorry if I'm coming into this late, but the # part is not part of the request - and it stripped away before it gets there. We can't change that. What's left should end in the format.
   Grant Vergottini:What's the issue? It seems that a lot of it is decided by standards that come before us
   parisse:yes, Grant, it is the reason I propose to replace the # by the ~when you want that all the "string" is sent to the server
   Monica Palmirani:The parser is not able to distinguish univocally the optional part of the _expression_ to the components
   parisse:I dont understant this
   parisse:Which example ?
   Grant Vergottini:In my existing implementation, I do {doc}{@expressionpart}/{fragmentPath}.{format}#{id}. The only difference I can see from Fabio's proposal is that I use / instead of ~
   Monica Palmirani:!
   Fabio Vitali:Veronique, in the mail I gave also a brief specification of the algorithm necessary to extract the fragment id part from the URI. It is literally three lines long.
   parisse:I propose also something for annex of annex.  And also, I thing that the ! is also free.  Last, I don't understand why the format is sometimes at the end and sometimes not.
   Fabio Vitali:It is ALWAYS at the end of the request.
   Fabio Vitali:as with any decent-looking URI
   parisse:so #art+*.doc ?
   Grant Vergottini:The format is always at the end in my case. The part starting with # is not part of the request
   parisse:srry #art_12.doc ?
   Fabio Vitali:#art is NOT part of the request
   Fabio Vitali:this is the URI syntax not me
   parisse:I don't understand the difference : it is a way to specify a portion/fragment of text
   parisse:the only thing is that it is impossible to sent to the server something after the # but it is all.
   Fabio Vitali:Veronique: there is a designed structure of the URI, that we are keeping consistent: AKN URIs look like normal URIs as much as possible, are organized in parts, and these parts make sense.
   Fabio Vitali:The first part is the WORK
   Fabio Vitali:The secodn PART is the _expression_
   parisse:For a user given a reference, there is no need to make a difference between the two structure, there is no need to put the format at the end sometimes and sometimes not
   Fabio Vitali:The third part is manifestation (minus, for tradition, the format)
   Fabio Vitali:The FOURTH part is the internal specification
   Fabio Vitali:The fifth part ìs the format
   parisse:not minus that the question
   Monica Palmirani:The internal specification can be used also with  WORK and _expression_
   parisse:and the last part is the fragment/portion part with a special character before (~or ! )
   Grant Vergottini:I've never seen a URL that specified a format anywhere but at the end
   Monica Palmirani:right Grant and so .xml#art_12
   Monica Palmirani:this is the URL syntax
   parisse:when you have the # how does it works ?
   parisse:the format is before the #, not after
   Grant Vergottini:The # is stripped away by the browser before the request is transmitted
   parisse:I only want to use the same syntax, replacing the # by another character so that the server receive everything
   Monica Palmirani:it doesn't work veronique
   Monica Palmirani:for all the situations that we have
   Grant Vergottini:If you just replace the # with a ~, you get a weird URL that isn't conventional
   Monica Palmirani:right
   Monica Palmirani:Veronique
   Grant Vergottini:For some of my customers, they break the document up into a lot of small files, on for each section -- and then save the result in the file system It's easier to support that methodology using {docPath}{expressionPart}/{fragmentPath}.{format}
   Grant Vergottini:one for each section
   Grant Vergottini:That's why I use / instead of ~, but I'm not insistent on that
   Monica Palmirani:please start with WORK
   Monica Palmirani:/akn/eu/act/2015/123~main/art_12
   Grant Vergottini:With my methodology, I can implement a document broken into pieces using the file system and no resolver -- just a normal web server
   parisse:ok, but do you agree on the ~for separate the fragment/portion part from the IRI work _expression_ manifestation minus format ?
   parisse:That is very important for me
   Monica Palmirani:you are not able to redirect all the languages and all the versions useful for an interval of time Grant if you use only the file system
   Grant Vergottini:I'm happy to use the ~ instead of the /
   parisse:I can write ~main__art_12
   Monica Palmirani:~main/art_12
   Grant Vergottini:I understand that Monica, but not all customers require that
   parisse:if main is a prefix like art
   Grant Vergottini:Some customers need something really simple
   Monica Palmirani:We need to serve all
   parisse:no I think that you can do it using the same prefix_number (in the case of main, no number is needed)
   Grant Vergottini:My methodology is as Fabio proposes, except for the ~, but I'm happy to accept the ~
   Fabio Vitali:I believe that "main"  should be optional. ~main/art_12 and ~art_12 should mean exactly the same thing
   parisse:so ~main__art_1__para_1
   Grant Vergottini:Yes, absolutely. For me it would be ~main/sec_12 == ~sec_12
   parisse:@grand yes, really simple
   Monica Palmirani:hold on: simple situation is simple we MUST to model also the other situations
   Monica Palmirani:nooo
   Monica Palmirani:I am forced to use internal id main__chp_I
   Monica Palmirani:and It is not necessary
   Monica Palmirani:at all
   Monica Palmirani:simple solution you said
   parisse:so you can use ~chap_I
   Grant Vergottini:I would not include main__
   Monica Palmirani:what about annex_1__annex__3__main__4
   Monica Palmirani:and why do not use /
   Fabio Vitali:We cannot use / as a separator in fragment ids, but we can and should use it to separate components from fragment ids
   Fabio Vitali:attachment_1/attachment_1/art_4
   parisse:or attachment_1__attachment_1__amin__art_4
   parisse:no attachment is an element that has a prefix_number for eId or wId
   parisse:so it is the same mechanism
   Monica Palmirani:no
   Monica Palmirani:it is not the same
   Monica Palmirani:we can use / for composing the URI
   Fabio Vitali:No veronique
   Fabio Vitali:NO NO NO
   Monica Palmirani:granularly
   Fabio Vitali:you have a fragment id that is cpmposed of parts separataed by __
   Monica Palmirani:and hierarchyacally
   Fabio Vitali:then you have the component name
   Fabio Vitali:if the component name is part of the fragment id, it is alreay in the fragment id. Otherwise, you CANNOT USE __ to separate component names
   parisse:yes, inside an attachment you have only one document.  You can refer to it using his IRI that is in its identification part of the metadata
   Fabio Vitali:otherwise we cannot find out where the fragment id starts
   parisse:or using the imbrication of element and treat it like any other portion
   Fabio Vitali:You are mixing up the organization of an XML Manifestation with the conceptual organization of the _expression_. The fragment ids work at the Work and _expression_ level, too.
   Fabio Vitali:They should NOT depend on how you cut the Manifestation in pieces
   parisse:not it is not the case as I use the <component> element for that
   Monica Palmirani:you have also <portion>
   Fabio Vitali:NOOOOO
   Fabio Vitali:_expression_-level documents do not contain portions!
   Fabio Vitali:This is only a MANIFESTATION-level trick
   Fabio Vitali:you cannot use manifestation-level ids for links
   Fabio Vitali:NEVER
   parisse:I can reference document attached to the "root" document using the mecanism based on the element (cmp_1__[portion inside the document] or using the IRI that is specify at the level of the attachment
   Monica Palmirani:this is the id
   parisse:what do you do when you use art_1__para_1 ?
   parisse:it is exactly the same
   Fabio Vitali:NO ID should change if you return a portion of a document or the whole document
   Monica Palmirani:One of the main comment of the reviewer Patrick is to divide the D3 in two parts: ID to  move this part in D1 and naming convention of URI to maintain in D3 in order to not make confusion
   Monica Palmirani:now we are stuck in this discussion.
   parisse:yes, I agree with this, this is the reason I want a character to separe the two parts in the reference
   Monica Palmirani:confusing ID with URI
   Monica Palmirani:no Veronique
   Monica Palmirani:you pretend to use ID in the URI fragment
   Monica Palmirani:that are two different levels
   Monica Palmirani:components are part of the URI
   Monica Palmirani:fragment is linked to ID
   parisse:part that is build on id and part that is build on identification part of the metadata
   parisse:this is the meaning of the ~ for me
   parisse:but any other character is also good
   Monica Palmirani:/akn/eu/act/2015/123!main~art_12
   Monica Palmirani:what about this
   Monica Palmirani:veronique
   Monica Palmirani:do you agree?
   Monica Palmirani:with main optional
   Monica Palmirani: /akn/eu/act/2015/123/fr@2015!main~art_12
   Monica Palmirani:Veronique? do you agree since now?
   parisse:yes that is ok for me, as it separe the identification metadata from the id based info
   parisse:with only exception for the format
   Grant Vergottini:And I can use  /akn/eu/act/2015/123/fr@2015~art_12 if I want?
   Monica Palmirani:yes
   Monica Palmirani:mmmh almost
   Monica Palmirani:!
   Monica Palmirani:!~art_12
   Fabio Vitali:no
   Fabio Vitali:wait
   parisse:~art_12 (means, no info for the identification part)
   Fabio Vitali:IF we decide to separate compnents from fargment ids, then if there is no component spec, there must be no component spearator
   Fabio Vitali:So:
   Fabio Vitali:/akn/eu/act/2015/123/fr@2015~art_12
   Monica Palmirani:great
   Fabio Vitali:/akn/eu/act/2015/123/fr@2015!main~art_12
   parisse:~art_12.doc (with the only exception of the format)
   Fabio Vitali:/akn/eu/act/2015/123/fr@2015!main/annex_1~art_12
   Fabio Vitali:/akn/eu/act/2015/123/fr@2015!annex_1~art_12
   Fabio Vitali:etc
   Fabio Vitali:main is ALWAYS optional
   Monica Palmirani:ok now manifestation
   Fabio Vitali:manifestation level features come BEFORE the component, except for format, which is at the end
   Grant Vergottini:So much complexity!!!!!!!!
   Fabio Vitali:why?
   Grant Vergottini:!@^#$@
   Fabio Vitali:there is no complexity, there is additional information
   Fabio Vitali:the URI does NOT change for documents without components
   Grant Vergottini:The problem is trying to explain this to people
   Fabio Vitali:Grant: you do not need this complexity until you actually need it.
   Fabio Vitali:Then the users themselves will ask for complexity
   parisse:I think that it must be mapped to the identification part of the document that is the attachment or the component
   Fabio Vitali:I believe we do not need TWO characters, and I believe ~ is enough for both component and fragment
   Grant Vergottini:The complexity should only become necessary when the situation arises where you need it. Otherwise, to the user, it appears as unnencessary
   Fabio Vitali:but if this cannot be reached, then I am fine with two characters, AS LONG AS format goes to the end
   Fabio Vitali:In this proposed situation, complexity does not arise unless you have complex documents
   MonicaPalmirani:/akn/eu/act/2015/123/fr@2015!annex_1~art_12.xml  what is the rpoblem with that?
   Monica Palmirani:simple case
   Monica Palmirani:nothing more
   Grant Vergottini:I'm good with that
   Fabio Vitali:I can live with it
   Monica Palmirani:noooo
   Monica Palmirani:/akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12
   Fabio Vitali:ONE !
   Fabio Vitali:If you have a complex hierarchy of components, you use /
   Fabio Vitali:NOOO
   parisse:one syntax, but different separator
   Fabio Vitali:/akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12
   Monica Palmirani:why veronique you have this need ? it seems to me that is a problem of tool
   Monica Palmirani:in your syntax I can say  /akn/eu/act/2015/123/fr@2015!annex_1/annex_3 using the natural hierarchy of URI
   Fabio Vitali:I need to go now. I vote in favor for the current syntax. Please record this. I am not particularly willing to make any additional compromise
   parisse:In the first part of the IRI, the / separe different information ; in the component part, it is used for hierarchisation.  But we have already __ for that
   parisse:so for me  /akn/eu/act/2015/123/fr@2015!annex_1__annex_3~art_12 is more clean
   Monica Palmirani:current syntax is a big concept Fabio .... what is the current syntax
   Monica Palmirani:Veronique you are mixing different syntaxes and using / it is for sure more clear for the user
   Grant Vergottini:The __ is only used for assembling an identifier. I don't think if should be used to concatenate identifiers as well.
   Monica Palmirani:Right! Grant
   Monica Palmirani:so Veronique
   Monica Palmirani: /akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12
   parisse:it is not concatenation, it is hierarchisation
   Monica Palmirani:__ is not a hierarchisation
   Grant Vergottini:__ is for concatenation, / is for hierarchisation (is that a word?)
   Monica Palmirani:please consider that the people want to compose the URI using granular parts /
   Monica Palmirani:ok it is clear
   Monica Palmirani:I would like to vote a syntax
   Monica Palmirani:we MUST go in public review
   parisse:for the component ? yes : the annex 3 of the annex 2 is the same as the paragraph 3 of the article 2
   Monica Palmirani:soon
   Monica Palmirani:no
   Monica Palmirani:annex 3 and annex 2 are not like paragraph 3
   Monica Palmirani:so if there are no other important objections in term of use-cases  I would like to vote
   parisse:or /akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12/para_1
   Monica Palmirani:MOTION: /akn/eu/act/2015/123/fr@2015!main/annex_1~art_12 with main optional; /akn/eu/act/2015/123/fr@2015!main/annex_1~art_12.xml for manifestation
   Grant Vergottini:+1
   Monica Palmirani:+1
   parisse:Do you prefer  /akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12/para_1 or  /akn/eu/act/2015/123/fr@2015!annex_1__annex_3~art_12__para_1
   Grant Vergottini:I think Fabio's vote is implied?
   Monica Palmirani:yes
   Monica Palmirani:FABIO:+1
   Monica Palmirani:APPROVED.
   Monica Palmirani:thanks
   parisse:Do you prefer  /akn/eu/act/2015/123/fr@2015!annex_1/annex_3~art_12/para_1 or  /akn/eu/act/2015/123/fr@2015!annex_1__annex_3~art_12__para_1
   Grant Vergottini:First one
   Grant Vergottini:But I must go now. My next meeting starts in 3 minutes
   Monica Palmirani:me too
   parisse:ok, we replace everywhere __ by /
   Monica Palmirani:noo
   Monica Palmirani:art_12__para_1
   Monica Palmirani:is the internal id
   parisse:yes see the answer of grant
   Grant Vergottini:__ for internal Id
   Monica Palmirani:we need to discusse
   parisse:it is not logical
   Monica Palmirani:yes it is
   Grant Vergottini:Ok. next time. Biut I really must go no
   Grant Vergottini:now
   Monica Palmirani:because you distinguish component to the internal fragment of the document
   Monica Palmirani:next
   Monica Palmirani:next is 25
   Monica Palmirani:please prepare also the invoices
   Monica Palmirani:Grant and Veronique
   parisse:you use the same / for hierachisation and separation of information : akn/eu is not the same as annex_1/annex_2
   Monica Palmirani:no the annex are component and _para is fragment
   Monica Palmirani:Next time 25 nov.
   Monica Palmirani:Invoices please
   parisse:in the first part, it is separation of information, in the second part, it is hierarchisation of component
   Monica Palmirani:bye
   Monica Palmirani:we will discuss the next time the art_2__para_1
   parisse:can you give more info on the invoice I can do ?
   Monica Palmirani:or art_2/para_1
   Monica Palmirani:yes by email
   Monica Palmirani:ok thanks
   Monica Palmirani:ciao

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]