On 25/02/04 11:00 +0200, Oren Ben-Kiki wrote:
> Brian wrote:
> > > > In other words, if there is no "schema" or "contract",=20
> > > > two different=20
> > > > loaders will probably load the same document in different=20
> > > > ways. And=20
> > > > this is perfectly OK. It all depends on the application that is=20
> > > > using YAML. On the specific use case.
> So far, so good, but:
> > > > You cannot take a random YAML document from Perl, pass it through=
> > > > Ruby, and expect it (beyond a shadow of a doubt) to come back=20
> > > > intact.
> I *do* expect to be able to load a YAML document from Perl into Ruby and
> re-emit it "intact", regardless of the schema. That's the whole point of
> the "information model" - it defines what information must be preserved
> for the result to be "the same" as the input.
I agree with you in principle. My point was more along the lines of a
practical scenario. If you pass empty keys around between
implementations without explicit typing or some kind of schema, you are
basically playing "fast and loose" with YAML, and shouldn't be surprised
if your empty keys turn into empty strings along the way.
ie If you have the following document:
And load it into memory using a stock no-frills Perl loader, I would
expect the key to load as a string (since Perl only uses strings for
keys). And it might get dumped as:
And that's ok really because it was the most right thing to do. Perl
shouldn't jump through hoops to preserve every pedantic semantic (heh),
since there isn't a shred of schema assistance attached.
> It doesn't matter that the Ruby loader uses a different "cave drawing"
> than the Perl loader to represent each node. If the Ruby loader emits a
> "different" document, than it isn't really working properly. For
> example, if I write a YAML pretty-printer in Ruby, it would be very bad
> if it changed the document semantics.
Of course it would. I agree with this and everything else below.
> > > > *Unless* there is a schema associated with the=20
> > > > document. Or=20
> > > > unless the classes in Perl and in Python have been=20
> > > > designed to work=20
> > > > with each other. Which is really a different form of a=20
> > > > "schema" or "contract".
> A schema helps in two ways. First, if the Ruby loader fails to preserve
> all the information required by the YAML spec, but the specific schema
> doesn't ever use the lost information (e.g., never uses implicit
> typing), then the application is still "valid YAML", even though the
> loader isn't. I expect this to be rather rare, though.
> Second, and more importantly, you must agree on a schema/contract in
> advance if you want a YAML document generated by Perl to load into
> "meaningful" Ruby - that is, into "compatible" classes with "the same"
> semantics. In fact this holds when transferring a document between any
> two different processing systems.
> Brano Tich=FD asked:
> > > i found several schema proposals at=20
> > > http://yaml.freepan.org/index.cgi?SchemaProposals,
> > > but is there any plans to have standard way to attach schema to=20
> > > document? or is this again application specific?
> Yes and no. Like Brian said:
> > There will most likely be conventions that arise, and that=20
> > YAML-core endorses.
> > Take a sample document:
> > --- !ingy.net,2004/floozle
> > date: 1/2/2004
> > name: Duck Soup
> The !ingy.net,2004/floozle tag is the standard YAML way to associate a
> schema with the document. However, all the YAML gives you is a URI -
> globally unique identifier - for the schema. It does not specify the
> mechanism by which you convert this URI into whatever concrete form you
> expect the schema to take.
> This is intentional. There is a range of concrete forms the schema may
> take - human-readable documents, various declarative languages for
> verification, and even code libraries that may be loaded dynamically for
> processing the document. Similarly, there is a range of mechanisms that
> may be used to locate the concrete schema - using protocols such as http
> or ftp, accessing a database, and so on. Inevitably, different
> applications running in different systems will have different choices of
> the format and mechanism. It may even be that the same application may
> use multiple mechanisms simultaneously (e.g., fetching separate
> "verification schema" and "loading schema").
> That's why the schema tag is a UR*I*, rather than a UR*L* - it merely
> *identifies* the schema, it does not *locate* it.
> > I'm sure Clark and Oren have ideas on how this might work.
> I have a lot of ideas on how schema location may work, but I firmly
> believe it is outside the scope of the YAML standard itself.
> Have fun,
> Oren Ben-Kiki
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> Yaml-core mailing list