From: Brian I. <in...@tt...> - 2002-07-21 18:05:53
|
On 21/07/02 13:53 -0400, Clark C . Evans wrote: > overview: > > Howdy! Just had a short IRC chat with Brian, and basically he seems > to agree, with some modifications. Brian, if I mis-speak, please > correct me. > > proposal: > - > > Revise the specification to only allow HTTP schema type, while > we are at it, the domain name should be forced to be small-caps > and should not allow for #fragments. > - > > Revise the specification so that the target of the HTTP type-family > shall be a "resource index". A resource index is a single YAML > document with a top level map. > - All keys are scalars. > - Those keys containing a period are domain > names and their content can be defined by > the domain name owner > - Remaining keys, without a period, are > reserved for yaml.org usage > - > > Specify that YAML processes may want to fetch such indexes, > and should cashe indexes if possible. The HTTP "expires" > header should be used for this purpose. When a YAML document > is fetched, the expiration date given can be added to the top > level map with an "expires" key which is the timestamp > retrieved via HTTP header. This allows for a directory of > indexes to be maintained locally and updated as appropriate. > - > > We specify that !str is equivalent to http://type.yaml.org/str > and update things appropriately. > - > > For website maintanence ease, we setup XXX.yaml.org to point to > yaml.org/XXX and populate all types with appopriate information. > - > > We make up an initial "format" for these resource bundles > which is not part of the specification (but the existence of > the bundles is). We were thinking keys could include "title" > for a short, 60 character snappy name for the type family, > "summary" for a longer description of the title, and > "example" for a sequence of usage examples. Later on we > could add "schema", etc. > > notes: > - > > Brian mentioned that it would be cool if our type repository > was setup as a wiki or some way that people can propose updates > to our various type index files. This was a joke. > - > > This is a dramatic change; but it is also very restrictive, > we can loosen things up later if we find it is necessary. > > Best, > > Clark > > On Sun, Jul 21, 2002 at 11:33:54AM -0400, Clark C . Evans wrote: > | overview: > > | We need to quickly review "What is a type family?" decisions > | and make any last-minute tweaks. This review is necessary since > | most of the decisions were made well over a year ago and a bulk > | of you weren't even on board at that time or were concerned about > | many other of our important topics. > | > | summary: > > | The type-family mechanism is primarly there to encode type and > | class information within YAML. A URI was provisionally chosen > | since this provides for a pre-built framework for deriving > | globally unique identifiers (based on DNS). > | > | xml: > | - > > | XML uses URIs for its "namespace-name". Thus, about a year ago, > | when one contemplated use case for YAML was to allow existing > | XML to be mapped as YAML, it seemed natural to use URIs for our > | type families, as this allowed for very clean namespace mapping. > | - > > | However, our type family isn't quite the same as a namespace name. > | In XML, each tag name (qname) is a (namespace,local-name) pair. > | In YAML, the equivalence isn't quite there. The closest we have > | to a element local-name is our mapping key. However, it would > | be butt-ugly (and not very useful) to apply type-families to > | each of these. Thus, its not clear how such a namespace name > | to type family mapping would happen; semantic differences aside. > | - > > | Wordse, I was just scanning XML-DEV for a while and once again, > | the namespace URI issue is the primary thread; this thread > | emerges about once a quarter and rages for at least a few weeks. > | It's clear to everyone on the list that something isn't quite > | right... but no one knows what it is. > | - > > | The history of namespace names are even messier, at one point > | they were allowed to be "URI references" which included > | relative URIs. I don't even want to go here, it's just a bad > | idea that Tim Berners-Lee is in-love with and most good-sensed > | XML people object to. > | - > > | The primary thing which a newbie asks: "Oh, this namespace > | is a HTTP URL, how come it doesn't point to anything?". This > | is beacuse an XML namespace name uses a URI only as a unique > | identifier, and nothing more. The result is that people have > | put anything (if something at all) at the end of the URI > | rainbow and there isn't any consistency; really such a useful > | pointer is just being wasted. This is why RDDL was proposed, > | but it (a good proposal) just lost steam. > | - > > | Another interesting aspect of XML is that it also has a > | schema mechanism, which is distinct from the namespace name. > | This mechanism causes a bunch of clutter in the document > | and seems redundant given that a unique namespace is > | already present; in 99% of the cases, the namespace name > | implies the schema. Yet the design of XML didn't take this > | into account. > | > | resources: > | - > > | Besides providing for a unique name, a type family could also > | provide a way to fetch resources about the type family, such as > | a human description of the type, a regular expression for validating > | scalar types, processing programs, mapping programs between > | various languages, schemas, etc. > | - > > | Regardless of our type family, some way to fetch resources > | about a given set of nodes will eventually be needed; XML seems > | to be somewhat handicap since it doesn't have such a mechanism. > | - > > | One of the resources is a schema, which for a mapping, could > | describe an entire sub-tree. Schemas are useful for validation, > | and other purposes. > | - > > | A resource mechanism for YAML could be very easy to specify > | without requiring a schema definition. In fact, it may be good > | to put this sort of definition within the YAML specification > | proper so that we have this sort of mechanism "up-front". > | - > > | A resource stream could be a YAML text with a single > | document, a mapping. The mapping could then have > | several defined keys. Domain names could also be used > | as keys, with the structure under that domain name defined > | by the organization who owns the domain. Example: > | - > | name: Short name of the type-family > | summary: > > | This is a multi-paragraph description of the > | type-family. It can say what ever it wishes. > | yaml.org: > | notes: > > | This is where YAML.ORG specific details go, for > | example, we could have a "schema" key here > | containing our schema, if it ever emerges. > | > | proposal: > | - > > | We "tighten" up the family-uri to only allow the "http" scheme > | this is the 99% use case, and the other options just make things > | hard to handle. > | - > > | We define explicitly what *must* be at the end of the "http" rainbow. > | Namely, it is a YAML resource as described above. In this way > | just about any information needed to process data of a given type > | family can be obtained in a non-biased manner. > | - > > | We define that anyone "fetching" the resource document must > | obey the HTTP "expires" header and cache the resource > | information appropriately. Thus, if a type family has an > | expiration several months out, the YAML processor shouldn't > | be constantly hitting the box asking for the family's resource > | bundle. > | > | notes: > > | I suggest this now since this handles most of the problems > | that have emerged on the XML-DEV list over the last 3-4 > | years. It is very restrictive up-front; but also quite > | intuitive. URIs are only http, and we've defined explicitly > | what they point to. This makes for a nice "closed" system. > | > | If we find we are wrong, we can always "open up" and > | be more flexible later... > | > | --- | > | Clark C. Evans Axista, Inc. > | http://www.axista.com 800.926.5525 > | XCOLLA Collaborative Project Management Software > | > | > | ------------------------------------------------------- > | This sf.net email is sponsored by:ThinkGeek > | Welcome to geek heaven. > | http://thinkgeek.com/sf > | _______________________________________________ > | Yaml-core mailing list > | Yam...@li... > | https://lists.sourceforge.net/lists/listinfo/yaml-core > > -- > Clark C. Evans Axista, Inc. > http://www.axista.com 800.926.5525 > XCOLLA Collaborative Project Management Software > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |