W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2005


From: Danny Vint <dvint@dvint.com>
Date: Sun, 21 Aug 2005 09:13:08 -0700 (PDT)
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Cc: Udo Ende <u.ende@mid.de>, xmlschema-dev@w3.org
Message-ID: <Pine.LNX.4.62.0508210902190.22714@gimli.dreamhost.com>

I see that ID is recommended for compatibility to be only used on 
attributes. I understand that if I had a DTD that this is the only place 
an ID value is going to be recognized, but if I'm not concerned about that 
use or situation, can I use ID as the type of an element and have it be 
recognized by XPath and XSLT? Specifically is the id() function supposed 
to find the matching ID in an elements content? In a schema situation, can 
I have an attribute as the IDREF, that references an element of type ID 
and have it valdiate that content as well as make sure there is no 
attribute of type ID with the same value.

Bottomline, can I expect normal ID/IDREF processing with a schema if I use 
an ID or IDREF as element content? Does a schema enforce the rules 
regardless of this compatibility statement?


Danny Vint

Specializing in Panoramic Images of California and the West

FAX: 801-749-3229

On Fri, 19 Aug 2005, Henry S. Thompson wrote:

> Hash: SHA1
> Udo Ende writes:
>> Can I only declare a leaf element of type IDREF or how can I reference an
>> element of complexType via ID/IDREF?
> You can have an attribute of type ID or IDREF on any element, simple
> or complex.
> ht
> - --
> Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
>                     Half-time member of W3C Team
>    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
>            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
>                   URL: http://www.ltg.ed.ac.uk/~ht/
> [mail really from me _always_ has this .sig -- mail without it is forged spam]
> Version: GnuPG v1.2.6 (GNU/Linux)
> w9phEpiU7b293Ff+ga/5/uQ=
> =0R/R
Received on Sunday, 21 August 2005 16:13:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:30 UTC