Tags:
create new tag
, view all tags

This topic is documented in TWikiMetaData and closed - start new MetaDataDev topic for further discussion (and search for existing related topics).

See:



Current version: 1.0

Table of contents

Example of format

%META:TOPICINFO{version="1.6" date="976762663" author="PeterThoeny" format="1.0"}%
   text of the topic
%META:TOPICMOVED{from="Codev.OldName" to="CoDev.NewName" by="JohnTalintyre" date="976762680"}%
%META:TOPICPARENT{name="NavigationByTopicContext"}%
%META:FILEATTACHMENT{name="Sample.txt" version="1.3" ... }%
%META:FILEATTACHMENT{name="Smile.gif" version="1.1" ... }%
%META:FORM{name="WebFormTemplate"}%
%META:FIELD{name="OperatingSystem" value="OsWin"}%
%META:FIELD{name="TopicClassification" value="PublicFAQ"}%

General notes

  • Format is as for TWikiVariables, except all fields have a key.
    • %META:<type>{key1="value1" [key2="value2" [...]]}%
  • Order of fields within the meta variables is not defined, except that if there is a field with key name, this appears first for easier searching (note the order of the variables themselves is defined)
  • Each meta variable is on one line
  • '\n' is represented in values by %_N_ and '"' by %_Q_%

Logical order

There no absolute need for meta data to be in a specific order, however, it does for the following reasons:

  • Keep (form) fields in the order they are defined
  • Allow diff command to give output in a logically sensible order

These could be done in other ways, but this adds complexity

  • Order fields - definition could be read on each rendering (expensive)
  • Diff - render data before doing diff, has something to offer, but not likely to be available for next TWiki release

So the order is:

  • TOPICINFO
  • text of topic
  • TOPICMOVED - optional
  • TOPICPARENT - optional
  • FILEATTACHMENT - 0 or more entries
  • FORM - optional
  • FIELD - 0 or more entries (FORM required)

Specification

TOPICINFO

Key Comment
version Same as RCS version
date integer, unx time, seconds since start 1970
author last to change topic, is the REMOTE_USER
format Format of this topic, will be used for automatic format conversion

TOPICMOVED

This is optional, exists if topic has ever been moved. If a topic is moved more than once, only the most recent TOPICMOVED meta variable exists in the topic, older ones are to be found in the rcs history.

%META:TOPICMOVED{from="Codev.OldName" to="CoDev.NewName" by="talintj" date="976762680"}%

Key Comment
from Full name i.e. web.topic
to Full name i.e. web.topic
by Who did it, is the REMOTE_USER, not WikiName
date integer, unx time, seconds since start 1970

Notes:

  • at present version number is not supported directly, it can be inferred from the RCS history.
  • there is only one META:TOPICMOVED in a topic, older move information can be found in the RCS history.

TOPICPARENT

Key Comment
name The topic from which this was created, WebHome if done from Go, othewise topic where ? or form used. Normally just topic, but is full web.topic format if parent is in a different Web. Renaming a Web will then only break a few of these references or they can be scanned and fixed.

FILEATTACHMENT

Key Comment
name Name of file, no path. Must be unique within topic
version Same as RCS revision
path Full path file was loaded from
size In bytes
date integer, unx time, seconds since start 1970
user the REMOTE_USER, not WikiName
comment As supplied when file uploaded
attr h if hidden, optional

Extra field that are added if an attachment is moved:

movedfrom full topic name - web.topic
movedby the REMOTE_USER, not WikiName
movedto full topic name - web.topic
moveddate integer, unx time, seconds since start 1970

FORM

Key Comment
name A topic name - the topic is a FormDefinition. Can optionally include the web name i.e. web.topic, but doesn't normally

See: FormTemplateSystem

FIELD

Should only be present if there is a FORM entry. Note that this data is used when viewing a topic, the form template definition is not read.

Key Name
name Ties to entry in FormDefinition, is title with all bar alphanumerics and . removed
title Full text from FormDefinition
value Value user has supplied via form

Other

There is currently no support for meta data for Plugins. However, the format is readily extendable and the Meta.pm code that supports the format only needs minor alteration.

