From: Oren Ben-K. <or...@ri...> - 2001-12-18 19:05:53
|
Clark C . Evans [mailto:cc...@cl...] wrote: > I was thinking, given the GUID example below, that > separating the "namespace" from the "type" may be > a bad idea. It is a very *good* idea :-) > Perhaps our | separator is just syntax > sugar. Consider the following two GUIDS... > > yaml://COM/GUID/{F3CA571F-C5DA-11CF-8F28-00AA006AAAAA} > yaml://COM/GUID/{F3CA571F-C5DA-11CF-8F28-00AA006FFFFF} > > I've seen the case where the left part of the GUID is > constant, while the right part varies from component > to component. What if... Which AFAIK is an abuse of the GUID system. I think they are supposed to be randomly generated each time... > In other words, the | is just a function of the syntax model, leaving > all objects in the system with just a family and format. Problems with this: languages use characters which are not allowed in a URI, like '{'. Also you no longer use a tandard hierarchical URI. It is simply a two part one, better written as: !yaml:lang:lang-specific-id Where the '|' can appear anywhere you want. !yaml:any:org.yaml.|seq !:any:org.yaml.|seq !::org.yaml.|seq !seq Note that such a URI is not allowed to contain '/' - these are only allowed in valid hierarchical URI structures. So you'd have to encode IANA names: !yaml:iana:image%??gif Ugh. > This would mean... that the period is needed after lang ... Oh yes. That too. > In other words, the | acts as a very very simple splitter > to save typing. It is only a syntax device... I kinda like > this notion. > > --- !perl/Net::|Ftp Actually !:perl:%25Net::|Ftp Brian would have kittens... > This saves us the whole headache of defining what > is a namespace vs what is a class name. No it doesn't. There's no such headache for Java because it has a global namespace mechanism. Perl is second best because it has an agreed upon mechanism - even if it uses a flat namespace :-) C++ will be a pain in whatever organ because it has no such mechanism, and it doesn't matter what you do, it will be a headache. Got to go... Oren. |
From: Brian I. <in...@tt...> - 2001-12-18 20:10:30
|
On 18/12/01 21:06 +0200, Oren Ben-Kiki wrote: > > --- !perl/Net::|Ftp > > Actually !:perl:%25Net::|Ftp > > Brian would have kittens... Yes, he would. Brian is having kittens over the whole discussion of breaking up or shortening Perl namespaces. It won't be generally useful for Perl. Sometimes I wish that Perl was this hierarchical, but it ain't. So all of your proposals along these lines don't make life any better. Perl namespaces should always be specified in full. So I am sticking with '%' for hash based objects just to be a PITA. :) Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2001-12-18 21:10:03
|
I'm convinced neither of you two read what I wrote. On Tue, Dec 18, 2001 at 09:06:31PM +0200, Oren Ben-Kiki wrote: | Clark C . Evans [mailto:cc...@cl...] wrote: | > I was thinking, given the GUID example below, that | > separating the "namespace" from the "type" may be | > a bad idea. | | It is a very *good* idea :-) Brian convinced me (after some thinking and seeing the COM example) that drawing a distinction between namespace and the class is not a productive thing to do. Logically, Net::Ftp is a single component and shouldn't be broken up. I'm now having flash-backs of the qname problems in XSLT. Yuck. I hate qnames. It should be a single opaque string in the format that the programmers from the particular language are familar. On Tue, Dec 18, 2001 at 12:10:20PM -0800, Brian Ingerson wrote: | Brian is having kittens over the whole discussion of breaking up or | shortening Perl namespaces. It won't be generally useful for Perl. | Sometimes I wish that Perl was this hierarchical, but it ain't. So all | of your proposals along these lines don't make life any better. Perl | namespaces should always be specified in full. Right. Imposing hierarchy isn't a good idea. I'm not proposing to break them up. I'm proposing a very very dumb short-hand mechanism (^) to save typing. If you don't want to use it... no problem! But please read the proposal before you hatch your kittens on me. | So I am sticking with '%' for hash based objects just to be a PITA. :) Please consider my compromise on this one: Type | Marker -----------+---------- Scalar | $ Array | @ Subroutine | & Typeglob | * Hashtable | <unmarked> In short, the URI syntax (which isn't ours, so we cannot change it) allows for ;?:@&=+$,-_.!~*'() characters. Unfortunately, % is not in there since it is used for escaping. So... the question is; will the above work? If so, then *cool* our "typename" can be a _single_ unit (not a namespace, localname pair) that happens to be a URI. Hurray. Just think of it this way, with the compromise, you shed one character, | Summary of cases... 0. Perl !yaml:perl/Net::Ftp !perl/Net::Ftp !perl/SomeHashtable !perl/@SomeArray !perl/$SomeScalar !perl/&SomeSubroutine !perl/*SomeTypeGlob 1. IANA Names (no problem, just cannot abbreviate) !yaml:iana/image/gif 2. COM Identifiers (no problem, just don't use the {} ) !yaml:com/F3CA571F-C5DA-11CF-8F28-00AA006AAAAA !com/F3CA571F-C5DA-11CF-8F28-00AA006AAAAA 3. Java names (no problem!) !yaml:java/java.lang.String !java/java.lang.String 4. Arbitrary absolute URIs (no probelm!) !http://google.com/some-path?x=23?&y=33 5. Reverse DNS based names (no problem!) !yaml:any/com.clarkevans.timesheet !any/com.clarkevans.timesheet !com.clarkevans.timesheet 6. Built-in YAML names (easiest) !yaml:any/org.yaml.seq !any/org.yaml.seq !org.yaml.seq !seq 7. XML Mapping Let's use rddl:resource for an example (openhealth.org/RDDL) We use a character not in '.' | '-' | '_' | ':' to separate the namespace from the local part. So, this should do it. !http://www.rddl.org/;resource To unpack, simply start at the left, when you hit the ;, you know everything before this is the XML namespace I hope this helps! Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Brian I. <in...@tt...> - 2001-12-19 02:09:04
|
On 18/12/01 16:23 -0500, Clark C . Evans wrote: > I'm convinced neither of you two read what I wrote. Perhaps you write too much ;) > Please consider my compromise on this one: > > Type | Marker > -----------+---------- > Scalar | $ > Array | @ > Subroutine | & > Typeglob | * > Hashtable | <unmarked> I'll go with it. The ambiguous case now is: !perl/glob But I can make a special case for that. (BTW, A glob is a native Perl type) How about: !perl/.glob > !perl/Net::Ftp > > !perl/SomeHashtable > !perl/@SomeArray > !perl/$SomeScalar > !perl/&SomeSubroutine > !perl/*SomeTypeGlob !perl/~SomeRegex > !yaml:iana/image/gif > |
From: Clark C . E. <cc...@cl...> - 2001-12-19 02:14:20
|
On Tue, Dec 18, 2001 at 06:08:11PM -0800, Brian Ingerson wrote: | > Type | Marker | > -----------+---------- | > Scalar | $ | > Array | @ | > Subroutine | & | > Typeglob | * | > Hashtable | <unmarked> | | I'll go with it. Hurray! | The ambiguous case now is: | | !perl/glob | | But I can make a special case for that. Any of the following characters are avaliable: ;?:@&=+$,-_.!~*'() | !perl/.glob Sure. | !perl/~SomeRegex Sure, both . and ~ are in the list of valid URI characters above. Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Oren Ben-K. <or...@ri...> - 2001-12-18 20:59:49
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | Note that such a URI is not allowed to contain '/' > > Actually, over lunch I figured that the uri_part > production can contain '/' without any problem. It > just requires that IANA names are always written > without the abbreviation: !yaml:iana/image/gif From the RFC: absoluteURI = scheme ":" ( hier_part | opaque_part ) opaque_part = uric_no_slash *uric ^^^^^^^^ No, you *can't* write !yaml:iana/image/gif. This would be a *relative* URL with 'iana/image/gif' being the path, and an unspecified authority. You *could* write yaml://iana/image/gif - but that would mean we are back to the current proposal... You'll just need to use some other character to separate language and space. And encode the '/' somehow (you could replace it by '.' for IANA for the sake of readability). yaml:iana:image.gif But this would break the shorthand mechanism: No period and no ':': !seq == !yaml:any:org.yaml.seq A period and no ':': !com.clarkevans.timesheet == !yaml:any:org.yaml.timesheet Just one ':': !java:java.lang.Integer == !yaml:java:java.lang.Integer PROBLEM: !perl:Net::Ftp - OOPS. So it can't be ':' unless you prefix it: !:perl:Net::Ftp - no problem. However it is better to not use ':'. Say we use '!' instead: !yaml:perl!Net::Ftp !perl!Net::Ftp !yaml:any!org.yaml.int|dec !any!org.yaml.int|dec !org.yaml.int|dec !int|dec Hmmm... As for using '^' for separating it... Ugly as sin, right? Let's see the alternatives: !yaml:any!org.yaml.^int|dec !^int|dec !yaml:any!org.yaml.`int|dec !`int|dec !yaml:any!org.yaml.\int|dec !\int|dec !yaml:any!org.yaml.|int^dec !|int^dec !yaml:any!org.yaml.|int`dec !|int`dec !yaml:any!org.yaml.|int\dec !|int\dec I think the latter are best. Say | for splitting, \ for format? Another issue: !http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ? |html We'd have to put something instead of '?' above (and '?' won't do). A '/' I guess: !http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd/|p Hmmm... I guess I could live with that... It does solve a part of the problem (not ALL the problem... just a part). That is if Brian can live with writing: !perl!Blessed::Hash !perl!@Blessed::Array !perl!$Blessed::Scalar Brian, does that work for you? Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-12-18 21:13:16
|
| absoluteURI = scheme ":" ( hier_part | opaque_part ) | opaque_part = uric_no_slash *uric | ^^^^^^^^ | No, you *can't* write !yaml:iana/image/gif. Yes you can. Look at the production again. The short-hand mechanisms are just fine. I thought this one through I did. | Hmmm... As for using '^' for separating it... | Ugly as sin, right? Let's see the alternatives: ... | I think the latter are best. Say | for splitting, \ for format? Fine. Although I like ^ for splitting and | for format. | !http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ? |html I suggest using a semi-colon, but really any non-qname character valid in a URI will do it. | That is if Brian can live with writing: | | !perl!Blessed::Hash | !perl!@Blessed::Array | !perl!$Blessed::Scalar | | Brian, does that work for you? I hope so. Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Clark C . E. <cc...@cl...> - 2001-12-18 21:26:40
|
Oren, Sorry for yepiing! From your last post you just want to use differnet characters? --- - clark: !yaml:any/org.yaml.^int|hex oren: !yaml:any!org.yaml.|int\hex - clark: !perl/Blessed::Hash oren: !perl!Blessed::Hash - clark: !perl/@Blessed::Array oren: !perl!@Blessed::Array - clark: !yaml:iana/image/gif oren: !iana!image/gif - clark: !int|hex 0x29 oren: !int\hex 0x23 No substantive disagreements then? *winks* Clark |
From: Oren Ben-K. <or...@ri...> - 2001-12-18 23:37:51
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | absoluteURI = scheme ":" ( hier_part | opaque_part ) > | opaque_part = uric_no_slash *uric > | ^^^^^^^^ > | No, you *can't* write !yaml:iana/image/gif. > > Yes you can. Look at the production again. The > short-hand mechanisms are just fine. I thought > this one through I did. *Blush* Right - it just can't start with a slash. Sorry... As for the characters to use... I like '|' for splitting. Remember we'll be using the splitting *much* more often than using a format specifcation, so I'd much rather have a less-nice format specifier than a less nice split-specifier. I think ` would be better than ^... !yaml:language/language-ty|pe`format Even better: think of a format as a "fragment" in the absolute URI of the type: !yaml:language/language-type#format RFC2396 explicitly says that an absolute URI does not have fragments... so the above is safe and supported by URI tools, and also naturally expresses the relationship between a format and a type. The only problem is that if the URI refers to a real entity, the fragment part would not necessarily work... Finally there's the issue of combining an XML URI with an XML tag name to get another URI. Using '#' is very tempting, but the result isn't a URI (as URIs can't have fragments). You wrote: > I suggest using a semi-colon, but really any non-qname character > valid in a URI will do it. So... any character which can't be in an XML tag name, but is valid in a URI... !http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;html I guess so. OK. It is better than '/'... Now, about URI, escaping, etc. OK, In understand how a URI can contain any Unicode character in a standard (UTF-8) way. Fine. And the XML precedence means we are allowed to escape characters in there using \x \u \U - also fine. So the parser: - expands escapes - encodes in UTF-8 - escapes anything which isn't a valid uric (URI character). So far, so good. But you also wrote: > This is the behavior expected of an XML parser. XML uses '&entity; escaping but is otherwise identical (I presume). > It > allows "unicode" in the URIs, but makes it the parser's > job to do the escaping so that the application really > sees a URI So far so good... > (and a normalized one at that, where > characters that don't need to be escaped are not > escaped, etc.). Here I have a big problem. Do you mean the parser is responsible for escaping the URI in the "canonical" format? For example, suppose I have the URI: http://a.b/a\x90\x92b/c Is it the parser's job to know that \x90 can be safely written in unescaped format ('Z'), while \x92 can't (it would be a '/' and change the semantics of the URI)? If you do mean that, there's a problem because AFAIK it is impossible to do this in a scheme independent way. It seems to me that the parser must take any \... escape sequence and convert it to %... sequences regardless of what character it is. It is the responsibility of whoever is writing the URI into the YAML file to ensure that: > This will allow for name > comparisons, etc. Or... is there a scheme-independent algorithm for deciding which characters should be escaped and which shouldn't? From a cursory reading of the RFC it seems there isn't (and I put wording to that effect in the draft I sent you). For example, in some schemes the character '@' would have to be escaped as it separates a user name from a host name. In others (our yaml: scheme, at least for yaml:perl/...), it wouldn't have to be escaped. And so on... Anyway, let's summarize this as a YAC (#8): - Type family is a globally unique URI. - Transfer method is a URI followed by an optional fragment specifying a format. - XML namespaces are translated by using ';' as the glue character between space and tag. - The parser works like in XML - unescapes \ codes first, encodes as UTF-8, and escapes to % format any byte which isn't a URI char *or is a char that was escaped using a \ code or was escaped using a % code*. - The URI writer is responsible for ensuring the result is the single unique canonical normalized format of the URI (since normalization is scheme specific). - The '|' character can appear anywhere in the URI, and is used for relative names. - Defaulting is done (as you described), if there is no colon: - If there is a slash, "yaml:" is prepended. - Otherwise if there is a period, "yaml:any/" is prepended. - Otherwise "yaml:any/org.yaml." is prepended. Possible variants: YAC#8.?: Change the characters from '#' (format), '|' (split) and ';' (glue) to something else... YAC#8.?: Require the parser to normalize URIs using the following algorithm... Does that properly summarize the YAC? OK, now (finally) to whether I like it or not. Let's see: Benefits: - URI per name rather than per space. So we can talk about "THE" type name. Good. - XML namespaces are handled... somehow. OK. - '|' a syntactical shorthand only, which should work for anything at all. Brian happy. - URI can reflect the language's naming convention as closely as practical in the URI character set. Brian still happy - ``!perl/Net::Ftp'' works. Downsides: - Additional explicit glue character required. Only when specifying the full URI, however, which is pretty rate (that's the whole point of '|'). Acceptable... - Additional parser complexity. We've been there... Acceptable I think. Examples: !seq !int#dec !com.clarkevans.|invoice !|client # Hey Brian - look, no '|'! !perl/Net::Ftp Hmmm. OK, I'll go for it, under the following conditions :-) - Brian likes it. - Starting from right now, everyone who proposes a YAC is responsible for updating the draft and the YAC list accordingly. :-) I'll be happy to review it :-) :-) Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-12-19 00:01:55
|
| As for the characters to use... I like '|' for splitting. Remember we'll be | using the splitting *much* more often than using a format specifcation, so | I'd much rather have a less-nice format specifier than a less nice | split-specifier. I think ` would be better than ^... | | !yaml:language/language-ty|pe`format Ok. Then we use | for splitting and ` for format. | Even better: think of a format as a "fragment" in the absolute | URI of the type: | | !yaml:language/language-type#format | | RFC2396 explicitly says that an absolute URI does not have | fragments... We could do it this way... Unfortunately, there are some XML namespaces which contain fragments since they are URI references. I think our names should be "Absolute URI References" aka, a URI Reference that has been made absolute. This will cover those pesky XML namespaces with fragments in them (there are quite a few of those buggers out there). Note that this term is not defined by the URI specification, but should be apparently obvious. Obviously, we require that any relative URI reference to be made absolute before it can be converted to YAML. | !http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;html | | I guess so. OK. It is better than '/'... Perfect. | Now, about URI, escaping, etc. OK, In understand how a URI can contain any | Unicode character in a standard (UTF-8) way. Fine. And the XML precedence | means we are allowed to escape characters in there using \x \u \U - also | fine. So the parser: | | - expands escapes | - encodes in UTF-8 | - escapes anything which isn't a valid uric (URI character). | | > It allows "unicode" in the URIs, but makes it the parser's | > job to do the escaping so that the application really | > sees a URI | | So far so good... Good. | > (and a normalized one at that, where | > characters that don't need to be escaped are not | > escaped, etc.). | | Here I have a big problem. Good catch. Thanks. | Anyway, let's summarize this as a YAC (#8): | | - Type family is a globally unique URI. "globally unique absolute uri reference", aka absoluteURI "#" fragment per RFC 2396 | - Transfer method is a URI followed by an optional | fragment specifying a format. Transfer method is a type family followed by a "`" followed by a format. | - XML namespaces are translated by using ';' as the glue | character between space and tag. | - The parser works like in XML - unescapes \ codes first, | encodes as UTF-8, and escapes to % format any byte which | isn't a URI char *or is a char that was escaped using | a \ code or was escaped using a % code. Right. | - The '|' character can appear anywhere in the URI, and | is used for relative names. Right, aka dumb copy/paste. | - Defaulting is done (as you described), if there is no colon: | - If there is a slash, "yaml:" is prepended. | - Otherwise if there is a period, "yaml:any/" is prepended. | - Otherwise "yaml:any/org.yaml." is prepended. Right. | YAC#8.?: Change the characters from '#' (format), '|' (split) and ';' (glue) | to something else... How about `, |, ; respectively? | Does that properly summarize the YAC? Yes. The only issue is if we allow fragments in our names. If we don't there are XML namespaces we can't convert; but then again, there are a few anyway (they need to be put into absolute form first... aka the whole XML base mess). | OK, now (finally) to whether I like it or not. Let's see: | Benefits: | - URI per name rather than per space. So we can talk | about "THE" type name. | Good. | - XML namespaces are handled... somehow. OK. | - '|' a syntactical shorthand only, which should work for | anything at all. | Brian happy. | - URI can reflect the language's naming convention as closely | as practical in the URI character set. Brian still | happy - ``!perl/Net::Ftp'' works. | | Downsides: | - Additional explicit glue character required. Only when specifying | the full URI, however, which is pretty rate (that's the | whole point of '|'). | Acceptable... | - Additional parser complexity. We've been there... Acceptable I | think. Right. | Examples: | | !seq | !int#dec | !com.clarkevans.|invoice | !|client | # Hey Brian - look, no '|'! | !perl/Net::Ftp | | Hmmm. OK, I'll go for it, under the following conditions :-) | | - Brian likes it. | | - Starting from right now, everyone who proposes a YAC is responsible for | updating the draft and the YAC list accordingly. :-) Ok. One open issue, do we "absolute URI" or "absolute URI reference" for the type family? If the former, we use "#" as the format separator, otherwise we use "`" Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Oren Ben-K. <or...@ri...> - 2001-12-19 00:20:22
|
Clark C . Evans [mailto:cc...@cl...] wrote: > Ok. One open issue, do we "absolute URI" or "absolute URI reference" > for the type family? If the former, we use "#" as the format > separator, otherwise we use "`" If, as you say, XML namespaces actually use fragments (Ugh! Yuck! Arrgghh! Doesn't the XML spec say specifically a namespace should be a *URI*?) I think we are safer just allowing them and and use `. Drats, double drats and even triple drats! I *liked* the '#format' syntax :-( Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-12-19 00:44:42
|
On Wed, Dec 19, 2001 at 02:21:03AM +0200, Oren Ben-Kiki wrote: | Clark C . Evans [mailto:cc...@cl...] wrote: | > Ok. One open issue, do we "absolute URI" or "absolute URI reference" | > for the type family? If the former, we use "#" as the format | > separator, otherwise we use "`" | | If, as you say, XML namespaces actually use fragments (Ugh! Yuck! Arrgghh! | Doesn't the XML spec say specifically a namespace should be a *URI*?) Yep. The little word "reference" below became a source of great hardship in 1999/2000 ... and still packs a painful sting. If you notice... not ONE example uses a fragment and not ONE of them uses a relative reference. Bray is on record saying that if he understood relative references were included he would not have voted for it. http://www.w3.org/TR/1999/REC-xml-names-19990114/ [Definition:] An XML namespace is a collection of names, identified by a URI reference [RFC2396]... | I think we are safer just allowing them and and use `. | Drats, double drats and even triple drats! I *liked* | the '#format' syntax :-( Just think of it this way. We arn't going to allow relative URI references. A fragment at the end of an absolute reference... perhaps. But not a relative URI (XML Base) can be used to turn the relative reference into an absolute one. ;( Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Oren Ben-K. <or...@ri...> - 2001-12-19 00:54:33
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | If, as you say, XML namespaces actually use fragments (Ugh! > | Yuck! Arrgghh! > | Doesn't the XML spec say specifically a namespace should be > | a *URI*?) > > Yep. The little word "reference" below became a source of great > hardship in 1999/2000 ... and still packs a painful sting. If > you notice... not ONE example uses a fragment and not ONE of > them uses a relative reference. Bray is on record saying > that if he understood relative references were included he would > not have voted for it. > > http://www.w3.org/TR/1999/REC-xml-names-19990114/ > [Definition:] An XML namespace is a collection of names, identified by > a URI reference [RFC2396]... Yea gods and little fishes. The XML spec is a minefield. Remember the namespace attribute issue? Shudder! > | I think we are safer just allowing them and and use `. > | Drats, double drats and even triple drats! I *liked* > | the '#format' syntax :-( > > Just think of it this way. We arn't going to allow > relative URI references. A fragment at the end > of an absolute reference... perhaps. It seems we must... Unless... How about we use '#format' and if someone used a fragment as an XML namespace - well, he'll just have to encode the '#' character... This way we'll keep YAML clean, force the people who created the mess to clean up after themselves <really evil grin> Of course the problem is that it would hurt YAML acceptance for some people. Your call. > But not a > relative URI (XML Base) can be used to turn the > relative reference into an absolute one. NO relative URIs would be allowed as YAML namespaces EVER. You had better put that explicitly into the wording. As you say, if someone wants to convert a relative URI from XML he should take the trouble to convert it into an absolute URI first. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-12-19 01:19:41
|
On Wed, Dec 19, 2001 at 02:55:15AM +0200, Oren Ben-Kiki wrote: | > | I think we are safer just allowing them and and use `. | > | Drats, double drats and even triple drats! I *liked* | > | the '#format' syntax :-( | > | > Just think of it this way. We arn't going to allow | > relative URI references. A fragment at the end | > of an absolute reference... perhaps. | | It seems we must... Unless... How about we use '#format' and if someone used | a fragment as an XML namespace - well, he'll just have to encode the '#' | character... This way we'll keep YAML clean, force the people who created | the mess to clean up after themselves <really evil grin> Unfortunately, as you so wisely reminded me, when escaping, you may or may not change the semantics of the URI... so if we did escape the # we may in fact change the underlying URI and there is no way of knowing for sure. See section 2.4.2 of RFC 2396 Also, we will be adopting XML's version of the URI, where escape sequences are UTF-8 octets. This isn't always the case in some schemes... but those schemes are incompatible with XML... (there are some that use ISO 8859-1) | Of course the problem is that it would hurt YAML acceptance | for some people. Unfortunately, it might be the only thing stopping an isomorphic transformation from YAML to SOAP; and given that SOAP is such a big use case... and a Market that I see us doing well in, I'd hate to have classes of SOAP content that don't have a representation in YAML. | Your call. I'd call it as allowing fragments, but not allowing relative references. Thus, we get ` as our format character. | NO relative URIs would be allowed as YAML namespaces EVER. | You had better put that explicitly into the wording. As you | say, if someone wants to convert a relative URI from XML he | should take the trouble to convert it into an absolute URI first. Absolutely... *smirk* Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |
From: Oren Ben-K. <or...@ri...> - 2001-12-19 02:40:23
|
Brian Ingerson [mailto:in...@tt...] wrote: > On 18/12/01 16:23 -0500, Clark C . Evans wrote: > > I'm convinced neither of you two read what I wrote. > > Perhaps you write too much ;) ROTF :-) > > Please consider my compromise on this one: > > > > Type | Marker > > -----------+---------- > > Scalar | $ > > Array | @ > > Subroutine | & > > Typeglob | * > > Hashtable | <unmarked> > > I'll go with it. The ambiguous case now is: > > !perl/glob Ah, you want to distinguish it from a map, right? So what would happen if I write a package named 'glob'? > How about: > > !perl/.glob Or: !perl/:glob Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-12-18 19:55:27
|
| Problems with this: languages use characters which are not | allowed in a URI, like '{'. The character set is pretty generous, look at the last production posted: ;?:@&=+$,-_.!~*'() Nothing is perfect. They can drop the {} without loss of expressive power. | Note that such a URI is not allowed to contain '/' Actually, over lunch I figured that the uri_part production can contain '/' without any problem. It just requires that IANA names are always written without the abbreviation: !yaml:iana/image/gif | > --- !perl/Net::|Ftp | | Actually !:perl:%25Net::|Ftp Hunh? What is the : before the perl and using : after perl instead of / for? Did you read the detail I _carefully_ laid out? As for the %25 thing, I'm not sure. I'm waiting for Brian's feedback. If he can assume that all perl items are hashtables and only specify $ or @ for scalars and arrays then we are all set. Did you read the whole proposal? Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management Software |