[
Lists Home |
Date Index |
Thread Index
]
actually you are right, there is nothing much to comment on.
I think this characteristic of XML-Schema is not desirable. I cannot say
for sure, but it looks as if W3C XML-Schema is actually defying a
formalism, which I would assume it should follow.
Why do we not place a constraint on wild-cards as such -- "the tag name of
the element that is validated by a wild-card should follow the unique
particle attribution as such -- there should not exist an element with the
same tag name that can be validated with a non-wild card type"
in the example below, the zip element cannot be validated by wild-card, as
there is another element declaration for zip.
anyways.. cheers and regards - murali.
On Mon, 3 Jun 2002, Dare Obasanjo wrote:
> I'm not really sure there is anything to comment about. You assume that
> one of the goals of W3C XML Schema is "the type of an element will
> change only if its content is modified". Basically only the W3C XML
> Schema WG can answer this question conclusively.
>
> On the other hand, if you are claiming that this rule is specified by
> some predefined formalism which W3C XML Schema is supposed to follow but
> does not then there is something to comment on.
>
> So which is it?
>
> Murali Mani wrote:
>
> > > You say that "any XML type system (even those based on tree
> > > expressions) will have problems with having to alter the type of an
> > > element if some of its content is modified."
> > >
> > > I agree -- I think that one of the unspecified goals of XML
> > Schema is
> > > that "the type of an element will change only if its content is
> > > modified"
> > >
> > > that is what is being violated, right? we have not changed
> > the content
> > > of <zip>90024</zip> in any way, but the type assignment has to be
> > > changed.
> > >
> > > I think the above is very subtle, and i am not sure if I am making
> > > sense.
> > >
> > > I think we can definitely handle this, but still..
> > >
> > > cheers and regards - murali.
> > >
> > > > > On Fri, 31 May 2002, Eddie Robertsson wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > > regarding updates -- I had a question how updates work with
> > > > > > > wildcards.
> > > > > > >
> > > > > > > I presume the following schema is correct..
> > > > > > >
> > > > > > > <xs:element name="billTo">
> > > > > > > <xs:complexType>
> > > > > > > <xs:sequence>
> > > > > > > <xs:element name="name" type="xs:string"/>
> > > > > > > <xs:element name="address" type="xs:string"/>
> > > > > > > <xs:element name="zip" type="xs:integer"/>
> > > > > > > <!-- extension. one can put anything here -->
> > > > > > > <xs:any namespace="#all" processContents="skip" />
> > > > > > > </xs:sequence>
> > > > > > > </xs:complexType>
> > > > > > > </xs:element>
> > > > > > >
> > > > > > > now, consider the tree (impractical, but still..)
> > > > > > >
> > > > > > > <billTo>
> > > > > > > <name>ABC</name>
> > > > > > > <address>California</address>
> > > > > > > <zip>90095</zip>
> > > > > > > <zip>90024</zip>
> > > > > > > </billTo>
> > > > > > >
> > > > > > > Now consider an update (delete the first zip element) --
> > > > > > >
> > > > > > > <billTo>
> > > > > > > <name>ABC</name>
> > > > > > > <address>California</address>
> > > > > > > <zip>90024</zip>
> > > > > > > </billTo>
> > > > > > >
> > > > > > > Now, I hope both the documents are valid w.r.to the
> > schema??
> > > > > > > -- also, will the type assignment for
> > <zip>90024</zip> change
> > > > > > > during the update??
> > > > > >
> > > > > > Yes. In the first instance <zip>90024</zip> will be
> > matched by
> > > > > > the wildcard and therefore will have the type xs:anyType (I
> > > > > think). In the
> > > > > > second instance <zip>90024</zip> will be matched by the zip
> > > > > > element declaration and hence have the type xs:integer.
> > > > > >
> > > > > > Cheers,
> > > > > > /Eddie
> > > > > >
> > > > > > > cheers and regards - murali.
|