Questions

  • [ JohnTalintyre ] If title is there, why not tooltip ? Would it be easier to just read in the form definition on view or should tooltip be added here?

  • [ MartinCleaver ] To make the design orthogonal, can we be able to use a TWiki.Form to edit the MetaData ?
    • [ JohnTalintyre ] I don't understand this. The forms own meta data is of course editable in forms, the other data isn't, with the exception of some attachment information, that comes from forms. Most of the rest should not be editable.
      • [ MartinCleaver ] By mere mortals, I agree. But, logically the meta data is a set of name-value pairs, so an orthogonal design might only restrict such facility due to policy, not by design. I'm not sure this explanation is clear, will look again! * [ JohnTalintyre ] Meta data is directly editable by administrators (for fixing problems)

-- MartinCleaver - 27 Jun 2001

Can we reserve part of the meta data namespace for a plug-inīs own use? I am thinking that we might one day have a plugin that gets invoked by WebStatistics that trawls through the stats and assigns stats on a per-page basis. That plugin would need a place to store its data.

-- MartinCleaver - 28 Jun 2001

Whilst we don't have APIs for it now, there's no reason in principle why a plugin couldn't have it own meta data e.g. = %META:PLUGIN:name{...}%. But, if the idea is to save data in many topics at a time then the change information will be confused - the down side of meta data being in the topic.

-- JohnTalintyre - 28 Jun 2001

Lets think about user (aka plugin) definable meta data after the pending release.

-- PeterThoeny - 28 Jun 2001

Sure, I just wanted the namespace carved up. BTW: Would %META::CORE::name{...}% have any advantage over just %META::name{..}% ?

-- MartinCleaver - 29 Jun 2001

It's actually META:name. I can't see any real advantage to have CORE there too.

-- JohnTalintyre - 30 Jun 2001

  • [ PeterThoeny ] - user should be REMOTE_USER name, not WikiName
    • [ JohnTalintyre ] - all changed to this
    • [ MartinCleaver ] Why? When do we ever show the TWiki.REMOTE_USER? Donīt we trust WikiName?
    • [ PeterThoeny ] TWiki already tracks two user names, the REMOTE_USER name stored in $TWiki::userName (i.e. pthoeny for intranet login name), and the WikiName stored in $TWiki::wikiUserName (i.e. Main.PeterThoeny). The function userToWikiName( $userName ) is used to map the REMOTE_USER to the Wiki user name. Storing the original $TWiki::userName is more flexible and more robust.
    • [ EdgarBrown ] I would have to disagree Peter, the WikiName is less likely to change than the REMOTE_USER, after all, the remote user name can be changed by just editing a field in a page, or by the whim of a system administrator (just imagine a bad security problem, or even an e-mail flood), the WikiName would probably only change for legal reasons ;^).
    • [ MartinCleaver ] I vote use the WikiName.

    • [ MartinCleaver ] How about showing their IP address or DNS Name?
    • [ MartinCleaver ] Can we escape newlines and double quotes but permit them?
    • [ JohnTalintyre ] user is already stored in RCS are REMOTE_USER so it's consistent to do these same in meta tags.


Last thought before this become this becomes 1.0 format.

We could simplify some of the names i.e.:

  • TOPICINFO to INFO
  • TOPICPARENT to PARENT
  • TOPICMOVED to MOVED
  • FILEATTACHMENT to FILE

Votes?

-- JohnTalintyre - 08 Aug 2001

(Beside the point: somehow I've missed (or forgotten) a lot of this discussion, yet I subscribe to WebNotify. Must be getting old.)

Instantly, PARENT, MOVED, and FILE seem simple and unambiguous (I can't immediately think of what they would be confused with). On the other hand, INFO seems somewhat ambiguous. Again, this is from a distance -- if it is not ambiguous, or unlikely to be confused with something else, I think my fingers would like the shorter form.

Is there (or is there likely to be) another variety of INFO, like WEBINFO or TWIKIINFO? The more I think about it, the more I think that INFO is clear in the context, and to use TOPICINFO and not TOPICPARENT, for example, would tend to be another potential source of confusion. (But I'll admit my thinking is rather shallow.)

I vote the short form for all four.

-- RandyKramer - 08 Aug 2001

I vote we use either form, but they as WikiWords. That way:

  1. we can have topics that talk about them
  2. they are more readable as they are less JarringToTheEye

And... I think prefixing stuff with TWiki looks like a fudge for not allowing SingletonWikiWords.

Also I'd vote TOPICINFO becomes TWikiHeaders

-- MartinCleaver - 09 Aug 2001

Not much feedback no this, so keeping the names as they were.

-- JohnTalintyre - 16 Aug 2001

Edit | Attach | Watch | Print version | History: r29 < r28 < r27 < r26 < r25 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r29 - 2003-02-27 - AdamSpiers
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.