Template talk:Document

TODO List

1. A parameter |Description
2. A parameter |Occasion = |ImmediateCause = |WhatPromptedThis for why these documents came about. e.g. A death certificate tied to a death event
3. A parameter |Location, useful for speeches.
4. A parameter |ProductionDate
5. Rethinking the |SeeAlso parameter - maybe replace by a set of "relates to" links
6. Date Format Standardisation

Description

A mandatory 3-4 sentence summary of posted documents could make browsing much easier while using automatically tables, e.g. using Property:Description. Robin (talk) 06:15, 21 December 2013 (GMT)

Production date

A separate parameter for when documents are made as opposed to when they are published may be needed (e.g. especially for leaked documents). However property:Creation date already exists - a special property for when pages were created on this wiki. Robin (talk) 06:15, 21 December 2013 (GMT)

SeeAlso

This is currently freeform text, but where it is used, it tends to be a bulleted list of links. This suggests that replacing text with a more tightly specified semantic markup may be a better way to go, combined with a new property, ~ "relates to". This would allow dynamically built lists and have the advantage that the data was available for other purposes. It might be a good idea to keep a human readable chunk, and make a threesome such as we use for source e.g. |related, |relatedURL, |relatedDetail Robin (talk) 06:15, 21 December 2013 (GMT)

Date Format Standardisation

Semantic wiki seems to parse dates OK for its own purposes, but I'm not entirely happy with its handling of incomplete dates. "2013" =/= "Dec 2013" =/= "1 Dec 2013" and it should be possible to input on of the two former ones if one doesn't know a specific day and or month. It would be convenient and tidy if SMW were good enough at date processing, but at the moment I'm still not sure it is. If we could highlight specific deficiencies (e.g. in Semantic Forms input capabilities?) we could forward these concerns to the developers. Robin (talk) 06:15, 21 December 2013 (GMT)

Form lagging a bit

I hesitate to mention this with all the stuff you're doing but 'Form:Document' needs to reflect all these additions sometime soon aswell. --Peter P (talk) 18:31, 24 December 2013 (GMT)

Comma separated lists

I'm aware that Form:Document is lagging. My first priority is to get the underlying data format straight. I see one more technological upgrade for this template on the immediate horizon - the replacement of hardcoded (and limited) numbered lists with comma (or other character) separated lists - which potentially could make for cleaner code and an easier interface. |SeeAlso needs an upgrade to I'll try it with that. Robin (talk) 14:39, 30 December 2013 (GMT)

Dates issue following recent Forms upgrade to v2.6.1

I noticed an apparent bug soon after this upgrade. Tried to track the issue down a couple of times without success. Thought is was the form u-grade but it turns out that was only what made it apparent, in that the form no longer filled in a blank day as '1'. Briefly, if day is not completed, a weird 'expression >' error appears in bold-red, just below the DocProv section of the document. It does NOT happen if only the year is completed, neither if the date in entered in the form monthname/yyyy by non-form editing. Also, it does not happen if the alternative ISO date params are used with the day left out.
Not sure how best to deal with this because I reckon it is a pretty fundamental requirement that documents can be reliably created and edited using the form - In fact for new editors it probably ought to be mandatory.
I'm still a bit distracted with server issues - tearing my hair out trying to get TLS IMAP email working (Dovecot/Postfix). However, since I can still send and received domain.com email OK I intend to shelve it for a bit and spend some time tweeking the Documant form using tabs to separate the mandatory from the various optional/doctype-specific sections.
If you have any ideas on how to fix that damn bug please have ago. You'll probably get there a lot faster than me anyway. --Peter P (talk) 13:19, 21 January 2014 (GMT)

Reinstatement of FileProv

I propose to reinstate Template:FileProv and create a separate form for it. This is in anticipation of moving to a few more dedicated namespaces. Both the form and template will be very similar to the existing ones but a couple of annoying anomalies can be removed - like the 'local copy' parameter and use of the Document Namespace variable doing odd things to 'File' namespace page edits which bother me and may be storing up trouble. I've put off editing loads of files whilst cogitating about this and would like to get on with them using a dedicated form. I think it would be good to deprecate all those extra subjects in favour of the comma-delimited list approach too. That way a single 'additional info for the entire subject group can be used. It will be much easier to use the form and should produce a clearer display too - though there are pitfalls, notably where existing page names contain commas. That will have to be addressed I guess. Thoughts? --Peter P (talk) 16:42, 4 February 2014 (GMT)

Namespaces - Probably a good move.

Commas in titles - The current technology (#arraymap) doesn't actually require use of commas as separators, though it is the most natural character to me, another sequence could be used. How many pages are there with commas in the title? Unless it's more than a handful, I say keep commas as separators and just botch the titles to exclude that character.

Separate template - I see no benefit from this. Instead I suggest vary behaviour by namespace with a #if block. This is not hard, and will prevent having multiple copies of code, which is not a good road to go down. What's needed to move forward with this is a list of the stuff to vary by namespace. Robin (talk) 22:37, 4 February 2014 (GMT)

OK I guess the 'document' issue is pretty much a legacy one-off anyway. So the principal to adopt is that a template can (in general theoretically and in this case practically) be used for pages in more than one namespace; any differences in usage to be noted against template parameters + conditional display code blocks and reflected in separate form design elements. Form differences in this case will be minor too, since the localcopy field is required in both - just treated slightly differently but using separate forms will address the red-link auto-form-use issue which I reckon is a big plus. I doubt the Comma issue is much of an issue at all, especially since pages so listed are likely to be a relatively small sub-set, so we'll stick with commas and see what happens. The template will need another field though - ie a generic description for the subject list. I'll work on all this over the next few days. --Peter P (talk) 07:21, 7 February 2014 (GMT)

Differences between file and document use of this template

• |localCopy = Only needed for the document: namespace, should link to an item in the file: namespace.