From: Oren Ben-K. <or...@ri...> - 2002-09-30 20:45:40
|
"why the lucky stiff" <yam...@wh...> wrote: > > --- #YAML:1.0 #ALIAS:whytheluckystiff.net:why #ALIAS:showell.net:sh > > - !why^/news > > title: Aliases added to YAML > > body: > > > Look out! Aliases are coming! > > timestamp: !sh^/time > > date: 2002-09-30 > > time: 12:37:00 (And alternatrive syntax forms). Steve Howell [mailto:sh...@zi...] wrote: > My first instinct would be to handle aliasing at a layer just > above the YAML > loader: > > --- > sh: showell.net > why: whytheluckystiff.net > --- > - !why^/news > title: Aliases added to YAML > body: > > Look out! Aliases are coming! > timestamp: !sh^/time > date: 2002-09-30 > time: 12:37:00 It is nice that in so few postings this idea has evolved so quickly to demonstrate the dangers of the idea. First one uses multiple short named prefixes just as a convenience... Then one eliminates the bother of actually declaring them, moving it outside the document (not even XML took such a drastic step)... Then people start think it is the prefixes which are globally unique and the long form they stand for isn't useful. At this point the URI this form is actually a shorthand for is a dim memory... At this point the prefixes are so useless as globally unique identifiers that Brian's proposal to get rid of them makes sense :-) No. We must have globally unique IDs. These are taguri:s. I feel that giving this up would be a big mistake. Nobody disputes that writing the full taguri isn't acceptable. Hence we need a shorthand mechanism. We provide such a mechanism. It may not be as convenient as it could be, and this deserves consideration. Now, Why's original idea has merits: - It unifies two separate shorthand mechanisms we have today (!lang/... And !^...). - It also makes most type families much more readable. It also has down sides: - The shorthand form is no longer globally unique. Brian in particular championed the idea that a parser need not expand the type family name to a URI. The current shorthand rules were set up so this is allowed and safe. Why's proposal makes this unsafe; a parser will be forced to expand to a URI in order to get a globally unique name. - Temptation. Even though the shorthands forms are no longer globally unique, there is a great temptation to treat them as if they are globally unique anyway - as the last few posts demonstrate. This leads to trouble. - Complexity. The current prefix mechanism is simple. Why's proposal is very similar to XML's namespaces mechanism. It requires maintaining a stack of sets of prefixes. Experience has shown that it has the potential to greatly complicate things. However the XML namespaces proposal had several others designs choices that made it complex, so it isn't fair to lay it all on the use of prefixes by itself. One question that pops up immediately is whether this is useful. We are being very generous with implicit types; presumably the explicit types would be rather rare. Mixing explicit types from different domains (other than in well-defined "islands") should be even more rare. Is there really enough of a use case to warrant complicating our current simple scheme? My current gut feeling is that the answer is "no". However I think we should continue to discuss this, being very wary of the potential downsides. Especially the temptation one - this is the dark side of the force calling :-) Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-10-01 09:44:48
|
why the lucky stiff [mailto:yam...@wh...] wrote: > > - Temptation. Even though the shorthands forms are no > > longer globally > > unique, there is a great temptation to treat them as if they are > > globally unique anyway - as the last few posts demonstrate. > > This leads to trouble. > > Yeah. This is the biggest strike against my idea. I hadn't > seen this right away, but it's terribly clear now. But it > also seems to be a strike against many of the recent schema > ideas that have been proposed on the list recently. There's a subtle difference. Perhaps too subtle... > The idea of having an external schema which can define > implicits, for instance. A document being read without the > schema would be ignorant of the implied types. Similarly, a > document with externally defined type aliases could be read > without regard to what the aliases expand to. I have a hard > time telling which way the list goes on this. It is physically impossible to (ab)use the implicit type family as if it is a globally unique ID. It is all too easy to succumb to that temptation if one has an almost-unique shorthand notation. > Half of us don't care about type information it seems, so > aliases shouldn't matter. These people read everything in as > collections and strings. Then these people wouldn't be using explicit type families either... No need for the aliases then. > The other half of us are tightly tied to type. So that if a > type doesn't resolve, we throw an error. The document > doesn't get parsed. It is here that abusing almost-unique shorthand forms leads to trouble. > > One question that pops up immediately is whether this is useful. I think we still don't have a good answer for this question. > I'm not trying to do a namespace kind of thing. Honestly, I > just see it as a nicer prefixing syntax. That's what namespaces started at as well :-) > For example, in a Yod document > (!yaml4r.sf.net,2003/yod/^Document), I currently only > allow three types of page content: !^Paragraph, !^Code, > !^Quote. But I want to allow a Wiki-like StructuredText type > of element also. This markup will not be a part of the Yod > project, though. I'd like to do a > !whytheluckystiff.net,2003/markup type. Perhaps I need to > use a shorter domain name, but aliases would work so nicely. > > --- #YAML:1.0 #ALIAS:yod:yaml4r.sf.net,2003/yod > #ALIAS:why:whytheluckystiff.net,2003 !yod/Document > Title: Yaml.rb -- Yaml for Ruby > Table of Contents: > - Preface > Preface: !yod/Page > - !yod/Paragraph > > What is YAML? From the specification: > > - !yod/Quote > > YAML(tm) (rhymes with 'camel') is a > straightforward machine parsable data serialization > format designed for > ... > > - !why/markup > > Here is some '''bold''' text and ''italicized'' also. > > Plainly I have a use case where the prefix doesn't help me, > but aliases would. Question. Is it really allowed to place a !why/markup inside a !yod/document? I'd have expected a yod document to specify the exact set of possible presentation syntaxes that may be used in it... I think that if/when someone comes up with a schema for yod/Document, why/markup will not be included in it. This may seem like nit-picking, but I feel it demonstrates an important general point. One can roughly separate types into two sets. There are generic containers such as !map that don't care at all about what they contain. Then there are specific containers (and scalars) that specify a fixed set of possible values (a good example is a 'point' that must contain 'x' and 'y' that must be 'float's). It is rather rare that you get a type that is in the middle - I can't think of one off-hand. This observation lends credibility to the "islands" concept, since in most cases a container of type family X would specify its components to be of related type families. Another point is that in many cases just specifying a type for the top-level container immediately constrains the type of many of the components. Take a 'circle' example that contains a 'point' and a radius. If the circle was explicitly typed as a '!.../circle' there's really no need to explicitly declare the 'point' as of type '!.../point' - that is implied by the structure of the document. Given the above observation, and combining the island concept with structure-driven implicit typing, seems to imply that the need for interleaving would be very low. Of course, that's all sheer speculation at this point. But I'd rather KISS for now. I'm with Clark; let's just leave it for now, while keeping our eyes peeled for counter-examples. Have fun, Oren Ben-Kiki |
From: why t. l. s. <yam...@wh...> - 2002-10-01 16:01:22
|
Oren Ben-Kiki (or...@ri...) wrote: > Question. Is it really allowed to place a !why/markup inside a > !yod/document? I'd have expected a yod document to specify the exact set of > possible presentation syntaxes that may be used in it... I think that > if/when someone comes up with a schema for yod/Document, why/markup will not > be included in it. A popular convention in the Ruby kingdom is to classify objects by their methods. (Like Interfaces in Java.) Any class which defines an 'each' iterator can use the Enumerable mixin to gain other similiar methods (such as 'grep' and 'each_with_index'). In Yod, I hoped to allow usage of any object which has its own set of 'to_html', 'to_chm', and 'to_man' methods. I can get by with writing wrapper classes, it's just annoying to keep them in sync. If there was a user out there that wanted to write a plugin class for Yod, and they named it outside of the yaml4r.sf.net domain, they could still add it to the yod/PageContent type class in !okay/schema. I believe RELAX-NG has a similiar mechanism. --- !okay/schema yaml4r.sf.net,2003/yod/Document: schema: - map: /Title: [ str ] /Table of Contents: - seq: [ str ] /*: - yaml4r.sf.net,2003/yod/Page - yaml4r.sf.net,2003/yod/Group yaml4r.sf.net,2003/yod/Page: schema: - seq: /*: [ yaml4r.sf.net,2003/yod/PageContent ] yaml4r.sf.net,2003/yod/Paragraph: classes: - yaml4r.sf.net,2003/yod/PageContent schema: - str Then in the schema for !whytheluckystiff.net,2003/markup: --- !okay/schema whytheluckystiff.net,2003/markup: classes: - yaml4r.sf.net,2003/yod/PageContent schema: - str > Another point is that in many cases just specifying a type for the top-level > container immediately constrains the type of many of the components. Take a > 'circle' example that contains a 'point' and a radius. If the circle was > explicitly typed as a '!.../circle' there's really no need to explicitly > declare the 'point' as of type '!.../point' - that is implied by the > structure of the document. I see what you're saying. Still, in the above Yod example, how am I to tell if paragraphs contain raw HTML or a simplified markup or plain text? Typing is the simplest way to do this and allow extensibility for future markup. _why |
From: Clark C. E. <cc...@cl...> - 2002-10-01 19:15:00
|
On Tue, Oct 01, 2002 at 10:10:55AM -0600, why the lucky stiff wrote: | A popular convention in the Ruby kingdom is to classify objects by their | methods. (Like Interfaces in Java.) Any class which defines an 'each' | iterator can use the Enumerable mixin to gain other similiar methods (such | as 'grep' and 'each_with_index'). Yes. Mix-ins are big with Python as well. Also there are two "big" use cases for interleving in XML land: 1) XSLT is entirely based on the concept, within a "template" object will be content from one or more namespaces, and perhaps within them, other calls in the XSLT namespace to pull values... <xslt:template ...> <html:body> <xslt:value-of ...> 2) XHTML mixing with other domains. For example, you may want to have some symbolic content readable by a browser. Thus, you mix both xhtml and your prefix, quite liberally. XHTML is desined to skip intermediate nodes from namespaces that it doesn't know about; instead only validating using content from the XHTML namespace. An example of this usage is RDDL. It is primarly XHTML but with RDDL objects litterred everwhere (using just elements and attributes). Anyway, I wanted to stress that I don't deny that this is a use case... I just think that it is probably less than 5% of the documents out there; and it brings with it complexity. Also, I have a hunch that one could accomplish the same "mixing" at the schema level rather than at the document level. Thus, we'd want some sort of cross-product operator for schemata... so that one schema can be dynamically constructed as the cross between two existing schemata (perhaps then sighting restrictions). So; I'd like to keep core yaml "simple" and see if this complexity of interleaving can be done at the shema level; if not, then we will have to come back and revisit this. For now, perhaps we can make sure that some prefix character is allowed after ! but not part of the production. I'm sure that this exists, but it may be nice to verify. | If there was a user out there that wanted to write a plugin class for Yod, | and they named it outside of the yaml4r.sf.net domain, they could still | add it to the yod/PageContent type class in !okay/schema. I believe RELAX-NG | has a similiar mechanism. *nods* Clark |
From: Oren Ben-K. <or...@ri...> - 2002-10-01 17:00:31
|
why the lucky stiff [mailto:yam...@wh...] wrote: > I see what you're saying. Still, in the above Yod example, > how am I to tell if paragraphs contain raw HTML or a > simplified markup or plain text? Typing is the simplest way > to do this and allow extensibility for future markup. +1 on that. Typing is the right answer. I expect that in such a case (such as Yod) the possible markup types would be types under a single domain most of the time. If people want to add new ones they would be encouraged to register them under that domain. E.g. !^HTML, !^Simple in addition to !^Document etc. This only makes sense if Yod presentations are expected to be platform-independent... Writing your own plug-in types to this sort of system essentially removes interoperability; what should my Yod converter do when it sees !why/whatever? Not supporting interleaved types can be thought of a way we'd be "encouraging" people to define schemas and be interoperable :-) Have fun, Oren Ben-Kiki |
From: why t. l. s. <yam...@wh...> - 2002-10-01 17:34:18
|
Oren Ben-Kiki (or...@ri...) wrote: > This only makes sense if Yod presentations are expected to be > platform-independent... Writing your own plug-in types to this sort of > system essentially removes interoperability; what should my Yod converter do > when it sees !why/whatever? > > Not supporting interleaved types can be thought of a way we'd be > "encouraging" people to define schemas and be interoperable :-) Okay. I'll buy that. Thanks for entertaining the original idea and going back and forth on this. I tend to look at my use cases from a very Ruby-centric point of view. If only the rest of the world could see it that way... ;) _why |
From: Steve H. <sh...@zi...> - 2002-09-30 20:56:31
|
From: "Oren Ben-Kiki" <or...@ri...> > One question that pops up immediately is whether this is useful. [...] Is there really enough of > a use case to warrant complicating our current simple scheme? > That's the key question. Are we actually writing an app that makes the uri abbreviation concept come into play? Or are we just waxing philosophical? |
From: why t. l. s. <yam...@wh...> - 2002-09-30 21:52:05
|
Oren Ben-Kiki (or...@ri...) wrote: > - The shorthand form is no longer globally unique. Brian in particular > championed the idea that a parser need not expand the type family name to a > URI. The current shorthand rules were set up so this is allowed and safe. > Why's proposal makes this unsafe; a parser will be forced to expand to a URI > in order to get a globally unique name. Yeah. True. > - Temptation. Even though the shorthands forms are no longer globally > unique, there is a great temptation to treat them as if they are globally > unique anyway - as the last few posts demonstrate. This leads to trouble. Yeah. This is the biggest strike against my idea. I hadn't seen this right away, but it's terribly clear now. But it also seems to be a strike against many of the recent schema ideas that have been proposed on the list recently. The idea of having an external schema which can define implicits, for instance. A document being read without the schema would be ignorant of the implied types. Similiarly, a document with externally defined type aliases could be read without regard to what the aliases expand to. I have a hard time telling which way the list goes on this. Half of us don't care about type information it seems, so aliases shouldn't matter. These people read everything in as collections and strings. The other half of us are tightly tied to type. So that if a type doesn't resolve, we throw an error. The document doesn't get parsed. > - Complexity. The current prefix mechanism is simple. Why's proposal is very > similar to XML's namespaces mechanism. It requires maintaining a stack of > sets of prefixes. Experience has shown that it has the potential to greatly > complicate things. However the XML namespaces proposal had several others > designs choices that made it complex, so it isn't fair to lay it all on the > use of prefixes by itself. The caret prefix is simple in simple documents. But hardly so in more complex documents. And I'm not saying get rid of the caret. The caret could be thought of as an alias as well. '!yaml4r.sf.net,2003/yod/^Document' is equivalent to saying the '^' alias = 'yaml4r.sf.net,2003/yod/'. I'm just expanding the valid character set for a prefix from just the caret to an unlimited number of character combinations, allowing combinations which are more meaningful to a user than the caret alone is. > One question that pops up immediately is whether this is useful. We are > being very generous with implicit types; presumably the explicit types would > be rather rare. Mixing explicit types from different domains (other than in > well-defined "islands") should be even more rare. Is there really enough of > a use case to warrant complicating our current simple scheme? I'm not trying to do a namespace kind of thing. Honestly, I just see it as a nicer prefixing syntax. The prefix caret could get kind of confusing if you try to overload it. For example, in a Yod document (!yaml4r.sf.net,2003/yod/^Document), I currently only allow three types of page content: !^Paragraph, !^Code, !^Quote. But I want to allow a Wiki-like StructuredText type of element also. This markup will not be a part of the Yod project, though. I'd like to do a !whytheluckystiff.net,2003/markup type. Perhaps I need to use a shorter domain name, but aliases would work so nicely. --- #YAML:1.0 #ALIAS:yod:yaml4r.sf.net,2003/yod #ALIAS:why:whytheluckystiff.net,2003 !yod/Document Title: Yaml.rb -- Yaml for Ruby Table of Contents: - Preface Preface: !yod/Page - !yod/Paragraph > What is YAML? From the specification: - !yod/Quote > YAML(tm) (rhymes with 'camel') is a straightforward machine parsable data serialization format designed for ... - !why/markup > Here is some '''bold''' text and ''italicized'' also. Plainly I have a use case where the prefix doesn't help me, but aliases would. _why |
From: Clark C. E. <cc...@cl...> - 2002-09-30 22:01:47
|
On Mon, Sep 30, 2002 at 04:01:39PM -0600, why the lucky stiff wrote: | --- #YAML:1.0 #ALIAS:yod:yaml4r.sf.net,2003/yod #ALIAS:why:whytheluckystiff.net,2003 !yod/Document | Preface: !yod/Page | - !why/markup > | Here is some '''bold''' text and ''italicized'' also. Yes. Let's call this case "interleaving". Fortunately, it isn't all that common. And it could be done at the schema level, by providing a mechanism for one schema to "inherit" the types from another schema. Most of the time, however, typing comes in "islands" (to quote Don Park) and this is the use case that the current prefix mechanism addresses; it's a 90% solution which is relatively clean. Yes, it's not a 100% solution; but once again, I think that solving these complicated issues should be moved up into the schema mechanism. So. I propose we not forget these issues; but focus on schema development (and solving these problems there). Best, Clark |
From: why t. l. s. <yam...@wh...> - 2002-09-30 22:18:22
|
Clark C. Evans (cc...@cl...) wrote: > So. I propose we not forget these issues; but focus on > schema development (and solving these problems there). Yeah, sounds good. I can find ways to work around interleaving. For example, I'll likely provide a 'tag:yaml4r.sf.net,2003:yod/Markup' wrapper type to allow the Wiki-like markup. The wrapper isn't such a bad idea, but I'd like to see Yod allow different sorts of content outside of its domain. On the topic of schema: I put up two more RELAX-NG examples on Wiki last week. I'm having a hard time seeing a plausible schema still and I'm letting my mind mull over it before proceeding to further examples. _why |
From: Clark C. E. <cc...@cl...> - 2002-09-30 22:58:50
|
On Mon, Sep 30, 2002 at 04:27:56PM -0600, why the lucky stiff wrote: | On the topic of schema: I put up two more RELAX-NG examples on Wiki last week. | I'm having a hard time seeing a plausible schema still and I'm letting my mind | mull over it before proceeding to further examples. Cool. I'll have a look at it. Thanks for pushing ahead... my day job is consuming time. Best, Clark |