> But if anyone can think of an assertion that can safely be made if you
> can identify a specific field as being a UUID, please tell me.

Well, anything can be used as a uuid, the thing is, there needs to be
a protocol around communicating about tiddlers that tells you exactly
how it is defined, for example in the case of giewieki.

This protocol that I am talking about is not some serialization format
for tiddlers. Instead, it gives instructions on how to access any
resource that provides them by telling you what you can expect from
the resource once you do access it.

Let me try and to propose a draft that makes my line of thinking more
clear:

tidcom:{
        version:"http://tidcom.org/v1";,
        format:"json",
        standard:"http://tidcom.org/tiddler/v1";,
        extensions:{
                creator:{
                        lookat:'field',
                        params:{
                                field:'creator'
                        }
                },
        },
        uuid:{
                lookat:'field',
                params:{
                        field:'uuid'
                }
        }
        versioning:{
                method:'v1/versioning/ver1',
                params:{
                        foo:'bar',
                        baz:'mumble'
                }
        }
        branching:{
                method:'v1/branching/bra1',
                params:{
                        frotz:'gronk',
                        hello:'world'
                }

        }
}

So, the protocol defines the semantics used at some tiddler store -
semantics the variants of which are well defined in some "universally"
agreed upon, evolving standard protocol - that tells you, for example,
how versioning is being implemented. So, when you are referencing to a
source of tiddlers you would communicate this protocol and the
receiving end would have a precise clue of what exactly you're talking
about, because...

http://tidcom.org/v1

...would be the place that tells you exactly that.

There certainly are ways to streamline the suggestion above, for
example, a tiddler standard v0 could refer to the first tiddler
definition that didn't even have fields, v1 could include fields, v2
could include a uuid and creator field, etc... so that you wouldn't
have to specify these things under "extensions". Same goes for
versioning... if a given standard vX entailed a standard versioning
and branching definition, then there would be no need to specify these
things in the protocol, unless you had to specify, say, some required
parameters that are required to define your exact versioning pattern.

Makes sense?

tb

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To post to this group, send email to tiddlywiki@googlegroups.com.
To unsubscribe from this group, send email to 
tiddlywiki+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/tiddlywiki?hl=en.

Reply via email to