Re: [Yaml-core] "unknown types" / "weak equality" are out-of-scope

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

On 17/10/03 01:55 +0200, Oren Ben-Kiki wrote:
> Clark C. Evans wrote:
> > Right.   So, a YAML document can be valid, indeterminant, invalid.
> > If two unknown scalars are used within a mapping, and they 
> > have the same tag and value, then the mapping (and thus the document)
> > is invalid.   If a mapping contains two unknown scalars of the
> > same tag but different values, then the mapping (and thus the
> > document) is indeterminant.   Therefore, the possibility of unknown 
> > typing implies that a given YAML document in the context of a 
> > given YAML processor may have three states; if the state is 
> > invalid or valid, then this designation holds regardless of 
> > the processor used.
> 
> Right. Note that this depends on the weak model, since in effect you are
> performing weak equality tests on the keys.
> 
> > Ok.  So if YPATH uses the 'value' of a scalar, and the scalar 
> > is not known, then a warning should be given.
> 
> +1.
> 
> > | If on the other hand you accept that YSLT _by itself_ makes no 
> > | guarantees about the validity of input/output documents
> > 
> > This is the best approach... probably.
> 
> :-)
> 
> > | IMO the right solution is to distinguish between 
> > | schema-aware/specific 
> > | applications and schema-unaware/generic tools.
> > 
> > I'm not sure what you mean by schema aware/unaware.
> 
> I don't mean YSCHEMA. I mean "aware of all the types, and probably loads
> them to native types". That is, an application loading a YAML document
> to an Outlook calendar would be "schema aware" while YAML-Pretty-Print
> would be schema unaware.
> 
> > I see a 
> > schema as a transformation that changes !str typing into 
> > !whatever typing.
> 
> First, I try never to use the words "schema" and "transformation" in the
> same sentence. To me, a schema (YSCHEMA) is a Boolean predicate that may
> be applied to a document (valid/invalid). No transformations involved.
> 
> Of course, of necessity every loader computes such a Boolean
> (loadable/unloadable); hence every application that loads YAML to a
> native type (strong model, _not_ generic nodes) is by definition "schema
> aware".
> 
> > | The former always work at the strong model and pose no problem.
> > | The latter must fall back to the weak model when unknown tags are 
> > | encountered, and can only guarantee the validity of their output 
> > | given that their input was valid in the first place. 
> > 
> > I assume you mean this to be granular, ie, a loader can 
> > create both native nodes when it knows the !tag, and 'generic scalar' 
> > nodes when it doesn't.   As such, I see one model, with each
> > tag in the system having a flag if it is known or unknown.  I 
> > am not comfortable with two models (a weak vs a strong) as 
> > the problem is more complicated than this and for the model 
> > section to be valuable it must describe the interaction 
> > between nodes of a known and unknown types.
> 
> Not so. The weak model is exactly this mixture of known and unknown
> nodes you refer to, while in the strong model all nodes are known. At
> least that was the decision we reached after trashing this issue for an
> inch of its life :-)
> 
> I feel it is essential to define the pure/core/known "strong" model as
> this is the motivation for everything else. Defining it allows us to
> specify the true core of YAML, what applications actually need to
> consider when YAML-ing their data - how to cast their data in the form
> of map/seq/scalar, and nothing else.
> 
> We both agree that we also need a model where some tags are "known" and
> some are "unknown". That's the model you refer to when you say you see
> "one model". Its name is the "weak" model to distinguish it from the
> pure/core/known "strong" model. I feel it would be a mistake to neglect
> the "strong" model because that would mix together issues of weak
> equality and handling unknown types that are better separated from the
> core issue of map/seq/scalar modeling of data.
> 
> > Right.  So, nodes with an a tag which is unknown to a given 
> > processor will have a set of warnings to be used when the 
> > node is used in an equality setting (recursively defined) or 
> > when looking 'into' the
> > string value during a process.   This way literal copying does not
> > issue a warning, but just about every other use of scalars 
> > with an unknown tag does.
> 
> +1. This is all weak model stuff.
> 
> > On Thu, Oct 16, 2003 at 09:49:08AM -0700, Brian Ingerson wrote:
> > | Most everything boils down to:
> > |   * ALWAYS CONSIDER: Schema Blind vs Schema Aware
> > |   * Generic YAML processors should be as forgiving as possible
> > |   * Specific applications should be as rigid as they need to be
> 
> +1.
> 
> > Yes; although I'd also say that the default behavior for a 
> > YAML processor should be to notify the user of a potential 
> > problem due to an unknown type; and to let this notification 
> > be turned off.
> 
> +1.
> 
> > | I asserted to Clark that at the YPATH "level" you always 
> > | know the tag 
> > | by definition.
> > 
> > And this assertion is wrong.  As you may use YPath to select a 
> > node from a graph where the node selected has an "unknown tag".
> 
> +1.

There is a complete skew in semantics going on here. Specicically the
semantics of "know".

If a node is tagged '!boogle', you *know* what its tag is: 'boogle'.
Your loader may not have a specific native type adapter for it. In that
case, the loader has two choices:
  * reject the node
  * graph the node using a ynode

My assertions are:

* YPATH can be thought to only operate an a graph of pure ynodes.
* A ynode always has a tag
* The tag (and string value) should be considered canonical/strong to
  YPATH

If this does not produce the desired results, you need to rework your
loader schema.

Cheers, Brian
> 
> Have fun,
> 
> 	Oren Ben-Kiki
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Yaml-core mailing list
> Yam...@li...
> https://lists.sourceforge.net/lists/listinfo/yaml-core