From: Clark C . E. <cc...@cl...> - 2001-12-16 23:39:53
|
IRC Meeting Minutes 16-DEC-2003; Present Brian and Clark 1. We would like to use ; instead of ~ The transfer method format is three part (namespace,typename,format). Since the typename is always mandatory, the namespace is always separated from the format. Thus, we can use ; to separate the typename from the format. This only requires that we restrict the typename so that it does not contain a semi-colon. 2. The use of absolute URIs for namespaces, !perl|type I very much like saying that a namespace *is* an absolute URI. However, I do like our short hand notation... !seq Should be given a default YAML namespace. !perl|type Should map to a nice namespace as well. Given that the colon does not appear in the name; thus, we can make this a short hand for a more verbose namespace So, how about we do this sort of mapping... transfer method namespace type --------------- ---------------------------------------- !type -> http://yaml.org/t/ , type !perl|type -> http://yaml.org/t/perl , type !java.lang|type -> http://yaml.org/d/java.lang , type !org.clarkevans|type -> http://yaml.org/d/org.clarkevans , type !http://boogle|type -> http://boogle , type !urn:pid:E34kfd|type -> urn:pid:E34kfd , type We provide semantics that abbreviations without a period must be approved by YAML mailing list. And those with a period are reverse DNS names and controlled by the domain owner. We make an exception for "java." since this is so prevalent. This has the distinct advantage of giving us wonderful XML compatibility, while making it simple for common use cases. Also, it doesn't require us registering a new URI scheme. See the end of the mesage for an alternative proposal 3. Implicit typing clairification Can we change "implicit" scalar back to "plain" scalar? This way, a plain scalar is implicitly typed when it is not explicitly typed. In this way we avoid the nasty case of content which is given an explicit type, but doesn't match an implicit type. 4. Dropping of the - magic: map I'd like to drop this one since it has too many implications and creates exceptions. Alternatively, we can just limit it to a single, one-line variant. I think Brian said that he'd rather drop it than have a limited variant... and I prefer dropping it to keeping a limited (or full) variant. 5. Character sets The spec needs to be clarified as to what we mean by printable unicode characters. Is this defined somewhere in the Unicode specification? In particular, is PS and LS included in the "printable" set? How about control codes. If we drop the printable restriction, then we need to explicity disallow C0 and C1 control classes, plus DEL, the surrogate pairs, etc. 6. Perl type/class problem. Brian said that @!$ works to solve this problem! Hurray! Best, Clark P.S. Here is the alternative proposal for the package names... I suggest that we create our own URI scheme [2], and register it. Let the scheme have two parts, the first part is a language (one of many choices registered via the pkg definition), and the second item (optional and separated by a semi-colon) is a valid package name within the language. Let's call this URI scheme "pkg". pkg:java:java.lang pkg:python:Some.Package pkg:yaml !seq -> ( pkg:yaml ,seq ) !perl|type -> ( pkg:perl ,type ) !pkg:java:tld.dns|class -> ( pkg:java:tld.dns ,class ) !http://yaml.org|class -> ( http://yaml.org ,class ) In this way we are contributing a uri scheme which is not YAML specific, yet covers a bulk of our needs. From what I gather, Brian thinks this is "ok", but I was rather vague on the IRC client, so I can't expect him to grok the implications. [1] http://www.ietf.org/rfc/rfc2396.txt http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/ [2] http://www.iana.org/assignments/uri-schemes http://www.w3.org/Addressing/schemes -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Brian I. <in...@tt...> - 2001-12-17 18:39:16
|
On 16/12/01 18:53 -0500, Clark C . Evans wrote: > IRC Meeting Minutes 16-DEC-2003; Present Brian and Clark > 3. Implicit typing clairification > > Can we change "implicit" scalar back to "plain" > scalar? This way, a plain scalar is implicitly > typed when it is not explicitly typed. In this > way we avoid the nasty case of content which > is given an explicit type, but doesn't match > an implicit type. Um, Clark. This was not discussed in our meeting IIRC. You are free to propose it but please don't make it sound like we've already discussed it. |