From: Oren Ben-K. <or...@be...> - 2003-03-15 17:48:36
|
I wrote: > > If I tell my emitter to use 2-column indenting, do I get: > > Well, that really depends how you write it, but I expect the > answer to be: > > > --- > > foo: > > - bar > > --- > > > Oren, is this possible for the productions? > > Well, here's the thing - it is already there :-) The only > problem is the incorrect wording, which should be fixed. Nice catch! Me bad - I was wrong, there is a need to fix the productions. Sorry about that. In fact, a "proper" fix is messy, as Brian has correctly pointed out. I used a cope-out in production 95 (similar to the dirty trick I'm pulling in production 193). I hope that's acceptable. In addition to fixing this I changed the wording in section 3.2.1 (indentation) accordingly and added some examples. That should lay this problem to rest. I also changed the implicit header to '---' instead of the old '--- %YAML:1.0'. This is a simple wording change in section 3.3.1 that I somehow missed making this change the last time I released the draft, even though we agreed to it. A final change was allowing implicit top-level flow scalars as we just agreed, which required a wording change in 3.3.3, fixing production 47 and adding production 61. You can find the corrected spec at www.ben-kiki.org/oren/yod/spec.html and the updated changes list in www.ben-kiki.org/oren/yod/changes.html. The YOD source is at www.ben-kiki.org/oren/yod/spec.yod as usual. Clark, could you please upload this to the main site? I think that we are about done nit-picking the spec, at least as far as intent is concerned. Clark, Brian, everyone - I feel it is about time we declared this as a "release candidate". Any reason not to? As Brian pointed out, we don't see ourselves making any further changes... Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2003-03-16 00:57:01
|
On 15/03/03 19:48 +0200, Oren Ben-Kiki wrote: > You can find the corrected spec at www.ben-kiki.org/oren/yod/spec.html > and the updated changes list in www.ben-kiki.org/oren/yod/changes.html. > The YOD source is at www.ben-kiki.org/oren/yod/spec.yod as usual. Clark, > could you please upload this to the main site? And it's so beautiful! Great work on the YOD stuff Oren (and Why). > I think that we are about done nit-picking the spec, at least as far as > intent is concerned. Clark, Brian, everyone - I feel it is about time we > declared this as a "release candidate". Any reason not to? As Brian > pointed out, we don't see ourselves making any further changes... I'll tell you what. Let's shoot for the end of April for announcing a Release Candidate. (It seems that) Why, Mike Orr and I are are in the middle of implementing a lot of stuff in the next 6 weeks. If the spec can survive that period, then I'm willing to go to a release candidate. Clark? BTW Oren (and Clark), you never replied to my email "The diagram is wrong". I think that it requests some changes in the model section of the spec. The important part is: - The flow diagram in the spec is flawed in my opinion. I am actually to blame, because I wanted it that way. But a linker and a loader are just two "flavors" of the same thing. And there can be many many more flavors. I would just drop the concepts of Linker and Serializer and call them Generic Loader and Generic Dumper. That's what they are. I'm now very convinced that a linker is just a specialized loader, and a serializer is just a specialized dumper. The only concepts that matter (specwise) are Parser/Loader and Dumper/Emitter. A native Loader doesn't "employ" a Linker, as I once suggested. They may both inherit common code, but they are conceptually separated. ie An application will either want to do a Generic Load, or a Native Load, (or some other specialized Load). Perhaps we should have a several different style implementations under our belts before writing "this is how implementations should behave" in the spec. Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2003-03-16 08:46:20
|
Brian Ingerson [mailto:in...@tt...] wrote: > ... Great work on the YOD stuff Oren (and Why). Thanks. Just note that my YOD isn't Why's YOD - unless why has changed his code; if he did, I'd love to run it through yod2pdf to get a printable version. I tried to get a yod2latex going but latex's tables have defeated me; it seems impossible to get the required table functionality out of latex... Also, the source YOD file would look much better (getting rid of all the '- >') once I can switch to the new YAML.pm. As it is today, it needs a hacked version of YAML.pm 0.35. > I'll tell you what. Let's shoot for the end of April for=20 > announcing a Release Candidate. (It seems that) Why, Mike Orr=20 > and I are in the middle of implementing a lot of stuff in=20 > the next 6 weeks. If the spec can survive that period, then=20 > I'm willing to go to a release candidate. Works for me. > BTW Oren (and Clark), you never replied to my email "The=20 > diagram is wrong". I think that it requests some changes in=20 > the model section of the spec. The important part is: ... >=20 > - The flow diagram in the spec is flawed in my opinion. I=20 > am actually to blame, because I wanted it that way. :-) > But a linker and a loader > are just two "flavors" of the same thing. That's what the old diagram said... > And there can=20 > be many > more flavors. I would just drop the concepts of Linker and > Serializer and call them Generic Loader and Generic Dumper. That's > what they are. Hmmm. So you'd rather see the old diagram? -------------- | GRAPH | TEXT -- Parser -> SERIAL -- Loader -> | (generic) | |---- or ----| (syntax) <- Emitter - (tree) <- Dumper <- | NATIVE | | (language) | -------------- /\ || \/ Application=A0 I don't like it much... > ... A native Loader doesn't "employ" a=20 > Linker, as I once suggested. > They may both inherit common=20 > code, but they are conceptually separated. This by itself doesn't bother me at all; it is merely implementation details. It is possible, after all, to implement a YAML loader without going through a serial (tree) model either, directly using some sort of lexical tokenizer. > ie An application=20 > will either want to do a Generic Load, or a Native Load, (or=20 > some other specialized Load). You could also say that an application would either want to see the serial (tree) model or one of the above, but not both. Again that doesn't invalidate the serial model being at a different abstraction level. The main reason I'd like to keep the diagram as it is, regardless of implementation details, is that the graph is an *enhancement* of the native model with formats and a uniform string representation of the scalar values. I think that this justifies viewing the graph model as a valid intermediate step between the native and serial models. Have fun, Oren Ben-Kiki |
From: <ms...@oz...> - 2003-03-17 19:00:39
|
Oren wrote: > Brian wrote; >> I would just drop the concepts of Linker and >> Serializer and call them Generic Loader and Generic Dumper. That's >> what they are. > > Hmmm. So you'd rather see the old diagram? > > -------------- > | GRAPH | > TEXT -- Parser -> SERIAL -- Loader -> | (generic) | > |---- or ----| > (syntax) <- Emitter - (tree) <- Dumper <- | NATIVE | > | (language) | > -------------- > /\ > || > \/ > Application > > I don't like it much... > >> ... A native Loader doesn't "employ" a >> Linker, as I once suggested. >> They may both inherit common >> code, but they are conceptually separated. > > This by itself doesn't bother me at all; it is merely implementation > details. It is possible, after all, to implement a YAML loader without > going through a serial (tree) model either, directly using some sort of > lexical tokenizer. > >> ie An application >> will either want to do a Generic Load, or a Native Load, (or >> some other specialized Load). > > You could also say that an application would either want to see the > serial (tree) model or one of the above, but not both. Again that > doesn't invalidate the serial model being at a different abstraction > level. I would just like to cut down on the number of terms. There are already four terms for the different stages (Text, Serial, Graph, Native), and then seven terms for the different transitions. Loader/dumper are defensible because they are used as opposites in some programming languages. But "linker"/"serializer" aren't natural opposites, and neither is "parser"/"emitter" (parse = decode; emit = give out), nor do the words have any natural affinity to the stages they go from or to. However, I understand it's more important to get things implemented than to spend a lot of time on terms. |
From: Brian I. <in...@tt...> - 2003-03-17 20:25:50
|
On 17/03/03 12:00 -0700, ms...@oz... wrote: > Oren wrote: > > Brian wrote; > >> I would just drop the concepts of Linker and > >> Serializer and call them Generic Loader and Generic Dumper. That's > >> what they are. > > > > Hmmm. So you'd rather see the old diagram? > > > > -------------- > > | GRAPH | > > TEXT -- Parser -> SERIAL -- Loader -> | (generic) | > > |---- or ----| > > (syntax) <- Emitter - (tree) <- Dumper <- | NATIVE | > > | (language) | > > -------------- > > /\ > > || > > \/ > > Application > > > > I don't like it much... > > > >> ... A native Loader doesn't "employ" a > >> Linker, as I once suggested. > >> They may both inherit common > >> code, but they are conceptually separated. > > > > This by itself doesn't bother me at all; it is merely implementation > > details. It is possible, after all, to implement a YAML loader without > > going through a serial (tree) model either, directly using some sort of > > lexical tokenizer. > > > >> ie An application > >> will either want to do a Generic Load, or a Native Load, (or > >> some other specialized Load). > > > > You could also say that an application would either want to see the > > serial (tree) model or one of the above, but not both. Again that > > doesn't invalidate the serial model being at a different abstraction > > level. > Oren, I swear I did not prompt Mike! ;) > I would just like to cut down on the number of terms. There are already > four terms for the different stages (Text, Serial, Graph, Native), and > then seven terms for the different transitions. yep > Loader/dumper are defensible because they are used as opposites in > some programming languages. +1 Load and Dump are operations you expect to do from a program. > But "linker"/"serializer" aren't natural opposites, and neither is Link and Serialize are rather yagni. I see them as special forms of Load and Dump. Since there are N ways to Load and Dump, I find it confusing to give special names to one. (Even if it's an important one) > "parser"/"emitter" (parse = decode; emit = give out), nor do the words > have any natural affinity to the stages they go from or to. Applications actually will want to Parse and Emit directly. This is known as serial or streaming access; like XML SAX. Currently there are no modules that support this, but that is about to change very soon (at least in Perl). So we really do need the concepts of Parser and Emitter. They associate to real classes. > However, I understand it's more important to get things implemented than > to spend a lot of time on terms. +10 Cheers, Brian BTW, Clark and Oren and i met on irc. Clark is going to try to rework this stuff in the spec a little bit. |
From: Oren Ben-K. <or...@be...> - 2003-03-17 20:49:45
|
Brian Ingerson [mailto:in...@tt...] wrote: > ms...@oz... wrote: > > I would just like to cut down on the number of terms. There are > > already four terms for the different stages (Text, Serial, Graph, > > Native), and then seven terms for the different transitions. > > yep Yes, there are. > > Loader/dumper are defensible because they are used as opposites in > > some programming languages. > > +1 Load and Dump are operations you expect to do from a program. In most cases. Unless you just want to parse... Or maybe just to view native data as YAML... And of course generic YAML tools would stop after linking... > > But "linker"/"serializer" aren't natural opposites, and neither is > > "parser"/"emitter" That's the best wording we came up with. I don't know what would be a better name for the opposite of a parser - "printer" is even worse than "emitter". Improved terms would be most welcome. > Link and Serialize are rather yagni. I see them as special > forms of Load and Dump. Since there are N ways to Load and > Dump, I find it confusing to give special names to one. (Even > if it's an important one) The reason I'd like to stick with the current diagram is that "generic" is more than "yet another way to load the data". The crucial difference between the generic model and the native one is the existence of formats. IMVHO saying that generic is a variant of native, except for this little thing with formats and values as Unicode strings, is similar to saying that the serial model is a variant of the generic one, except for this little thing with key order and alias nodes. The current diagram allows explaining the introduction and role of formats in a much cleaner (and simpler) way. I don't quite see how they can be defined in any other fashion; after all, they are neither a part of the native model nor the serial one. > > However, I understand it's more important to get things implemented > > than to spend a lot of time on terms. > > +10 2nd-ed; I think we are splitting hairs about the best wording, but the intent is the same. We've trashed the models section to death as it is; I'd rather work on the implementation (in what little time I can spare for YAML these days). > BTW, Clark and Oren and i met on irc. Clark is going to try > to rework this stuff in the spec a little bit. Specifically, we asked Clark to consider two options; - one is just adding wording to the effect that in most implementations the linker and loader are combined in a single module (their separation seems to be the main objection to the diagram), - the other is to combine the generic and native model sections, adding wording saying that formats may or may not be preserved in some implementations, and so on (shudder - IMVHO). We'll see... Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2003-03-18 20:44:14
|
On 17/03/03 22:49 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > ms...@oz... wrote: > > > I would just like to cut down on the number of terms. There are > > > already four terms for the different stages (Text, Serial, Graph, > > > Native), and then seven terms for the different transitions. > > > > > Link and Serialize are rather yagni. I see them as special > > forms of Load and Dump. Since there are N ways to Load and > > Dump, I find it confusing to give special names to one. (Even > > if it's an important one) > > The reason I'd like to stick with the current diagram is that "generic" > is more than "yet another way to load the data". The crucial difference > between the generic model and the native one is the existence of > formats. IMVHO saying that generic is a variant of native, except for > this little thing with formats and values as Unicode strings, is similar > to saying that the serial model is a variant of the generic one, except > for this little thing with key order and alias nodes. I did not say that "generic is a variant of native" exactly. I said that a loader can load YAML into memory in more than one way. Let's consider what a loader does: - It gets a series of events from a parser. Things like scalar_value(string, type, format, anchor). - Determines how these should be represented in memory: - There are several possible ways to store a YAML node in memory. (Even in the same programing language). A date could become a string, an integer, a date object (from any number of date classes) - To do this it needs to take direction from various sources like: - The loader class's defaults - The calling applications overrides - Other helper classes yaml methods - A yaml schema document - It can choose to apply a type and format in order to create a native binding, *or* it can create some container object that holds the original type and format, *or* it can load every node as the number 42 (but that might not be too useful) - Oten times a loader will be able to load some nodes natively, but other nodes as container objects. - When a loader is set up to load *all* nodes as container objects, then this is what we call a Linker. The "generic" graph is just a load of container nodes. > The current diagram allows explaining the introduction and role of > formats in a much cleaner (and simpler) way. I don't quite see how they > can be defined in any other fashion; after all, they are neither a part > of the native model nor the serial one. What do you mean? Formats are definitely in the serial model. I don't follow you here. > > > > However, I understand it's more important to get things implemented > > > than to spend a lot of time on terms. > > > > +10 > > 2nd-ed; I think we are splitting hairs about the best wording, but the > intent is the same. We've trashed the models section to death as it is; > I'd rather work on the implementation (in what little time I can spare > for YAML these days). > > > BTW, Clark and Oren and i met on irc. Clark is going to try > > to rework this stuff in the spec a little bit. > > Specifically, we asked Clark to consider two options; > > - one is just adding wording to the effect that in most implementations > the linker and loader are combined in a single module (their separation > seems to be the main objection to the diagram), > > - the other is to combine the generic and native model sections, adding > wording saying that formats may or may not be preserved in some > implementations, and so on (shudder - IMVHO). It's more like "formats may or may not be preserved depending on how the application wants to use the loader". Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2003-03-18 22:32:04
|
Brian Ingerson wrote: > I did not say that "generic is a variant of native" exactly. > I said that a loader can load YAML into memory in more than one way. To be sure. The thing is, the way I see it there's a strong distinction between two different ways of loading (each with multiple possible physical implementation). One follows the rules described in the generic model and the other follows the rules described in the native model. > > The current diagram allows explaining the introduction and role of > > formats in a much cleaner (and simpler) way. I don't quite see how > > they can be defined in any other fashion; after all, they > > are neither > > a part of the native model nor the serial one. > > What do you mean? Formats are definitely in the serial model. > I don't follow you here. Sorry, I didn't phrase this well. I meant to say that formats don't "belong" to the serial model - "belong" meaning "are stripped/introduced when moving from/to the specific model to a higher level model". Alias nodes "belong" to the serial model, since by definition they are lost when the serial model is converted to a higher level, and introduced when a serial model is created from a higher level. Formats, on the other hand, are not lost when the serial model is converted to a higher level, and are introduced independently of serialization. Hence they don't "belong" to the serial model. And they don't even exist in the native model, so... > > ... I [still] > > think we are splitting hairs about the best > > wording, but the > > intent is the same. We've trashed the models section to death as it > > is; I'd rather work on the implementation (in what little > > time I can spare for YAML these days). > > - the other [alternative] > > is to combine the generic and native model sections, > > adding wording saying that formats may or may not be > > preserved in some > > implementations, and so on (shudder - IMVHO). > > It's more like "formats may or may not be preserved depending > on how the application wants to use the loader". Exactly. Shudder. After all, you can say the same thing about aliases or key order (which may or may not be preserved depending on how the application wants to use the file); you might as well merge all the models into a single one with the application picking and choosing which parts it wants to keep. After all, this by definition is what happens in practice... One can always write an application that preserves, say, key order and formats but not aliases, or whatever, and it would be valid YAML. I think that clearly defining separate serial/generic/native levels is useful for a tight definition of the semantics, without limiting application flexibility. I don't care at all that the implementations merge steps together. For example, it doesn't bother me one bit if a YAML system merged the parser, linker and loader into a single step (e.g., on top of a lower-level lexer-like tool). The levels are for clearly defining YAML semantics, not a top-level design for YAML libraries. Maybe this is a good example of why Analysis != Design. Have fun, Oren Ben-Kiki |
From: <ms...@oz...> - 2003-03-20 20:10:16
|
Oren wrote: > I think that clearly defining separate serial/generic/native levels is > useful for a tight definition of the semantics, without limiting > application flexibility. I don't care at all that the implementations > merge steps together. For example, it doesn't bother me one bit if a > YAML system merged the parser, linker and loader into a single step > (e.g., on top of a lower-level lexer-like tool). > The levels are for clearly defining YAML semantics, not a top-level > design for YAML libraries. That would be good to mention at the end of section 4.1 (Information Models, Overview). E.g., say that these models are meant to guide processor implementors, not dictate the terminology of the user interface. |
From: Oren Ben-K. <or...@be...> - 2003-03-21 10:24:49
|
ms...@oz... wrote: > Oren wrote: > > I think that clearly defining separate > > serial/generic/native levels is > > useful for a tight definition of the semantics, without limiting > > application flexibility. I don't care at all that the > > implementations > > merge steps together. For example, it doesn't bother me one > > bit if a > > YAML system merged the parser, linker and loader into a single step > > (e.g., on top of a lower-level lexer-like tool). The levels are for > > clearly defining YAML semantics, not a top-level design for YAML > > libraries. > > That would be good to mention at the end of section 4.1 > (Information Models, Overview). E.g., say that these models > are meant to guide processor implementors, not dictate the > terminology of the user interface. +1. That's more-or-less one of the alternatives Clark has to choose from (the second being to make major structural changes to the models section). Clark...? Have fun, Oren Ben-Kiki |
From: <ms...@oz...> - 2003-03-17 20:59:04
|
Brian wrote: > Oren, I swear I did not prompt Mike! ;) It's been something I've been feeling for a couple months. >> "parser"/"emitter" (parse = decode; emit = give out), nor do the words >> have any natural affinity to the stages they go from or to. > > Applications actually will want to Parse and Emit directly. This is > known as serial or streaming access; like XML SAX. Does XML SAX actually use the term emit(ter)? "Parser" makes sense, but I usually hear its opposite called "writer". Emitting is what the sun does when it throws off rays; it just throws them out without any concern for the context or prettying it up with whitespace. |
From: Clark C. E. <cc...@cl...> - 2003-03-17 23:32:40
|
On Mon, Mar 17, 2003 at 01:59:05PM -0700, ms...@oz... wrote: | Does XML SAX actually use the term emit(ter)? "Parser" makes sense, but | I usually hear its opposite called "writer". Emitting is what the sun does | when it throws off rays; it just throws them out without any concern for the | context or prettying it up with whitespace. Unfortunately, Reader is almost always coupled with Writer, java.io.Reader/java.io.Writer being but one of many examples. So, rather than call it a Writer, I've been using Emitter I tend to think of Emit not in the Radiological sense, but rather with the second more 'legal' meaning: To issue with authority; to voice; express an idea. Clark |
From: Colin M. <cm...@he...> - 2003-03-18 22:03:40
|
On Mon, Mar 17, 2003 at 11:49:35PM +0000, Clark C. Evans wrote: > On Mon, Mar 17, 2003 at 01:59:05PM -0700, ms...@oz... wrote: > | Does XML SAX actually use the term emit(ter)? "Parser" makes sense, but > | I usually hear its opposite called "writer". Emitting is what the sun does > | when it throws off rays; it just throws them out without any concern for the > | context or prettying it up with whitespace. > > Unfortunately, Reader is almost always coupled with Writer, > java.io.Reader/java.io.Writer being but one of many examples. > So, rather than call it a Writer, I've been using Emitter > I tend to think of Emit not in the Radiological sense, but > rather with the second more 'legal' meaning: > > To issue with authority; to voice; express an idea. In the Perl world (XML::SAX, XML::SAX::Base and associated modules), code that creates SAX events is often called the "driver", and code that receives such events is called the "handler". Most drivers are parsers, but that is not exclusive (a contrary example could be a module that queries a database, and generates SAX events based on results). Modules that are simultaneously handlers and drivers are typically called "filters". In *nix command pipelines, the similar terms would be "source", "filter" and "sink". Have fun, -Colin. |
From: Clark C. E. <cc...@cl...> - 2003-03-18 23:06:54
|
On Tue, Mar 18, 2003 at 02:03:37PM -0800, Colin Meyer wrote: | > Unfortunately, Reader is almost always coupled with Writer, | > java.io.Reader/java.io.Writer being but one of many examples. | > So, rather than call it a Writer, I've been using Emitter | > I tend to think of Emit not in the Radiological sense, but | > rather with the second more 'legal' meaning: | > | > To issue with authority; to voice; express an idea. | | In the Perl world (XML::SAX, XML::SAX::Base and associated modules), | code that creates SAX events is often called the "driver", and code that | receives such events is called the "handler". Most drivers are parsers, | but that is not exclusive (a contrary example could be a module that | queries a database, and generates SAX events based on results). Modules | that are simultaneously handlers and drivers are typically called | "filters". Thanks for the suggestions. On further reading, it seems that Microsoft's XML implementation is using Reader/Writer... so perhaps I was too quick to dismiss this pair. Reader has the added advantage of allowing Parser and Lexer to be distinct sub-components. Well... this part of the spec is about to go through one-more-small-rewrite, so what do we think? On to your suggestions... The difficulty with Driver is that the diagram is trying to convey a path from a flow of characters into a native data structure and then back. So, for this context, Driver is a bit too generic, although it'd be a great name for the Interface that a parser implements. I have a deeper problem with Handler, not only doesn't it convey that the target is text characters, but it goes on to imply a particular flow control -- push style, where the Handler is composed of a set of callbacks which are pushed events. Even though push parsers are easier to write than Pull parsers, I'd rather not have this bias enter the spec. Once again, YamlHandler is probably a great name for a "push" interface. | In *nix command pipelines, the similar terms would be "source", | "filter" and "sink". Sink is pretty neat. I like the streaming implications. But, once again, both source and sink kinda imply a program rather than something which converts text into a node stream or takes a node stream and makes text. Your feedback is really helpful; perhaps 'emitter' is too ugly. Brian/Oren is YamlReader YamlWriter better? Clark |
From: Bruce W. <br...@co...> - 2003-03-19 02:43:17
|
On Tuesday 18 March 2003 06:23 pm, Clark C. Evans wrote: | On further reading, it seems that | Microsoft's XML implementation is using Reader/Writer... so perhaps | I was too quick to dismiss this pair. Is it just me, or does the above just sound wrong? I've heard very, very few people laud MS handling of XML (or any open standard, of course)-- especially during implementation. -- author: Bruce R. Williams url: http://codedbliss.com irc: { nick: iusris, channel: [ruby-lang,yaml], server: irc.freenode.net } quote: > It does not require a majority to prevail, but rather an irate, tireless minority keen to set brush fires in people's minds.' -- Samuel Adams |
From: Clark C. E. <cc...@cl...> - 2003-03-19 15:51:28
|
On Tue, Mar 18, 2003 at 09:41:16PM -0500, Bruce Williams wrote: | On Tuesday 18 March 2003 06:23 pm, Clark C. Evans wrote: | | On further reading, it seems that | | Microsoft's XML implementation is using Reader/Writer... so perhaps | | I was too quick to dismiss this pair. | | Is it just me, or does the above just sound wrong? | | I've heard very, very few people laud MS handling of XML (or any open | standard, of course)-- especially during implementation. I like Parser/Emitter the best, Parser is almost perfect it represents a component which takes a character stream into some form that is more useable to a application program; but the problem with Parser is that it doesn't have a clean analogue... thus, after searching far and wide, I picked up on the term 'Emitter' which I heared someone on XML-DEV using for the opposite of a Parser. The advantage of Emitter is that it isn't overloaded with other meanings (it isn't in the Jargon file... yet). Reader/Writer is much more generic, I rejected it early on since, in my mind, it is tightly coupled with "man 2" read and write. Clark |
From: Brian I. <in...@tt...> - 2003-03-20 01:40:54
|
On 18/03/03 23:23 +0000, Clark C. Evans wrote: > On Tue, Mar 18, 2003 at 02:03:37PM -0800, Colin Meyer wrote: > | > Unfortunately, Reader is almost always coupled with Writer, > | > java.io.Reader/java.io.Writer being but one of many examples. > | > So, rather than call it a Writer, I've been using Emitter > | > I tend to think of Emit not in the Radiological sense, but > | > rather with the second more 'legal' meaning: > | > > | > To issue with authority; to voice; express an idea. > | > | In the Perl world (XML::SAX, XML::SAX::Base and associated modules), > | code that creates SAX events is often called the "driver", and code that > | receives such events is called the "handler". Most drivers are parsers, > | but that is not exclusive (a contrary example could be a module that > | queries a database, and generates SAX events based on results). Modules > | that are simultaneously handlers and drivers are typically called > | "filters". > > Thanks for the suggestions. On further reading, it seems that > Microsoft's XML implementation is using Reader/Writer... so perhaps > I was too quick to dismiss this pair. Reader has the added advantage > of allowing Parser and Lexer to be distinct sub-components. Well... > this part of the spec is about to go through one-more-small-rewrite, > so what do we think? > > On to your suggestions... > > The difficulty with Driver is that the diagram is trying to convey > a path from a flow of characters into a native data structure > and then back. So, for this context, Driver is a bit too generic, > although it'd be a great name for the Interface that a parser > implements. > > I have a deeper problem with Handler, not only doesn't it convey > that the target is text characters, but it goes on to imply a > particular flow control -- push style, where the Handler is composed > of a set of callbacks which are pushed events. Even though push > parsers are easier to write than Pull parsers, I'd rather not have > this bias enter the spec. Once again, YamlHandler is probably a > great name for a "push" interface. > > | In *nix command pipelines, the similar terms would be "source", > | "filter" and "sink". > > Sink is pretty neat. I like the streaming implications. But, > once again, both source and sink kinda imply a program rather > than something which converts text into a node stream or takes > a node stream and makes text. > > Your feedback is really helpful; perhaps 'emitter' is too ugly. > Brian/Oren is YamlReader YamlWriter better? AFAIAC, Parser and Emitter are excellent terms. I've always liked them. Cheers, Brian |