[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Type-assignment (was Re: Are we losing out because of grammars?)

• From: James Clark <jjc@j...>
• To: Murata Makoto <mura034@a...>
• 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

• Follow-Ups:
  • Re: Type-assignment (was Re: Are we losing out because of grammars?)
    • From: Murata Makoto <mura034@a...>
  • Re: Type-assignment (was Re: Are we losing out because of grammars?)
    • From: Murata Makoto <mura034@a...>
  • Re: Type-assignment (was Re: Are we losing out because of grammars?)
    • From: "K.Kawaguchi" <k-kawa@b...>

• References:
  • Type-assignment (was Re: Are we losing out because of grammars?)
    • From: Murata Makoto <mura034@a...>

• Prev by Date: Re: Type-assignment
• Next by Date: Re: Type-assignment (was Re: Are we losing out because of grammars?)
• Previous by thread: Re: Type-assignment
• Next by thread: Re: Type-assignment (was Re: Are we losing out because of grammars?)
• Index(es):
  • Date
  • Thread