Re: Potential new issue: PSVI considered harmful

<noah_mendelsohn@us.ibm.com> wrote:


>
> I think we need to be careful about what sort of types
> we mean, and where they come from.  We need to be clear
> on the distinction between knowing the name of type,
> vs. knowing the meaning of the type.  ...
...
>
> Question: in which cases and to what extent can we envision
> doing what you suggest, I.e. provide some typing information
> in self-describing XML documents, for which schema-validation
> is not required?
...
>
>   3. Complex types.  (Yes, these are very useful
>      e.g. for mappings to databases and programming
>      languages) Now we're into territory where the
>      whole point is that different schema languages are
>      likely to have different models of how contents
>      are constrained.  Even the notion of such a type
>      is only natural in some schema languages.
>      Nonetheless, you can imagine the same sort of
>      approach as with ages above.
>
>      <width xxx:type="zzz:measurementType"
>              units="cm">
>                  15
>      </width>
>      <height xxx:type="zzz:measurementType"
>              units="inch">
>                  30
>      </height>
>
>
>      Without validation, you know the name of the type,
>      and you know that both elements have the same
>      type.  To understand what a measurementType is,
>      you need some particular schema language, but
>      not necessarily to do validation.  Only if you
>      want to be sure the document told the truth about
>      the type do you have to validate.
>

Agreed. This underscores why an umambiguous mapping of type names e.g.
QNames to URI references is so important. This mapping is perhaps the only
reasonable way a type indicated in such an XML instance document can be
connected to the schema fragment that defines the type.

> My point in listing the above cases is primarily to
> clarify that knowing the name of type to which an
> element/attribute claims to conform is very different
> from having useful knowledge of what the type means,
> which in turn is one step short of doing the validation
> to prove the document didn't lie about the type (which
> in turn is different from relying on the schema to
> assert the type name in the first place.)  In
> considering Tim's challenge to build self-describing
> documents, we need to consider the sort of types to be
> supported, what kind of information various
> applications will need, and where that information
> should come from.
>

Yes and this underscores the importance of tag-issue:rdfmsQnameUriMapping
err... http://www.w3.org/2001/tag/ilist#rdfmsQnameUriMapping-6

>
> Thus, I do think it is a very good thing that a
> language such as W3C XML schema takes the trouble to
> carefully describe and formalize the information that's
> known after a validation.  Yes, a different language
> might provide less information or more as a result of
> validation (e.g. might tell you only about validity,
> not defaults or types), but that's a nearly orthogonal
> issue.  What you do know, you should formalize, IMO.
> The proposal to rule out PSVI's could be taken as
> discouraging such formalization;  I suspect that's not
> quite what was intended.

Agreed that we should be careful to distinguish between the concept of a
general PSVI or TAI vs. a specific incarnation of such tied to only one of a
number of languages that can express constraints on pieces of XML.

>
> Some of what you know from validation will necessarily
> be schema-language specific.  Thus, it's likely that
> there will be a somewhat different PSVI for each schema
> language.  Layering those things that might also be
> known before validation (e.g. type names) or factoring
> those likely to be common across many schema languages
> (primitive type names?) seems like a good thing, but
> not in conflict the need to have a language-specific
> PSVI for the rest.

Perhaps each language specific "PSVI" ought derive from a general "TAI"
which is what we ought focus on.

Jonathan

Received on Thursday, 13 June 2002 19:55:58 UTC