headers
Clark C. Evans | 1 Sep 2004 01:36
Gravatar

Re: Simple Prefix Namespace Proposal

On Wed, Sep 01, 2004 at 01:47:19AM +0300, Oren Ben-Kiki wrote:
| Clark, Brian and myself just went through a heated debate on this in
| IRC.  Here's what we hope is a reasonable compromise (Brian had to
| leave so he may  have further comments).

While we've had a tag system for quite some time, it has several known
warts.  While the cut^paste mechanism functions well for single
namespaces, it fails when mixing namespaces in a document. The tag
shortcuts are also quite subtle and difficult for newbies to pickup.
These complications were added to support globally unique identifiers.
The result is that the average user (who may not want globally unique
identifiers) is burdened with complexity.  A change has been coming for
some time, I want to thank those who kept complaining. ;)

To complicate this problem, we seem to have a difference in vision at
the top.  Brian stronly feels that globally unique identifiers do not
belong in a document, and is opposed to any directive.  I feel that
unique identifiers are essential for lots of nerdly uses.   The proposed
compromse "philosophy" is:

  By default, all types should be private; unless you want to
  pay for uniqueness with additional pain.

| So. Here's the proposal in a nutshell:
| 
| - There are two kind of tags.
| 
| - Tags using the format "!prefix:stuff" (where "stuff" doesn't 
|   start with ':') are globally unique tags. The prefix _must_ 
|   be declared in a directive (see below).
(Continue reading)

Permalink | Reply | 8 comments |
headers
T. Onoma | 1 Sep 2004 02:06
Favicon

Re: Simple Prefix Namespace Proposal

On Tuesday 31 August 2004 07:36 pm, Clark C. Evans wrote:
> Thoughts?

So what's !int ?

--

-- 
T.

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
Permalink | Reply | 1 comment |
headers
T. Onoma | 1 Sep 2004 03:44
Favicon

Re: Prolegomena to Any Future Schema

On Monday 30 August 2004 06:51 pm, T. Onoma wrote:

I just want to talk about Schema since I am near putting together my proposal 
for "YASL".

For the sake of simplicity lites make the stupidest little schema language in 
the know universe. It an only do one thing that any really useful schema will 
certainly be able to do, and that is to designate real Type given a Tag 
inference. The syntax of our poor schema will be likewise poor quasi-English, 
but that should be enough for our purposes here.

Here is my document:

  ---
  a: !int 1

And my first schema says

  All tag:int are yaml.org,2002:int.

Good? Let's try another.

  ---
  b: !yaml:str b

This time my schema is feeling a little contrary and says

  All prefix:yaml is really toms.org,2004/.

Huh. that's odd, but if the schema says so.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian Ingerson | 1 Sep 2004 05:10

And Now For Something Compleatly Different

Well not really completely different but...

Yes Clark Oren and I had a wicked debate on irc. They have tried to
represent me in the follow up posts, but have not really captured the
vision of where I want this to go. I'll try to be explicit and blunt
about my ideas in this post, although when I do this, things still seem
to get misinterpreted. But here goes anyway...

I'll just start by making some assertions in no particular order:

1) A YAML *document* cannot by itself contain all the semantics that all
   applications need for successful processing.

Well they could of course, but then it would not be YAML. YAML is nice
because it is clean and easy to read. There is just enough information
there that a person can read the document and say, yeah I see where
this is going.

2) To make a YAML document semantically complete in a given context,
   requires a thingy we refer to as a "schema". This is a body of code
   and or text that contains all the hints to add onto the information
   in the document that completes the YAML Information Model.

A schema can be as simple as the instructions in a Python program that read
config file:

    ---
    name: Brian Ingerson
    age: 21
(Continue reading)

Permalink | Reply | 97 comments |
headers
Clark C. Evans | 1 Sep 2004 05:47
Gravatar

Re: Simple Prefix Namespace Proposal

On Tue, Aug 31, 2004 at 08:06:37PM -0400, T. Onoma wrote:
| So what's !int ?

According to the current specification, it is "cooked" to become
'tag:yaml.org,2002:int' in the YAML Representation model, and according
to the YAML type repository, implementations would be obligated to load
such a node into an 'integer' of sorts.  I feel this is rather
"reasurring" value, if you see !int in a YAML document, you know it is
an integer.  I think this is a good feature, I like it.

Unfortunately, as you point out, the current specifcation doesn't
provide a nice way to mix different globally unique tags in the same
document.  So, we need some sort of prefix mechanism to make this
use case work.

My preferred solution is to add a syntax-level %tag/prefix mechanism,
making clear notes that it is presentation issue only, and does not go
into the serialization or representation models (and thus, never makes
it into the parser API).  I'd leave current shortcuts alone, as I think
they are a great compromise for inter-language data transfer and
readability.  I would deprechiate the cut^paste hack.  Note, that this
preferred solution would just add another syntax-level trick (we got
tons of them for data, why not one more for tags?).  Since a !tag cannot
currently look like !prefix:value, this is a no-brainer.

I'm not sure Oren would buy this, he seemed to want to get rid of
the various syntax shortcuts for building a 'taguri' with the
introduction of this %tag: directive.

As for Brian, I would have thought two weeks ago that he'd be more open
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clark C. Evans | 1 Sep 2004 06:21
Gravatar

Re: And Now For Something Compleatly Different

