[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Type-assignment (was Re: Are we losing out because of grammars?)
- From: James Clark <jjc@jclark.com>
- To: Murata Makoto <mura034@attglobal.net>
- Date: Fri, 02 Feb 2001 12:03:51 +0700
Murata Makoto wrote:
>
> James Clark wrote:
>
> > - You seem to think type-assignment is very important. Why?
>
> First, to implement ID/IDREF/IDREFS, we need type-assignment,
> or at least have to unambiguate relevant parts of the grammar.
Yes, indeed. ID/IDREF is a very interesting problem for TREX. However,
although type-assignment can be used to deal with this, it's not quite
solving the right problem. For ID/IDREF, I want to know whether I can
assign datatypes unambiguously not whether I can assign labels (in the
RELAX sense) umabiguously. A grammar may be ambiguous with respect to
assignment of labels, but unambiguous with respect to assignement of
datatypes.
My current thinking is that the ID/IDREF approach to uniqueness
constraints doesn't really scale. For example, there's no way I can see
to make it handle multipart keys. ID isn't purely a datatype in the same
way that NMTOKEN is: making an attribute have type ID has side-effects
on the validity of other attributes that making an attribute have type
NMTOKEN does not. I think it's better therefore to move to a completely
different approach to handling uniquessnes and cross-reference
constraints, more along the lines of the identity constraints in W3C's
XML Schemas.
Another interesting issue with ID and with type-assigment is how it
interacts with intersection (the "concur" operator in TREX). What do I
do with something like this
<concur>
<element name="e">
<attribute name="a">
<data type="xsd:ID"/>
</attribute>
</element>
<element>
<anyName/>
<zeroOrMore>
<attribute>
<anyName/>
</attribute>
</zeroOrMore>
</element>
</concur>
?
> James Clark wrote:
>
> > It depends how you restrict the grammar. If you restrict the grammar as
> > much as W3C's schemas, type assignment is significantly simpler than
> > validation (since I believe I am correct in saying that for W3C schemas
> > the type of an element depends only on its name and the names of its
> > parents).
>
> I believe so too. On the other hand, because of this restriction, XML Schema
> is not closed under boolean operations, and cannot prohibit the first para
> from containing footnotes while allowing the other para to contain footnotes.
> (I have to admit that this concern is rather theoretical.)
I think closure is not just of theoretical importance. This is one
reason why I want to keep type-assignment and validation separate: it's
useful to have the validation be closed under
union/intersection/difference, even if type-assignment isn't. I think I
can live with fairly trivial type-assignment (as in W3C's XML Schemas),
which allows type assignment to be done in a single, streaming pass, but
I want to have more sophisticated validation (which can also be done in
a single, streaming pass).
James