[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: Faroukh Fekravar <email@example.com>
- To: Eddie Robertsson <firstname.lastname@example.org>
- Date: Tue, 13 Feb 2001 17:41:43 -0600
Thanks for the info. Yes, that's exactly what I wanted. However,
I like to avoid declaring all keys/keyrefs at the root level.
The problem is that we'll have 100s of elements and any kind
of relationship between those.
The reason that I have a root element called Project and most likely
refs to all those 100s of elements from it, is that, the user is theoretically
able to instantiate any of those within a project (that's why Item1 like the
others is optional). However if any of those instantiated, there should be
a key for that Item.
We have in our model a deep abstraction and at it's highest level
a key is defined. The very high levels of abstraction are abstract,
and the type of concrete level (sub-types) do extend the high level
abstract types. But because the key can be defined just within
an element, I'm forced to have abstract elements and types and repeat
the key at each and every level. I may miss somthing here in regard of
abstraction of types and elements and the dentity-constraint.
Having all of keys/keyrefs at root level is extremely confusing.
Is there any other way that I can achieve same thing and avoiding
overloading the root?
Eddie Robertsson wrote:
> > Folks,
> > I'm validating my xml instance (generated manually) based on the schema
> > below by using XSV
> > and get the 'cvc-identity-constraint.2.3.2' error.
> > (No key or unique constraint named Item1Key declared, refed by keyref
> > Item2_KeyRef)
> > I'm not usre whether I'm missing something here or XSV has some
> > limitation/bugs.
> >XML Instance:
> ><Item1 Item1_2="123">
> ><Item2 Item2_2="123">
> > <Item2_1>999</Item2_1>
> > </Item2>
> I don't think that XSV has fully implemented the validation regarding keys
> and keyref yet but I don't think that is the problem with your schema. From
> what I can understand of your instance above you want to define a key for
> Item1/@Item1_2 and then reference this key saying that the value of
> Item2/@Item2_2 must be the same as an already existing Item1/@Item1_2.
> If this is correct you must declare the key in the scope of where you want
> it to be unique and in this case you want the Item1/@Item1_2 value to be
> unique within the scope of the Project element. This means that the key
> should be declared within the scope of the Project element and not within
> the scope of the Item1 element. The same will apply to your keyref
> declaration, it should be declared within the scope of the Project element
> instead of the Item2 element. This means your schema should be:
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
> elementFormDefault="qualified" targetNamespace="www.allette.com.au/keyref"
> <xsd:element name="Project">
> <xsd:element ref="Item1" minOccurs="0"/>
> <xsd:element ref="Item2" minOccurs="0"/>
> <xsd:key name="Item1Key">
> <xsd:selector xpath="Item1"/>
> <xsd:field xpath="@Item1_2"/>
> <xsd:keyref name="Item2_KeyRef" refer="Item1Key">
> <xsd:selector xpath ="Item2"/>
> <xsd:field xpath ="@Item2_2"/>
> <xsd:element name="Item1">
> <xsd:element name="Item1_1" type="xsd:string" minOccurs="0"
> <xsd:attribute name="Item1_2" type="xsd:string" use="required"/>
> <xsd:element name="Item2">
> <xsd:element name="Item2_1" type="xsd:string" minOccurs="0"
> <xsd:attribute name="Item2_2" type="xsd:string" use="required"/>
> But remember that I don't think XSV has fully implemented the validation of
> key and keyref. I also noticed that in the above schema you have declared
> your Item1 element as being optional (minOccurs=0) but when you define
> Item1/@Item1_2 as a key this attribute _must_ appear in an instance.
Faroukh Fekravar Schlumberger Austin Product Center
Principal Reservoir Engineer 8311 North 620
Software Product Integration, Austin, TX 78726
Data Modeling Voice: (512) 331-3348
E-mail: email@example.com Fax: (512) 331-3075