There are several concepts masking around as 'schema', often when I use
schema, I refer to it as a set of types, each type identified by a tag.
Let's call this a tagset, or namespace.   

Some tagsets, like YATL, may have tags, which allow children with tags
from other tagsets, without knowing what those tagsets are or what the
meaning of tags in those tagsets have.  A transformation language is
a good example of such a use case.

On Tue, Aug 31, 2004 at 08:10:47PM -0700, Brian Ingerson wrote:
| 10) That said, tags can be minimal. They don't need to be globally
|     unique until they are comsumed by the loader. Until they are ready
|     to be judged against a schema to determine what they really mean, So
|     a tag only needs enough info to clearly disambiguate a node of one
|     meaning from a node of another.

[in the context of a particular schema].  What happens if you have a
document that takes nodes from two differnet tagsets?  How are you going
to automate the process or merging them, or does the burden of mingling
tags from different sets fall onto the application developer?

This doesn't work with my use case.

| 13) A Parser must now report the GUID to the Loader. This is a new
|     concept. Clark would have you believe that a parser cooks info from
|     the GUID into each tag. I say no way. A parser reports the GUID and
|     all the other simple events. Period.

You are trying to find a single GUID that represents the schema
for the document?  Where 'schema' here means complete knowledge of
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hopwood | 1 Sep 2004 06:29
Picon
Favicon

Re: Prolegomena to Any Future Schema

T. Onoma wrote:
> This time my schema is feeling a little contrary and says
> 
>   All prefix:yaml is really toms.org,2004/.
> 
> Huh. that's odd, but if the schema says so.
> 
>   --- %tag:yaml.org,2002:/|yaml   # I assume that's right
>   b: !yaml:str b
> 
> But, who's right? The tag directive or the schema?

The %tag directives in the application document are used to expand its
tags to full URIs. The %tag directives in the schema document are used
to expand its tags to full URIs. If the parsed application document is
then matched against the schema and the full URIs do not match, then
the document will not validate. This is correct; it shouldn't validate.
I don't see the problem.

David Hopwood <david.nospam.hopwood@...>

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
Permalink | Reply | 1 comment |
headers
T. Onoma | 1 Sep 2004 08:04
Favicon

Re: Prolegomena to Any Future Schema

On Wednesday 01 September 2004 12:29 am, David Hopwood wrote:
> T. Onoma wrote:
> > This time my schema is feeling a little contrary and says
> >
> >   All prefix:yaml is really toms.org,2004/.
> >
> > Huh. that's odd, but if the schema says so.
> >
> >   --- %tag:yaml.org,2002:/|yaml   # I assume that's right
> >   b: !yaml:str b
> >
> > But, who's right? The tag directive or the schema?
>
> The %tag directives in the application document are used to expand its
> tags to full URIs. The %tag directives in the schema document are used
> to expand its tags to full URIs. If the parsed application document is
> then matched against the schema and the full URIs do not match, then
> the document will not validate. This is correct; it shouldn't validate.
> I don't see the problem.

ERROR! So the Schema was right. The document was wrong (INVALID). Well, if the 
schema knows best then why were we trying to do its job for it anyway? We can 
save ourselves the headache and give type authority to one entity: the 
schema, (IMHO) where it belongs. Granted the author can still get errors, but 
it won't be because she was trying to do the schema's job.

A schema is like a library. At the top of your yaml doc, you say: this doc 
complies with schema ZTX-80 of blueberry-bogs.net cric 2004. The docs 
exaplain the schema saying, you have these tags: !blue, !berry, !bog/deep 
and !bog/shallow, and then explains any structure formats that must be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oren Ben-Kiki | 1 Sep 2004 09:19
Gravatar

Re: And Now For Something Compleatly Different

OK, long answer... Sorry, I didn't have the time to make it shorter...

Summary: I think the compromise (suggested by Clark) that I posted is the best 
solution to the problem. It addresses all(most) Brian's points.

The only disagreement left is narrowed to a single question. Is a single GUID 
plus schema-specific "tag globalization" enough, or should there be a 
standard purely syntactical mechanism for "tag globalization"? With this in 
mind...

There are two different steps required in making a document be "completely 
known".

- Step #1: For each node, compute a unique id identifying its type. The spec 
calls this "tag resolution". Hence I use "tag globalization" for the act of 
converting a "!stuff" into a GUID. Less confusion.

- Step #2: Given you know the id of the type of the node, map it to the 
appropriate data structure/behavior/cave drawing. The spec calls this 
"constructing".

Both these steps are determined by the "schema". Not the parser job. Fine.

The question remains: what is the _input_ to step #1?

A. GUID tags for some subset of the nodes (current spec, Clark, myself)... or

B. A single (possibly implicit) GUID identifying the schema plus arbitrary 
schema-specific tag-globalization mechanism per node (Brian, Onoma).
(Continue reading)

Permalink | Reply | 38 comments |
headers
Brian Ingerson | 1 Sep 2004 10:31

Re: And Now For Something Compleatly Different

On 01/09/04 10:19 +0300, Oren Ben-Kiki wrote:
> OK, long answer... Sorry, I didn't have the time to make it shorter...
> 
> Summary: I think the compromise (suggested by Clark) that I posted
> is the best solution to the problem. It addresses all(most)
> Brian's points.

I'm not buying it. Looks like another irc session is in order. Prepare thine
defenses... :P

Cheerzzzzzz, Brian

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
Permalink | Reply | 0 comments |

Gmane