From: Oren Ben-K. <or...@be...> - 2004-09-04 18:57:19
|
On Saturday 04 September 2004 18:13, T. Onoma wrote: > Okay. Question: What is the functional distinction between a private tag > 'mytag' and a tag resolved to 'yaml.org,2002:mytag'? > ... The crux of which being > simply this: We don't need private tags at all! Again I'll describe the use case (this is getting old...). - Phase 1: You write a private app and use only private tags. You also use yaml.org types cause they are so useful, universally supported, etc. - Phase 2: Someone - not you - wants to mix the abilities of your app (as a module, say) with other apps (modules). For the combined app, he can't just pile all the "private tags" together, since there are collisions between your "list" tags and another, similar app's "list" tag. How to move from phase 1 to phase 2? By "globalizing" the files, somehow associating _your_ domain with your private tags. This makes them unique and allows people to use them together with other modules in a combined app. So, the functional difference is: In this scenario, when "globalizing" one of your files, the _private_ tags need to be associated with _your_ domain, while _yaml_'s tags must continue to be associated with _yaml.org_. The fact that in phase 1 you could happily pile them together, which you keep harping on, IS COMPLETELY IRRELEVANT AT THIS POINT. Of *course* if you never leave phase 1, private tags are sufficient. For crying out loud, almost *any* mechanism works in phase 1! However, we are NOT interested in a solution that doesn't also work on phase 2. Can you _please_ accept that _this_ is the scenario we keep in mind when discussing this? Sure, some people aren't interested in this scenario. Great. I _am_ interested. So, we make every effort to ensure that people who are _only_ interested in phase 1 do not "pay" for this extra ability. At the same time, we do our best to ensure that when the time comes to move from phase 1 to phase 2, it is possible without having to modify each and every tag in each and every data file. Instead, it is sufficient to stick a single header line at the start of each file and be done. That's the trick - how to do this without incurring (almost) any cost to people in phase 1 while still allowing (relatively) painless migration to phase 2. Both #7 and #8 do this. Each has its tradeoffs. We need to choose. But one of them, or an alternative mechanism solving this scenario, is required. OK? Note: I'm leaving aside the scenario of people designing "global schemas" from scratch, as there, again, almost anything will work. It is also taken for granted that, in general, if you cut&paste YAML text from a "single app" file to a "multi app" file, some sort of %s/.../.../ must occur to correct the "prefixes" used. Again, using tables for this is unacceptable; however, any mechanism that solves the transition from phase 1 to phase 2 also solves this problem, so I'm leaving it aside as a consideration. Have fun, Oren Ben-Kiki |