[
Lists Home |
Date Index |
Thread Index
]
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?
--
PITHY WORDS OF WISDOM
To err is human, but to really foul things up requires a computer.
This posting is provided "AS IS" with no warranties, and confers no
rights.
> -----Original Message-----
> From: Murali Mani [mailto:mani@CS.UCLA.EDU]
> Sent: Sunday, June 02, 2002 2:45 PM
> To: Dare Obasanjo
> Cc: Eddie Robertsson; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Question regarding PSVI..
>
>
>
> actually, can someone comment on this? I am quite interested
> in knowing your opinions, as to whether this was unexpected,
> but what we have to live with..??
>
> thanks and regards - murali.
>
> > 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 Thu, 30 May 2002, Dare Obasanjo wrote:
> >
> > > A.) I'm don't think this was one of the design goals of W3C XML
> > > Schema.
> > >
> > > B.) I am not sure the W3C XML Schema Working Group specifically
> > > considered editting/modification scenarios when designing W3C XML
> > > Schema. But even if they had, the fact of the matter is
> that almost
> > > 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.
> > >
> > > > -----Original Message-----
> > > > From: Murali Mani [mailto:mani@CS.UCLA.EDU]
> > > >
> > > > isn't one of the goals of XML Schema to try to avoid
> this -- that
> > > > is -- once an element is assigned a type, try not to change the
> > > > type assignment for it???
> > > >
> > > > so will this be considered as a separate case by XML editors??
> > > >
> > > > thanks 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.
> > > > > >
> > > > > > On Wed, 29 May 2002, Dare Obasanjo wrote:
> > > > > >
> > > > > > > > Anyways, my question is -- where will the type names
> > > > and element
> > > > > > > > declarations associated with an element information
> > > > item in PSVI
> > > > > > > > be used?
> > > > > > >
> > > > > > > I've seen user scenarios where both are needed.
> > > > > > >
> > > > > > > 1.) The type names for element declarations are
> useful for
> > > > > > > type based queries like those that will exist in Xpath 2.0
> > > > and XQuery.
> > > > > > >
> > > > > > > EXAMPLE: /myco:company-roster/myco:employee[. instance
> > > > of element
> > > > > > > of type myco:managerType]
> > > > > > >
> > > > > > > where myco:managerType is a complexType defined in the
> > > > > > > schema.
> > > > > > >
> > > > > > > 2.) Currently MSXML ships with the ability to obtain the
> > > > > > > Schema Object Model (SOM) object that represents
> an element
> > > > > > > or
> > > > attribute
> > > > > > > declaration from a DOM instance. Our users love it and we
> > > > > > > are inundiated with requests to provide similar
> > > > functionality for the
> > > > > > > .NET frameworks version of the DOM. One user scenario
> > > > > > > involved creating a schema-aware XML text editor
> and using
> > > > > > > the element decls for the particular element
> being edited to
> > > > determine whether
> > > > > > > the edits were valid or not which was way more performant
> > > > > > > than validating on each edit.
> > > > > >
> > > > > >
> --------------------------------------------------------------
> > > > > > ---
> > > > > > The xml-dev list is sponsored by XML.org
<http://www.xml.org>, an
> > > > > initiative of OASIS <http://www.oasis-open.org>
> > > > >
> > > > > The list archives are at
> > > > > http://lists.xml.org/archives/xml-dev/
> > > > >
> > > > > To subscribe or unsubscribe from this list use the
> > > > > subscription
> > > > > manager: <http://lists.xml.org/ob/adm.pl>
> > > >
> > >
> > >
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://lists.xml.org/ob/adm.pl>
> >
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
