W3C home > Mailing lists > Public > www-tag@w3.org > June 2002

Re: Potential new issue: PSVI considered harmful

From: Jonathan Borden <jonathan@openhealth.org>
Date: Thu, 13 Jun 2002 19:42:14 -0400
Message-ID: <00c101c21333$f2a0cec0$0201a8c0@ne.mediaone.net>
To: <noah_mendelsohn@us.ibm.com>, <www-tag@w3.org>

<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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:32 UTC