On Mon, Sep 06, 2004 at 04:36:48PM +0100, David Hopwood wrote:
| In the context of #7a, this is determined by whether the full names
| of the unspecfied tags look like absolute URI references, i.e. whether
| they match (scheme ":" uric*).
In the proposal that I put out; the unspecified tags are 'global' tags.
However, I don't see why this is an important distinction. The !!seq,
!!map, and !!str tags can easily be from tag:yaml.org,2002: The tag
for the unspecified plain scalar is a bit more problematic:
- If it is a !unspecified-implicit-scalar private tag then
the YAML Graph produced from the document will be 'partial',
that is, it would not be possible to determine if two tags
using the implicit format are equal. Thus, the tag would
require the application 'recognize' it for it to be useful.
- If it is a !!imp from tag:yaml.org,2002: global tag, then a
document only using implicit tagging would be a Complete
YAML Representation. The up-side of this option is that
the YAML Spec keeps its 'default' tags in tag:yaml.org,2002:
In some ways, the !private-tag reflects the uncertainty of using !!imp;
I'm not sure at this point why one would be preferred over the other,
| If they do, then Clark's view is correct: since it is possible to
| write these tags explicitly in a document, some documents must be
| described as syntactic sugar for others. Also, it is possible to
| write things like, !!unspecified-plain "but quoted"
Ok, so you seem to be saying that !!imp is _OK_
| If the unspecified tags don't like like absolute URI references, then
| Oren's view is correct: in that case these tags cannot be written
| explicitly in documents, and are not syntactic sugar.
While !unspecified-implicit-scalar (a private type) is not. I'm curious
why? I would assume that this case would be treated just like I found
!private in the text. It is 'unrecognized', and thus only a partial
YAML representation is possible (ie, one that doesn't necessarly force
uniqueness constraints correctly).
| The main advantages of being able to describe tag specification just
| as a graph transformation, rather than as a special process with
| different input and output models, apply in either case.
Right. This is the main advantage, it doesn't require implementations
to have a "API" for loading "implict tag resolvers".
| Note that any schema language will need to be able to refer to the
| unspecified tags. It would be convenient to use the same tag-specifier
| syntax to do this (whether the references to tags in the schema
| language are actually tag-specifiers or just look like them depends
| on how the language is constructed).
I think you are mis-understanding what "resolution" does. It happens
_before_ the YAML Representation is constructed. A YAML Schema, in
theory, would _never_ know that an implicit tag had been provided. If
you want this feature, resolution is out.
| 2. Whether the step that is currently called "resolution" just specifies
| tags (Oren), or whether it is an arbitrary transformation (Clark).
In my proposal, the arbitrary transformation is optional, and if it
exists, completely determined by the application. A paragraph may
go in the spec mentioning the possibility and reminding the
implementer to follow the model, and/or suggesting a reverse transform,
but that's as far as the spec would go.
Oren's proposal mandates a very weak, limiting transformation. This
requirement seems quite arbitrary.
| IMHO, it is useful to define "tag specification" to describe only
| transformations that change unspecified tags to specified ones,
| and "fully specified" to describe graphs that contain no unspecified
Why? I don't see any reason why the tag must be changed; I see a few
use cases where one would want to keep things _without_ a transformation:
- A schema language may want to check for structure of things
using only the four basic tags, !!seq, !!map, !!str, and !!imp
- A programming environment may want to provide a 'imp' like object
that isn't a string, but acts just like an imp. For example, a
Python binding could provide a Numeric type that allows '3' and
'3.0' to appear as mapping keys, yet, otherwise behave as numbers.
I may want to use a YAML Transform or Schema as described by another
spec (using a YAML Representation as its model) to make application
specific determinations of how unspecified implicit tags should be
treated. Depending on regex, paths, or some external logic, I may
want some nodes to be integers, dates, booleans, or what not. If
I have to _resolve_ my data before I can use a Transform/Schema,
it really complicates my life, and unnecessarly.
| Apart from defining these terms, I don't think that the main
| YAML spec needs to say much if anything about either transformations
| between representations, or conversion of representations to native
| data structures. These are too language-, API- and application-specific
| to go in the main spec.
Agreed, while I may not have been clear, this was always my intent
(it said "optional" and "may" in my original pass many times). I was
trying to describe how an application could provide replacement
behavior for the 'resolution' process in a more general context.
without irbe yrih Agreed. And I'm suggesting that this 'resolution' phase be
removed from the spec as well.
| 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.
| Yaml-core mailing list
Clark C. Evans Prometheus Research, LLC.
o office: +1.203.777.2550
~/ , mobile: +1.203.444.0557
(( Prometheus Research: Transforming Data Into Knowledge
\/ - Research Exchange Database
/\ - Survey & Assessment Technologies
` \ - Software Tools for Researchers