xmldb-org-xupdate Mailing List for XML:DB Initiative for XML Databases
Brought to you by:
reinhapa
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
(5) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(18) |
May
(5) |
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Kasimier B. <kbu...@4c...> - 2005-08-23 19:47:11
|
Hi, On Fri, 2005-08-19 at 16:05 +0100, Isidro Vila Verde wrote: > Well, > > In the same document, but in section where the choice is defined > (http://www.w3.org/TR/xmlschema-1/#element-choice) say that: > > <choice > id = ID > maxOccurs = (nonNegativeInteger | unbounded) : 1 > minOccurs = nonNegativeInteger : 1 > {any attributes with non-schema namespace . . .}> > Content: (annotation?, (element | group | choice | sequence | any)*) > </choice> Yes, this is quite misleading; and I was misled by it as well, until someone pointed out that even the schema for schemas was not reflecting the fact that the occurences are not allowed on the model group child of model group definitions. At that time the schema for schemas was changed. Have a look at the model group definition itself, which makes things much clearer: http://www.w3.org/TR/xmlschema-1/#declare-namedModelGroup There we have: "Also note that in the first (named) case above no reference is made to minOccurs or maxOccurs: this is because the schema for schemas does not allow them on the child of <group> when it is named. This in turn is because the {min occurs} and {max occurs} of the particles which refer to the definition are what count." > And in http://xmlsoft.org/index.html we have this warning: > > "A partial implementation of XML Schemas Part 1: Structure is being worked > on but it would be far too early to make any conformance statement about it > at the moment". ;-) So you assume any schema to be valid if Libxml2 reports it as invalid? We are very careful with conformance statements. In fact, Libxml2's schema processor is beyond the level this statement might communicate. > But I must admit I don't check the Schema of Schemas. > > Thank you for your alert. Regards, Kasimier |
From: Isidro V. V. <jv...@gm...> - 2005-08-19 15:01:00
|
Well, In the same document, but in section where the choice is defined (http://www.w3.org/TR/xmlschema-1/#element-choice) say that: <choice id = ID maxOccurs = (nonNegativeInteger | unbounded) : 1 minOccurs = nonNegativeInteger : 1 {any attributes with non-schema namespace . . .}> Content: (annotation?, (element | group | choice | sequence | any)*) </choice> And in http://xmlsoft.org/index.html we have this warning: "A partial implementation of XML Schemas Part 1: Structure is being worked on but it would be far too early to make any conformance statement about it at the moment". But I must admit I don't check the Schema of Schemas. Thank you for your alert. Isidro > -----Mensagem original----- > De: Kasimier Buchcik [mailto:kbu...@4c...] > Enviada: sexta-feira, 19 de Agosto de 2005 15:03 > Para: ML-xmldb-xupdate > Cc: Isidro Vila Verde > Assunto: Re: [Xmldb-org-xupdate] Re: Xupdate XSD > > Hi, > > On Fri, 2005-08-19 at 14:48 +0100, Isidro Vila Verde wrote: > > Hi Kasimier, > > > > It seems that Libmxl2 don't have full support for XML Schema, but I > change > > the XSD a little bit to workaround with this Libxml2 limitation. > > This is not a limitation of Libxml2, but simply ruled out by the schema > for schemas. Check out > http://www.w3.org/TR/xmlschema-1/#normative-schemaSchema > where we have > <xs:complexType name="namedGroup"> > which reflects the model group definition and contains > <xs:complexType name="simpleExplicitGroup"> > which prohibits occurences > <xs:attribute name="minOccurs" use="prohibited"/> > <xs:attribute name="maxOccurs" use="prohibited"/> > > The reason for ruling them out is that only the occurences of > the model group definition _reference_ are used. More technically > speaking, the particle which will correspond to the model group > definition reference will point to the model group child of > a model group definition. > Actually the following construct: > > <group name="foo"> > <choice ...> > </choice> > </group> > > does not produce any particles (particles hold the occurence > information) at the component level. So there is just no component > to store any occurence information for the above mentioned <choice>. > If schema processors don't bark, then they probably don't catch > this constraint and leave you unaware that your occurences were > just skipped. > > By the way, what schema processor did you use ? > > Regards, > > Kasimier > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 18-08-2005 > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 18-08-2005 |
From: Kasimier B. <kbu...@4c...> - 2005-08-19 14:07:42
|
Hi, On Fri, 2005-08-19 at 14:48 +0100, Isidro Vila Verde wrote: > Hi Kasimier, > > It seems that Libmxl2 don't have full support for XML Schema, but I change > the XSD a little bit to workaround with this Libxml2 limitation. This is not a limitation of Libxml2, but simply ruled out by the schema for schemas. Check out http://www.w3.org/TR/xmlschema-1/#normative-schemaSchema where we have <xs:complexType name="namedGroup"> which reflects the model group definition and contains <xs:complexType name="simpleExplicitGroup"> which prohibits occurences <xs:attribute name="minOccurs" use="prohibited"/> <xs:attribute name="maxOccurs" use="prohibited"/> The reason for ruling them out is that only the occurences of the model group definition _reference_ are used. More technically speaking, the particle which will correspond to the model group definition reference will point to the model group child of a model group definition. Actually the following construct: <group name="foo"> <choice ...> </choice> </group> does not produce any particles (particles hold the occurence information) at the component level. So there is just no component to store any occurence information for the above mentioned <choice>. If schema processors don't bark, then they probably don't catch this constraint and leave you unaware that your occurences were just skipped. By the way, what schema processor did you use ? Regards, Kasimier |
From: Isidro V. V. <jv...@se...> - 2005-08-19 13:43:58
|
Hi Kasimier, It seems that Libmxl2 don't have full support for XML Schema, but I = change the XSD a little bit to workaround with this Libxml2 limitation. The second version is here: ----------------------- <?xml version=3D"1.0" encoding=3D"UTF-8"?> <xs:schema targetNamespace=3D"http://www.xmldb.org/xupdate" xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" xmlns:xupdate=3D"http://www.xmldb.org/xupdate" = elementFormDefault=3D"qualified" attributeFormDefault=3D"unqualified"> <xs:annotation> <xs:appinfo>xsd4xupdate</xs:appinfo> <xs:documentation>A XSD for Xupdate</xs:documentation> </xs:annotation> <xs:group name=3D"modifications"> <xs:choice> <xs:element ref=3D"xupdate:insert-before"/> <xs:element ref=3D"xupdate:insert-after"/> <xs:element ref=3D"xupdate:append"/> <xs:element ref=3D"xupdate:update"/> <xs:element ref=3D"xupdate:remove"/> <xs:element ref=3D"xupdate:rename"/> <xs:element ref=3D"xupdate:variable"/> <xs:element ref=3D"xupdate:value-of"/> <xs:element ref=3D"xupdate:if"/> </xs:choice> </xs:group> <xs:element name=3D"modifications"> <xs:complexType> <xs:sequence> <xs:group ref=3D"xupdate:modifications" minOccurs=3D"0" maxOccurs=3D"unbounded"/> </xs:sequence> <xs:attribute name=3D"id" type=3D"xs:ID" use=3D"optional"/> <xs:attribute name=3D"version" type=3D"xs:NMTOKEN" use=3D"required" fixed=3D"1.0"/> </xs:complexType> </xs:element> <xs:group name=3D"instructions"> <xs:choice> <xs:element ref=3D"xupdate:element"/> <xs:element ref=3D"xupdate:attribute"/> <xs:element ref=3D"xupdate:text"/> <xs:element ref=3D"xupdate:processing-instruction"/> <xs:element ref=3D"xupdate:comment"/> <xs:element ref=3D"xupdate:value-of"/> <xs:element ref=3D"xupdate:if"/> <xs:element ref=3D"xupdate:variable"/> <xs:element ref=3D"xupdate:cdata"/> </xs:choice> </xs:group> <xs:element name=3D"insert-before"> <xs:complexType> <xs:group ref=3D"xupdate:instructions" maxOccurs=3D"unbounded"/> <xs:attribute name=3D"select" type=3D"xs:string" use=3D"required"/> </xs:complexType> </xs:element> <xs:element name=3D"insert-after"> <xs:complexType> <xs:group ref=3D"xupdate:instructions"/> <xs:attribute name=3D"select" type=3D"xs:string" use=3D"required"/> </xs:complexType> </xs:element> <xs:element name=3D"append"> <xs:complexType> <xs:group ref=3D"xupdate:instructions"/> <xs:attribute name=3D"select" type=3D"xs:string" use=3D"required"/> <xs:attribute name=3D"child" type=3D"xs:string" use=3D"optional"/> </xs:complexType> </xs:element> <xs:element name=3D"update"> <xs:complexType mixed=3D"true"> <xs:sequence> <xs:any namespace=3D"##other" processContents=3D"lax" minOccurs=3D"0" maxOccurs=3D"unbounded"/> </xs:sequence> <xs:attribute name=3D"select" type=3D"xs:string" use=3D"required"/> </xs:complexType> </xs:element> <xs:element name=3D"remove"> <xs:complexType> <xs:attribute name=3D"select" type=3D"xs:string" use=3D"required"/> </xs:complexType> </xs:element> <xs:element name=3D"rename"> <xs:complexType> <xs:simpleContent> <xs:extension base=3D"xs:NMTOKEN"> <xs:attribute name=3D"select" type=3D"xs:string" use=3D"required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name=3D"variable"> <xs:complexType> <xs:simpleContent> <xs:extension base=3D"xs:string"> <xs:attribute name=3D"name" type=3D"xs:NMTOKEN" use=3D"required"/> <xs:attribute name=3D"select" type=3D"xs:string" use=3D"optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name=3D"value-of"> <xs:complexType> <xs:attribute name=3D"select" type=3D"xs:string" use=3D"required"/> </xs:complexType> </xs:element> <xs:element name=3D"if"> <xs:complexType mixed=3D"true"> <xs:group ref=3D"xupdate:instructions"/> <xs:attribute name=3D"test" type=3D"xs:string" use=3D"required"/> </xs:complexType> </xs:element> <!-- - --> <xs:element name=3D"element"> <xs:complexType mixed=3D"true"> <xs:sequence> <xs:group ref=3D"xupdate:instructions" minOccurs=3D"0"/> <xs:any namespace=3D"##other" processContents=3D"lax" minOccurs=3D"0" maxOccurs=3D"unbounded"/> </xs:sequence> <xs:attribute name=3D"name" type=3D"xs:NMTOKEN" use=3D"required"/> <xs:attribute name=3D"namespace" type=3D"xs:QName" use=3D"optional"/> </xs:complexType> </xs:element> <xs:element name=3D"attribute"> <xs:complexType> <xs:simpleContent> <xs:extension base=3D"xs:string"> <xs:attribute name=3D"name" type=3D"xs:NMTOKEN" use=3D"required"/> <xs:attribute name=3D"namespace" type=3D"xs:string" use=3D"optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name=3D"text" type=3D"xs:string"/> <xs:element name=3D"comment" type=3D"xs:string"/> <xs:element name=3D"processing-instruction"> <xs:complexType> <xs:simpleContent> <xs:extension base=3D"xs:string"> <xs:attribute name=3D"name" type=3D"xs:NMTOKEN" use=3D"required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name=3D"cdata" type=3D"xs:string"/> </xs:schema> ----------------------- From: Kasimier Buchcik <kbuchcik@4c...> Re: Xupdate XSD =A0=20 2005-08-17 02:17=20 Hi, =20 (this is a handmade reply to the mail from Lars Martin, since I just subscribed) =20 Occurences must not be specified on the model group child of model group definitions. =20 With Libxml2 I get: =20 xmllint --noout --schema XUpdate.xsd xudummy.xml =20 XUpdate.xsd:44: element choice: Schemas parser error : Element "{http://www.w3.org/2001/XMLSchema}choice": The attribute "minOccurs" is not allowed. XUpdate.xsd:44: element choice: Schemas parser error : Element "{http://www.w3.org/2001/XMLSchema}choice": The attribute "maxOccurs" is not allowed. WXS schema XUpdate.xsd failed to compile =20 The occurences need to be moved to each of the model group references. =20 Regards, =20 Kasimier Isidro Vila Verde email: jv...@se...=20 web: http://serprest.pt/ ------------------------------------------ Este e-mail pode conter informa=E7=E3o confidencial e/ou privilegiada. = Se n=E3o for o destinat=E1rio pretendido (ou receber este e-mail por erro), = apague de imediato esta mensagem e por gentileza notifique o remetente. Toda a c=F3pia, divulga=E7=E3o ou distribui=E7=E3o n=E3o autorizada do = material deste e-mail =E9 estritamente proibida. ------------------------------------------ This e-mail may contain confidential and/or privileged information. If = you are not the intended recipient (or have received this e-mail in error) destroy this e-mail immediately and please notify the sender. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ------------------------------------------ --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: = 18-08-2005 =20 |
From: Isidro V. V. <jv...@gm...> - 2005-08-17 16:57:04
|
> -----Mensagem original----- > De: Per Nyfelt [mailto:per...@us...] > Enviada: sexta-feira, 12 de Agosto de 2005 21:02 > Para: xml...@li...; jv...@gm... > Cc: Lars Martin > Assunto: Re: [Xmldb-org-xupdate] Fwd: Xupdate XSD >=20 > Hi Isidro, [Isidro Vila Verde]=20 [Isidro Vila Verde]=20 Hi Per, Thank you for your answer >=20 > Thank you very much your contribution of the schema! >=20 > The XML:DB Xupdate project is in great need of voluteers. Please, if = you > have > time, join the xupdate mailing list and participate in the future > development > of xupdate! [Isidro Vila Verde]=20 [Isidro Vila Verde]=20 Well I already try to join but the site http://www.xmldb.org seems to be hacked. At least every link point to searchportal.information.com So I don't know how to subscribe the list. Can you put me in? =20 >=20 > Lets add the schema to the Xupdate documentation and publish it on the > homepage at http://xmldb-org.sourceforge.net/xupdate. I would prefer = that > we > keep official Xupdate resources there on one place. [Isidro Vila Verde]=20 It's ok for me. It's Fine. >=20 > I assume you've checked it agains the DTD for correctness? [Isidro Vila Verde]=20 [Isidro Vila Verde]=20 Well, I checked but with some assumption I had made, from the examples, because the DTD = (http://xmldb-org.sourceforge.net/xupdate/xupdate-wd.html) don't seem to be completed.=20 I am not sure about the correctiveness of xsd because some uses cases = are not valid against referred dtd. But as long I understand the present version could be ok for the uses = cases (I see in http://www.xmldatabases.org/projects/XUpdate-UseCases/ a new markup xupdate:cdata but as isn't mentioned in the draft I don't include = it in the XML schema). Best Regards Isidro >=20 > Best regards, > Per >=20 > Friday 12 August 2005 10.10 skrev Lars Martin: > > -----Urspr=FCngliche Nachricht----- > > Von: Isidro Vila Verde <jv...@gm...> > > Gesendet am: 11. Aug 2005, 19:58:47 > > > > > Dears, > > > > > > > > > > > > After unsuccessful search in the google for a XSD for xupdate, I > decide > > > to write this one. I am sending this to you and ask if it = correctly > > > define the Xupdate. > > > > > > I so I would like, with your permission of course, put it online. > > > > > > > > > > > > Meanwhile, what is the status of Xupdate. I see some products = (exist > for > > > example) support it but I don=92t see any movement on it. > > > > > > > > > > > > Regards > > > > > > > > > > > > Isidro > > > > > > > > > > > > > > > > > > = ---------------------------------------------------------------------- > --- > > >--- > > > = ---------------------------------------------------------------------- > --- > > >--- -------------------------------------------------- > > > > > > > > > > > > <?xml version=3D"1.0" encoding=3D"UTF-8"?> > > > > > > <xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > > > elementFormDefault=3D"qualified" = attributeFormDefault=3D"unqualified" > > > targetNamespace=3D"http://www.xmldb.org/xupdate" > > > xmlns:xupdate=3D"http://www.xmldb.org/xupdate"> > > > > > > <xs:element name=3D"modifications"> > > > > > > <xs:complexType> > > > > > > <xs:choice minOccurs=3D"1" maxOccurs=3D"unbounded"> > > > > > > <xs:element ref=3D"xupdate:insert-before"/> > > > > > > <xs:element ref=3D"xupdate:insert-after"/> > > > > > > <xs:element ref=3D"xupdate:append"/> > > > > > > <xs:element ref=3D"xupdate:update"/> > > > > > > <xs:element ref=3D"xupdate:remove"/> > > > > > > <xs:element ref=3D"xupdate:rename"/> > > > > > > <xs:element ref=3D"xupdate:variable"/> > > > > > > <xs:element ref=3D"xupdate:value-of"/> > > > > > > <xs:element ref=3D"xupdate:if"/> > > > > > > </xs:choice> > > > > > > <xs:attribute name=3D"id" type=3D"xs:ID" = use=3D"optional"/> > > > > > > <xs:attribute name=3D"version" type=3D"xs:NMTOKEN" > use=3D"required" > > > fixed=3D"1.0"/> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:group name=3D"instructions"> > > > > > > <xs:choice minOccurs=3D"1" maxOccurs=3D"unbounded"> > > > > > > <xs:element ref=3D"xupdate:element"/> > > > > > > <xs:element ref=3D"xupdate:attribute"/> > > > > > > <xs:element ref=3D"xupdate:text"/> > > > > > > <xs:element ref=3D"xupdate:processing-instruction"/> > > > > > > <xs:element ref=3D"xupdate:comment"/> > > > > > > </xs:choice> > > > > > > </xs:group> > > > > > > <xs:element name=3D"insert-before"> > > > > > > <xs:complexType> > > > > > > <xs:group ref=3D"xupdate:instructions"/> > > > > > > <xs:attribute name=3D"select" type=3D"xs:string" > use=3D"required"/> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"insert-after"> > > > > > > <xs:complexType> > > > > > > <xs:group ref=3D"xupdate:instructions"/> > > > > > > <xs:attribute name=3D"select" type=3D"xs:string" > use=3D"required"/> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"append"> > > > > > > <xs:complexType> > > > > > > <xs:group ref=3D"xupdate:instructions"/> > > > > > > <xs:attribute name=3D"select" type=3D"xs:string" > use=3D"required"/> > > > > > > <xs:attribute name=3D"child" type=3D"xs:string" > use=3D"optional"/> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"update"> > > > > > > <xs:complexType mixed=3D"true"> > > > > > > <xs:sequence> > > > > > > <xs:any namespace=3D"##other" = processContents=3D"lax" > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > </xs:sequence> > > > > > > <xs:attribute name=3D"select" type=3D"xs:string" > use=3D"required"/> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"remove"> > > > > > > <xs:complexType> > > > > > > <xs:attribute name=3D"select" type=3D"xs:string" > use=3D"required"/> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"rename"> > > > > > > <xs:complexType> > > > > > > <xs:simpleContent> > > > > > > <xs:extension base=3D"xs:NMTOKEN"> > > > > > > <xs:attribute name=3D"select" = type=3D"xs:string" > > > use=3D"required"/> > > > > > > </xs:extension> > > > > > > </xs:simpleContent> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"variable"> > > > > > > <xs:complexType> > > > > > > <xs:simpleContent> > > > > > > <xs:extension base=3D"xs:string"> > > > > > > <xs:attribute name=3D"name" = type=3D"xs:NMTOKEN" > > > use=3D"required"/> > > > > > > <xs:attribute name=3D"select" = type=3D"xs:string" > > > use=3D"optional"/> > > > > > > </xs:extension> > > > > > > </xs:simpleContent> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"value-of"> > > > > > > <xs:complexType> > > > > > > <xs:attribute name=3D"select" type=3D"xs:string" > use=3D"required"/> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"if"> > > > > > > <xs:complexType mixed=3D"true"> > > > > > > <xs:group ref=3D"xupdate:instructions"/> > > > > > > <xs:attribute name=3D"test" type=3D"xs:string" > use=3D"required"/> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <!-- - --> > > > > > > <xs:element name=3D"element"> > > > > > > <xs:complexType mixed=3D"true"> > > > > > > <xs:sequence> > > > > > > <xs:group ref=3D"xupdate:instructions" = minOccurs=3D"0"/> > > > > > > <xs:any namespace=3D"##other" = processContents=3D"lax" > > > minOccurs=3D"0" maxOccurs=3D"unbounded"/> > > > > > > </xs:sequence> > > > > > > <xs:attribute name=3D"name" type=3D"xs:NMTOKEN" > use=3D"required"/> > > > > > > <xs:attribute name=3D"namespace" type=3D"xs:string" > > > use=3D"optional"/> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"attribute"> > > > > > > <xs:complexType> > > > > > > <xs:simpleContent> > > > > > > <xs:extension base=3D"xs:string"> > > > > > > <xs:attribute name=3D"name" = type=3D"xs:NMTOKEN" > > > use=3D"required"/> > > > > > > <xs:attribute name=3D"namespace" = type=3D"xs:string" > > > use=3D"optional"/> > > > > > > </xs:extension> > > > > > > </xs:simpleContent> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > <xs:element name=3D"text" type=3D"xs:string"/> > > > > > > <xs:element name=3D"comment" type=3D"xs:string"/> > > > > > > <xs:element name=3D"processing-instruction"> > > > > > > <xs:complexType> > > > > > > <xs:simpleContent> > > > > > > <xs:extension base=3D"xs:string"> > > > > > > <xs:attribute name=3D"name" = type=3D"xs:NMTOKEN" > > > use=3D"required"/> > > > > > > </xs:extension> > > > > > > </xs:simpleContent> > > > > > > </xs:complexType> > > > > > > </xs:element> > > > > > > </xs:schema> > > > > > > > > > > > > = ---------------------------------------------------------------------- > --- > > >--- > > > = ---------------------------------------------------------------------- > --- > > >--- -------------------------------------------------- > > > > > > > > > > > > Isidro Vila Verde > > > email: HYPERLINK "mailto:jv...@se...web"jv...@se... > > > web: HYPERLINK "http://serprest.pt/"http://serprest.pt/ > > > ------------------------------------------ > > > Este e-mail pode conter informa=E7=E3o confidencial e/ou = privilegiada. Se > n=E3o > > > for o destinat=E1rio pretendido (ou receber este e-mail por erro), > apague > > > de imediato esta mensagem e por gentileza notifique o remetente. > > > > > > Toda a c=F3pia, divulga=E7=E3o ou distribui=E7=E3o n=E3o = autorizada do material > deste > > > e-mail =E9 estritamente proibida. > > > ------------------------------------------ > > > This e-mail may contain confidential and/or privileged = information. If > > > you are not the intended recipient (or have received this e-mail = in > > > error) destroy this e-mail immediately and please notify the = sender. > Any > > > unauthorized copying, disclosure or distribution of the material = in > this > > > e-mail is strictly forbidden. > > > ------------------------------------------ > > > > > > > > > > > > > > > -- > > > No virus found in this outgoing message. > > > Checked by AVG Anti-Virus. > > > Version: 7.0.338 / Virus Database: 267.10.6/69 - Release Date: = 11-08- > 2005 > > > > = ______________________________________________________________________ > > Lars Martin = mailto:Lar...@sm... > > SMB GmbH = http://www.smb-tec.com > > D-04347 Leipzig Rohrteichstrasse = 18 > > Tel: +49-(0)341-699 46 04 Fax: +49-(0)341-699 47 = 04 > > Produkt-Manager Business Server BS1 Produkt-Manager = CADDA.NET > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * = Testing & > QA > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Xmldb-org-xupdate mailing list > > Xml...@li... > > https://lists.sourceforge.net/lists/listinfo/xmldb-org-xupdate >=20 > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.338 / Virus Database: 267.10.11/74 - Release Date: = 17-08-2005 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.11/74 - Release Date: = 17-08-2005 =20 |
From: Kasimier B. <kbu...@4c...> - 2005-08-17 09:17:38
|
Hi, (this is a handmade reply to the mail from Lars Martin, since I just subscribed) Occurences must not be specified on the model group child of model group definitions. With Libxml2 I get: xmllint --noout --schema XUpdate.xsd xudummy.xml XUpdate.xsd:44: element choice: Schemas parser error : Element '{http://www.w3.org/2001/XMLSchema}choice': The attribute 'minOccurs' is not allowed. XUpdate.xsd:44: element choice: Schemas parser error : Element '{http://www.w3.org/2001/XMLSchema}choice': The attribute 'maxOccurs' is not allowed. WXS schema XUpdate.xsd failed to compile The occurences need to be moved to each of the model group references. Regards, Kasimier |
From: Per N. <per...@us...> - 2005-08-13 09:22:08
|
Update of /cvsroot/xmldb-org/xupdate In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28536/xupdate Modified Files: index.xml Log Message: Fixed download location Index: index.xml =================================================================== RCS file: /cvsroot/xmldb-org/xupdate/index.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- index.xml 30 May 2004 11:57:42 -0000 1.1 +++ index.xml 13 Aug 2005 09:21:52 -0000 1.2 @@ -31,10 +31,10 @@ <p><strong>Downloads:</strong></p> <ul> - <li><strong>NEW:</strong> <link href="http://www.xmldb.org/xupdate/downloads/xmldb-xupdate-0.3.zip">XML:DB Lexus 0.3</link><br/> + <li><strong>NEW:</strong> <link href="http://prdownloads.sourceforge.net/xmldb-org/xmldb-xupdate-0.3.zip?download">XML:DB Lexus 0.3</link><br/> The reference implementation is available for download. </li> - <li><link href="http://www.xmldb.org/xupdate/downloads/xmldb-xupdate-0.2.2.zip">XML:DB Lexus 0.2.2</link><br/> + <li><link href="http://prdownloads.sourceforge.net/xmldb-org/xmldb-xupdate-0.2.2.zip?download">XML:DB Lexus 0.2.2</link><br/> </li> </ul> |
From: Lars M. <Lar...@sm...> - 2005-08-12 08:15:10
|
-----Ursprüngliche Nachricht----- Von: Isidro Vila Verde <jv...@gm...> Gesendet am: 11. Aug 2005, 19:58:47 > Dears, > > > > After unsuccessful search in the google for a XSD for xupdate, I decide to > write this one. I am sending this to you and ask if it correctly define the > Xupdate. > > I so I would like, with your permission of course, put it online. > > > > Meanwhile, what is the status of Xupdate. I see some products (exist for > example) support it but I dont see any movement on it. > > > > Regards > > > > Isidro > > > > > > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > -------------------------------------------------- > > > > <?xml version="1.0" encoding="UTF-8"?> > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" > elementFormDefault="qualified" attributeFormDefault="unqualified" > targetNamespace="http://www.xmldb.org/xupdate" > xmlns:xupdate="http://www.xmldb.org/xupdate"> > > <xs:element name="modifications"> > > <xs:complexType> > > <xs:choice minOccurs="1" maxOccurs="unbounded"> > > <xs:element ref="xupdate:insert-before"/> > > <xs:element ref="xupdate:insert-after"/> > > <xs:element ref="xupdate:append"/> > > <xs:element ref="xupdate:update"/> > > <xs:element ref="xupdate:remove"/> > > <xs:element ref="xupdate:rename"/> > > <xs:element ref="xupdate:variable"/> > > <xs:element ref="xupdate:value-of"/> > > <xs:element ref="xupdate:if"/> > > </xs:choice> > > <xs:attribute name="id" type="xs:ID" use="optional"/> > > <xs:attribute name="version" type="xs:NMTOKEN" use="required" > fixed="1.0"/> > > </xs:complexType> > > </xs:element> > > <xs:group name="instructions"> > > <xs:choice minOccurs="1" maxOccurs="unbounded"> > > <xs:element ref="xupdate:element"/> > > <xs:element ref="xupdate:attribute"/> > > <xs:element ref="xupdate:text"/> > > <xs:element ref="xupdate:processing-instruction"/> > > <xs:element ref="xupdate:comment"/> > > </xs:choice> > > </xs:group> > > <xs:element name="insert-before"> > > <xs:complexType> > > <xs:group ref="xupdate:instructions"/> > > <xs:attribute name="select" type="xs:string" use="required"/> > > </xs:complexType> > > </xs:element> > > <xs:element name="insert-after"> > > <xs:complexType> > > <xs:group ref="xupdate:instructions"/> > > <xs:attribute name="select" type="xs:string" use="required"/> > > </xs:complexType> > > </xs:element> > > <xs:element name="append"> > > <xs:complexType> > > <xs:group ref="xupdate:instructions"/> > > <xs:attribute name="select" type="xs:string" use="required"/> > > <xs:attribute name="child" type="xs:string" use="optional"/> > > </xs:complexType> > > </xs:element> > > <xs:element name="update"> > > <xs:complexType mixed="true"> > > <xs:sequence> > > <xs:any namespace="##other" processContents="lax" > minOccurs="0" maxOccurs="unbounded"/> > > </xs:sequence> > > <xs:attribute name="select" type="xs:string" use="required"/> > > </xs:complexType> > > </xs:element> > > <xs:element name="remove"> > > <xs:complexType> > > <xs:attribute name="select" type="xs:string" use="required"/> > > </xs:complexType> > > </xs:element> > > <xs:element name="rename"> > > <xs:complexType> > > <xs:simpleContent> > > <xs:extension base="xs:NMTOKEN"> > > <xs:attribute name="select" type="xs:string" > use="required"/> > > </xs:extension> > > </xs:simpleContent> > > </xs:complexType> > > </xs:element> > > <xs:element name="variable"> > > <xs:complexType> > > <xs:simpleContent> > > <xs:extension base="xs:string"> > > <xs:attribute name="name" type="xs:NMTOKEN" > use="required"/> > > <xs:attribute name="select" type="xs:string" > use="optional"/> > > </xs:extension> > > </xs:simpleContent> > > </xs:complexType> > > </xs:element> > > <xs:element name="value-of"> > > <xs:complexType> > > <xs:attribute name="select" type="xs:string" use="required"/> > > </xs:complexType> > > </xs:element> > > <xs:element name="if"> > > <xs:complexType mixed="true"> > > <xs:group ref="xupdate:instructions"/> > > <xs:attribute name="test" type="xs:string" use="required"/> > > </xs:complexType> > > </xs:element> > > <!-- - --> > > <xs:element name="element"> > > <xs:complexType mixed="true"> > > <xs:sequence> > > <xs:group ref="xupdate:instructions" minOccurs="0"/> > > <xs:any namespace="##other" processContents="lax" > minOccurs="0" maxOccurs="unbounded"/> > > </xs:sequence> > > <xs:attribute name="name" type="xs:NMTOKEN" use="required"/> > > <xs:attribute name="namespace" type="xs:string" use="optional"/> > > </xs:complexType> > > </xs:element> > > <xs:element name="attribute"> > > <xs:complexType> > > <xs:simpleContent> > > <xs:extension base="xs:string"> > > <xs:attribute name="name" type="xs:NMTOKEN" > use="required"/> > > <xs:attribute name="namespace" type="xs:string" > use="optional"/> > > </xs:extension> > > </xs:simpleContent> > > </xs:complexType> > > </xs:element> > > <xs:element name="text" type="xs:string"/> > > <xs:element name="comment" type="xs:string"/> > > <xs:element name="processing-instruction"> > > <xs:complexType> > > <xs:simpleContent> > > <xs:extension base="xs:string"> > > <xs:attribute name="name" type="xs:NMTOKEN" > use="required"/> > > </xs:extension> > > </xs:simpleContent> > > </xs:complexType> > > </xs:element> > > </xs:schema> > > > > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > -------------------------------------------------- > > > > Isidro Vila Verde > email: HYPERLINK "mailto:jv...@se...web"jv...@se... > web: HYPERLINK "http://serprest.pt/"http://serprest.pt/ > ------------------------------------------ > Este e-mail pode conter informação confidencial e/ou privilegiada. Se não > for o destinatário pretendido (ou receber este e-mail por erro), apague de > imediato esta mensagem e por gentileza notifique o remetente. > > Toda a cópia, divulgação ou distribuição não autorizada do material deste > e-mail é estritamente proibida. > ------------------------------------------ > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in > error) destroy this e-mail immediately and please notify the sender. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > ------------------------------------------ > > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.338 / Virus Database: 267.10.6/69 - Release Date: 11-08-2005 > > ______________________________________________________________________ Lars Martin mailto:Lar...@sm... SMB GmbH http://www.smb-tec.com D-04347 Leipzig Rohrteichstrasse 18 Tel: +49-(0)341-699 46 04 Fax: +49-(0)341-699 47 04 Produkt-Manager Business Server BS1 Produkt-Manager CADDA.NET |
From: John L. C. <jl...@po...> - 2005-05-25 05:59:24
|
On Wed, May 11, 2005 at 04:42:43PM -0700, Ronald Bourret wrote: > John L. Clark wrote: > >I would prefer that the latter be made normative (that is, that > >update be treated precisely as node replacement, hence my original > >argument about the assignment operator semantics). >=20 > I prefer content replacement to node replacement. Node replacement would= =20 > mean that if I selected the node <date>10/11/12</date>, I would have to= =20 > include the <date> markup in my update instruction, which feels=20 > unnatural when all I want to do is change the date. The content of an element is a node[0]. If all you want to do is change the date, then you want to change the date element's content node, not the date node itself. More precisely, the node you want to change is represented by the XPath expression /date/text(), which more precisely expresses the target of the replacement (that is, the text, *not* the whole element). I think this is why it feels unnatural; if you want to change the whole element, then you should both address that element precisely and include the new element in the update content. This example is akin to my modification of the example from the specification: --- <xupdate:update select=3D"/addresses/address[2]/town/text()[1]" xmlns:xupdate=3D"http://www.xmldb.org/xupdate">New York</xupdate:update> --- Which selects the first text node within the town element and chooses to update *that*. In your example, you don't want to update the whole element, just the text child of that element (informally, that element's content), and so I think that you should be required to address the node that you want to update precisely. > This also shows why it would be useful to have an xupdate:replace=20 > element as Wolfgang suggests. This would allow me to replace the <date>= =20 > element with <birthday>, for example. To my mind, this is very distinct= =20 > from changing a value. As detailed above, I disagree. You can use the current xupdate:update to satisfy both of these use cases with an appropriate XPath expression. Take care, John L. Clark [0] http://www.w3.org/TR/xpath.html#data-model |
From: Ronald B. <rpb...@rp...> - 2005-05-11 23:42:39
|
John L. Clark wrote: > Well, the spec says that the update operation "can be used to update the > content of existing nodes". From the example given, I took this to mean > that the subtree underneath the selected node was replaced with the > update operation's content. This is why I thought that the replacing > content could be any valid XML content. If a text node is explicitly > selected, though, it does not have any subtree to update. > > To be explicit, if your example above were allowed, then following the > example in the spec, both of: > > --- > <xupdate:update select="/addresses/address[2]/town" > xmlns:xupdate="http://www.xmldb.org/xupdate">New York</xupdate:update> > --- > > and > > --- > <xupdate:update select="/addresses/address[2]/town/text()[1]" > xmlns:xupdate="http://www.xmldb.org/xupdate">New York</xupdate:update> > --- > > could be used for the same update. However, they explicitly select > different nodes for which to "update the content", which I believe is > fundamentally broken. I would argue for one way or the other, but not > both. I would prefer that the latter be made normative (that is, that > update be treated precisely as node replacement, hence my original > argument about the assignment operator semantics). I prefer content replacement to node replacement. Node replacement would mean that if I selected the node <date>10/11/12</date>, I would have to include the <date> markup in my update instruction, which feels unnatural when all I want to do is change the date. This also shows why it would be useful to have an xupdate:replace element as Wolfgang suggests. This would allow me to replace the <date> element with <birthday>, for example. To my mind, this is very distinct from changing a value. >>3) It would be useful for update to allow element, attribute, etc. as >>content. That said, I'm not convinced it's worth the complexity, as you >>can simply delete the element and reinsert it with the new content. > > I'm not convinced that it is that complex; it seems quite natural (at > least to me), and it seems to follow suit with the other XUpdate > operators. Now that I've thought about it, I agree. -- Ron |
From: Ronald B. <rpb...@rp...> - 2005-05-11 23:34:21
|
Wolfgang Meier wrote: >> 3) It would be useful for update to allow element, attribute, etc. as >> content. That said, I'm not convinced it's worth the complexity, as >> you can simply delete the element and reinsert it with the new content. > > I would like to propose a "replace" instruction for this purpose. Maybe > I'm wrong, but to replace an element by first deleting and then > reinserting it, you need to keep track of the element's position. This > is certainly possible (using a variable, for example), but a distinct > "replace" expression would make it easier and leaves it to the XUpdate > implementation to remember the previous position. Good point. That occurred to me later as well. -- Ron |
From: Ronald B. <rpb...@rp...> - 2005-05-11 23:29:41
|
I finally had a chance to look at this. It certainly seems that both processing models are reasonable and it's easy to imagine use cases for both. Personally, I lean towards the second model as it feels more natural -- an XUpdate document is equivalent to the sequential application of its parts. That said, I can also imagine the XUpdate spec adding a processingModel attribute to xupdate:modifications with values "composite" and "sequential". Anybody know how XQuery is handling these issues? -- Ron John L. Clark wrote: > Uche's recent XUpdate update[0] (heh) has renewed my interest in this > language. I am very interested in a diff solution for XML. I had > looked at XUpdate before, but hadn't found anything that seemed > reasonable to use as a diff producing tool. This time I looked (more > closely) at xmldiff, and things seem more hopeful. There is clearly a > lot of work to do. I started hacking on that codebase, and immediately > saw some frustrating gaps and inconsistencies in the definition of > XUpdate as a language. So, let's get to work, shall we? > > This may be obvious, but it seems to me that the XUpdate working draft > could use a section on its processing model (even if that model is > mostly what one would expect). > > First, I suppose, one needs to define what is being processed. I would > say that given two XML documents A and B, an XUpdate document U > describes the difference B - A, that is, a sufficient set of operations > which, when applied to A, produce B. > > As a result, the processing model would be that given A and U, one > applies the instructions in U to the content in A to get some B. > Clearly, an XUpdate document consists of a sequence of modifications. > Is the intent that these modifications be applied in document order? If > so, do each of these modifications apply independently to A, or to an > intermediate step formed from the result of the previous modification? > > As an example of the problem, consider the following document: > > A: > --- > <example> > <a/> <b/> <b/> <a/> > </example> > --- > > and XUpdate script: > > script.xup: > --- > <xupdate:modifications xmlns:xupdate="http://www.xmldb.org/xupdate"> > <xupdate:insert-before select="/example/a[1]"> > <xupdate:element name="c"/> > </xupdate:insert-before> > > <xupdate:remove select="/example/a[1]"/> > > <xupdate:insert-before select="/example/a[1]"> > <xupdate:element name="c"/> > </xupdate:insert-before> > </xupdate:modifications> > --- > > When applying script.xup to A, would this produce: > > B1: > --- > <example> > <c/> <c/> <b/> <b/> <a/> > </example> > --- > > or B2: > --- > <example> > <c/> <b/> <b/> <c/> <a/> > </example> > --- > > As you can see, B1 would be correct if the modifications in script.xup > applied directly to A, while B2 would be correct if modifications apply > incrementally to the result of previous modifications. Interestingly, > the former behavior might be more "friendly" for using XUpdate in an > XSLT environment (e.g. implementing xmlpatch, or the application of an > XUpdate script to an in initial file, which is what I first tried to > hack together in XSLT). I'm not convinced that trying to do this sort > of XUpdate processing with XSLT is advisable, but it sure is tempting, > given the similarities. Regardless, the B1 behavior may simply be > inconsistent (although I can imagine some distinct weirdness in the B2 > case as well); I've haven't investigated it fully. > > Take care, > > John L. Clark > > [0] http://www.oreillynet.com/pub/wlg/6935 |
From: Per N. <per...@us...> - 2005-05-05 11:57:43
|
Sinde there were no objections and plenty of time has passed, I have now=20 granted Uche commit rights to the project. welcome on board Uche! Best regards, Per m=E5ndagen den 25 april 2005 00.18 skrev Per Nyfelt: > As per our rules for adding new developers I hereby propose that we grant > Uche Ogbuji commit status on the XML:DB project. His primary focus is on > Xupdate, where we currently completely lack active developers and are in > great need of help. > > Here's my +1 > > Best regards, > Per > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Xmldb-org-xupdate mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmldb-org-xupdate |
From: John L. C. <jl...@po...> - 2005-04-29 18:24:22
|
On Fri, Apr 29, 2005 at 10:41:28AM +0200, Wolfgang Meier wrote: > >3) It would be useful for update to allow element, attribute, etc. as=20 > >content. That said, I'm not convinced it's worth the complexity, as you= =20 > >can simply delete the element and reinsert it with the new content. >=20 > I would like to propose a "replace" instruction for this purpose. [...] > Example: >=20 > <xupdate:replace select=3D"/example/p[2]"> > <quote>a <b>replaced</b> paragraph</quote> > </xupdate:replace> This is exactly the effect that I would like the update instruction to have. If we had such a replace operation, would there be any further need for an update? It seems that the most common use case for update is a quick textual change within a #PCDATA element field; this could easily be accomplished with a simple replace. For example, the example in the spec under the update instruction could be performed with: --- <xupdate:replace select=3D"/addresses/address[2]/town/text()[1]" xmlns:xupdate=3D"http://www.xmldb.org/xupdate">New York</xupdate:replace> --- > Concerning "update", I would still allow element, text etc. as content=20 > if the "select" xpath evaluates to one or more elements. Otherwise, the= =20 > expression just updates the value of an attribute or text node. As I mentioned above, with such a replace instruction, I no longer see the point of update[0]. I actually think that either name for the instruction - "update" or "replace" - would be fine, although keeping it as "update" would be less disruptive. Take care, John L. Clark [0] In fact, I think this would simplify the spec even further - I no longer see the need for a delete operation. You could delete the "New York" text with: --- <xupdate:replace select=3D"/addresses/address[2]/town/text()[1]" xmlns:xupdate=3D"http://www.xmldb.org/xupdate"/> --- or the whole town with: --- <xupdate:replace select=3D"/addresses/address[2]/town" xmlns:xupdate=3D"http://www.xmldb.org/xupdate"/> --- |
From: John L. C. <jl...@po...> - 2005-04-29 18:13:05
|
On Thu, Apr 28, 2005 at 11:23:36PM -0700, Ronald Bourret wrote: > 1) The update expression you give is not legal -- the content of the=20 > update element is #PCDATA, not element, attribute, etc. Aha; I didn't examine the DTD closely enough to infer that point. The examples do each only use #PCDATA, but examples for other operations use arbitrary XML and the description of the update operation did not forbid it. I would propose that the description in the spec be made more explicit on this point. > 2) Why can't you say: >=20 > <xupdate:update select=3D"/example/p/text()[2]" > xmlns:xupdate=3D"http://www.xmldb.org/xupdate">baz</xupdate:update> Well, the spec says that the update operation "can be used to update the content of existing nodes". From the example given, I took this to mean that the subtree underneath the selected node was replaced with the update operation's content. This is why I thought that the replacing content could be any valid XML content. If a text node is explicitly selected, though, it does not have any subtree to update. To be explicit, if your example above were allowed, then following the example in the spec, both of: --- <xupdate:update select=3D"/addresses/address[2]/town" xmlns:xupdate=3D"http://www.xmldb.org/xupdate">New York</xupdate:update> --- and --- <xupdate:update select=3D"/addresses/address[2]/town/text()[1]" xmlns:xupdate=3D"http://www.xmldb.org/xupdate">New York</xupdate:update> --- could be used for the same update. However, they explicitly select different nodes for which to "update the content", which I believe is fundamentally broken. I would argue for one way or the other, but not both. I would prefer that the latter be made normative (that is, that update be treated precisely as node replacement, hence my original argument about the assignment operator semantics). > 3) It would be useful for update to allow element, attribute, etc. as=20 > content. That said, I'm not convinced it's worth the complexity, as you= =20 > can simply delete the element and reinsert it with the new content. I'm not convinced that it is that complex; it seems quite natural (at least to me), and it seems to follow suit with the other XUpdate operators. > 4) I agree this should be clarified. There are other issues that could also benefit from clarification here, such as how to update attribute content. Take care, John L. Clark |
From: Wolfgang M. <wol...@ex...> - 2005-04-29 08:41:33
|
> 3) It would be useful for update to allow element, attribute, etc. as > content. That said, I'm not convinced it's worth the complexity, as you > can simply delete the element and reinsert it with the new content. I would like to propose a "replace" instruction for this purpose. Maybe I'm wrong, but to replace an element by first deleting and then reinserting it, you need to keep track of the element's position. This is certainly possible (using a variable, for example), but a distinct "replace" expression would make it easier and leaves it to the XUpdate implementation to remember the previous position. Example: <xupdate:replace select="/example/p[2]"> <quote>a <b>replaced</b> paragraph</quote> </xupdate:replace> Concerning "update", I would still allow element, text etc. as content if the "select" xpath evaluates to one or more elements. Otherwise, the expression just updates the value of an attribute or text node. Wolfgang |
From: Ronald B. <rpb...@rp...> - 2005-04-29 06:23:34
|
1) The update expression you give is not legal -- the content of the update element is #PCDATA, not element, attribute, etc. 2) Why can't you say: <xupdate:update select="/example/p/text()[2]" xmlns:xupdate="http://www.xmldb.org/xupdate">baz</xupdate:update> It's not clear if this would work with comments and PIs. 3) It would be useful for update to allow element, attribute, etc. as content. That said, I'm not convinced it's worth the complexity, as you can simply delete the element and reinsert it with the new content. 4) I agree this should be clarified. -- Ron John L. Clark wrote: > I think that the xupdate:update operation should have similar semantics > to the assignment operator in most programming languages. Further, I > think that as it is currently defined[0], it falls short of that goal. > I notice that in each of the three update use cases ([1], [2], and [3]), > the update is performed on a text-only node (element, attribute, or > comment, respectively). I think the selector is not specific enough (as > defined) to cover all of the cases one might want, however. > > For example, consider the XML document: > > test.xml: > --- > <example> > <p> > foo > <em>yes!</em> > bar > </p> > </example> > --- > > How would you express changing "bar" to "baz" in an XUpdate operation? > The closest one can come to that node with the update operation would > be: > > --- > <xupdate:update select="/example/p" > xmlns:xupdate="http://www.xmldb.org/xupdate"> > <xupdate:text>foo</xupdate:text> > > <xupdate:element name="em">yes!</xupdate:element> > > <xupdate:text>baz</xupdate:text> > </xupdate:update> > --- > > Where I think one should be able to directly pinpoint any node for > update, with the semantics that the node (or node set!) is replaced with > the template content, not that the selected node's *contents* is > replaced with the template content (which, I believe, is the current > model). I would want to do it this way: > > --- > <xupdate:update select="/example/p/text()[2]" > xmlns:xupdate="http://www.xmldb.org/xupdate"> > <xupdate:text>baz</xupdate:text> > </xupdate:update> > --- > > I think this type of processing is clearer and more complete. > > Take care, > > John L. Clark > > [0] http://www.smb-tec.com/xmldb/xupdate/xupdate-wd.html#N6d2633 > > [1] http://www.xmldatabases.org/projects/XUpdate-UseCases/#10 > > [2] http://www.xmldatabases.org/projects/XUpdate-UseCases/#11 > > [3] http://www.xmldatabases.org/projects/XUpdate-UseCases/#12 |
From: Ronald B. <rpb...@rp...> - 2005-04-29 06:12:48
|
The spec does not say what happens in insert-before or insert-after when the XPath specified by the select attribute evaluates to an empty set. So perhaps append is required in this case, although this might be a hole in the spec instead. (It's actually not clear what to do with insert when the node set is empty. If it's empty because there are no children, the user might conceivably want append semantics. On the other hand, if it's empty because there were no children of the desired type, the user might want an error. Note that the spec also does not say what to do when the node set evaluates to more than one node.) Except in this case, it seems that append is a redundant shorthand for the useful case in which you simply want to add a child and don't care / don't know what other children exist. It is redundant because you can always write an XPath that evaluates to the last child node of a given parent (modulo the aforementioned no-child case). Personally, I think it's useful enough to be worth keeping. -- Ron John L. Clark wrote: > Is it true that xupdate:insert-after and xupdate:insert-before provide a > proper subset of the functionality of xupdate:append? In particular, > xupdate:append can be used to create a new child of the context node > in the case where there were no children of that context node, but in > those cases where there are children of a context node, it seems that > you could use xupdate:append or one of xupdate:insert-after and > xupdate:insert-before interchangeably. > > If this observation is correct, then why do xupdate:insert-after and > xupdate:insert-before exist? > > Take care, > > John L. Clark |
From: Philippe P. <Phi...@so...> - 2005-04-28 11:59:43
|
hi, I thought about solutions for "XUpdate processing order" problem (posted from John L. Clark 2005-04-27 22:48) I did my own "XUpdate" that I called "Active Update" that resolves this=20 kind of problems, and fix other things incomplete in the WD, for example=20 alternative and iterative processing. XUpdate example : http://disc.inria.fr/perso/philippe.poulard/xml/active-tags/active-tags/a= ctive-tags.html#N4007F6 (=A72.9) this example shows an alternative update ; however I didn't implement=20 XUpdate in Active Tags because I consider replacing it with Active Update Active Update processing order example : http://disc.inria.fr/perso/philippe.poulard/xml/active-tags/active-tags/a= ctive-tags.html#x-operation-example (=A75.5) this example shows a set operations that are "deferred", that is to say=20 applied after resolving all XPath references ; this is exactly what John=20 L. Clark was expected. Active Update is also slightly different than XUpdate because it may=20 update objects that are "XML-friendly objects", that is to say some=20 objects that are not XML objects but that can have some XML behaviour ;=20 for example, such object may expose its internal states as XML=20 attributes that may be accessed with XPath and update with Active Update Active Update is part of a wider framework called Active Tags Have a look here : http://disc.inria.fr/perso/philippe.poulard/xml/active-tags/ --=20 Cordialement, /// (. .) -----ooO--(_)--Ooo----- | Philippe Poulard | ----------------------- |
From: John L. C. <jl...@po...> - 2005-04-28 06:32:54
|
I think that the xupdate:update operation should have similar semantics to the assignment operator in most programming languages. Further, I think that as it is currently defined[0], it falls short of that goal. I notice that in each of the three update use cases ([1], [2], and [3]), the update is performed on a text-only node (element, attribute, or comment, respectively). I think the selector is not specific enough (as defined) to cover all of the cases one might want, however. For example, consider the XML document: test.xml: --- <example> <p> foo <em>yes!</em> bar </p> </example> --- How would you express changing "bar" to "baz" in an XUpdate operation? The closest one can come to that node with the update operation would be: --- <xupdate:update select="/example/p" xmlns:xupdate="http://www.xmldb.org/xupdate"> <xupdate:text>foo</xupdate:text> <xupdate:element name="em">yes!</xupdate:element> <xupdate:text>baz</xupdate:text> </xupdate:update> --- Where I think one should be able to directly pinpoint any node for update, with the semantics that the node (or node set!) is replaced with the template content, not that the selected node's *contents* is replaced with the template content (which, I believe, is the current model). I would want to do it this way: --- <xupdate:update select="/example/p/text()[2]" xmlns:xupdate="http://www.xmldb.org/xupdate"> <xupdate:text>baz</xupdate:text> </xupdate:update> --- I think this type of processing is clearer and more complete. Take care, John L. Clark [0] http://www.smb-tec.com/xmldb/xupdate/xupdate-wd.html#N6d2633 [1] http://www.xmldatabases.org/projects/XUpdate-UseCases/#10 [2] http://www.xmldatabases.org/projects/XUpdate-UseCases/#11 [3] http://www.xmldatabases.org/projects/XUpdate-UseCases/#12 |
From: John L. C. <jl...@po...> - 2005-04-28 06:16:04
|
Is it true that xupdate:insert-after and xupdate:insert-before provide a proper subset of the functionality of xupdate:append? In particular, xupdate:append can be used to create a new child of the context node in the case where there were no children of that context node, but in those cases where there are children of a context node, it seems that you could use xupdate:append or one of xupdate:insert-after and xupdate:insert-before interchangeably. If this observation is correct, then why do xupdate:insert-after and xupdate:insert-before exist? Take care, John L. Clark |
From: John L. C. <jl...@po...> - 2005-04-28 05:48:00
|
Uche's recent XUpdate update[0] (heh) has renewed my interest in this language. I am very interested in a diff solution for XML. I had looked at XUpdate before, but hadn't found anything that seemed reasonable to use as a diff producing tool. This time I looked (more closely) at xmldiff, and things seem more hopeful. There is clearly a lot of work to do. I started hacking on that codebase, and immediately saw some frustrating gaps and inconsistencies in the definition of XUpdate as a language. So, let's get to work, shall we? This may be obvious, but it seems to me that the XUpdate working draft could use a section on its processing model (even if that model is mostly what one would expect). First, I suppose, one needs to define what is being processed. I would say that given two XML documents A and B, an XUpdate document U describes the difference B - A, that is, a sufficient set of operations which, when applied to A, produce B. As a result, the processing model would be that given A and U, one applies the instructions in U to the content in A to get some B. Clearly, an XUpdate document consists of a sequence of modifications. Is the intent that these modifications be applied in document order? If so, do each of these modifications apply independently to A, or to an intermediate step formed from the result of the previous modification? As an example of the problem, consider the following document: A: --- <example> <a/> <b/> <b/> <a/> </example> --- and XUpdate script: script.xup: --- <xupdate:modifications xmlns:xupdate="http://www.xmldb.org/xupdate"> <xupdate:insert-before select="/example/a[1]"> <xupdate:element name="c"/> </xupdate:insert-before> <xupdate:remove select="/example/a[1]"/> <xupdate:insert-before select="/example/a[1]"> <xupdate:element name="c"/> </xupdate:insert-before> </xupdate:modifications> --- When applying script.xup to A, would this produce: B1: --- <example> <c/> <c/> <b/> <b/> <a/> </example> --- or B2: --- <example> <c/> <b/> <b/> <c/> <a/> </example> --- As you can see, B1 would be correct if the modifications in script.xup applied directly to A, while B2 would be correct if modifications apply incrementally to the result of previous modifications. Interestingly, the former behavior might be more "friendly" for using XUpdate in an XSLT environment (e.g. implementing xmlpatch, or the application of an XUpdate script to an in initial file, which is what I first tried to hack together in XSLT). I'm not convinced that trying to do this sort of XUpdate processing with XSLT is advisable, but it sure is tempting, given the similarities. Regardless, the B1 behavior may simply be inconsistent (although I can imagine some distinct weirdness in the B2 case as well); I've haven't investigated it fully. Take care, John L. Clark [0] http://www.oreillynet.com/pub/wlg/6935 |
From: Uche O. <Uch...@fo...> - 2005-04-26 15:27:22
|
On Sun, 2005-04-24 at 10:33 -0600, Uche Ogbuji wrote: > I don't have time, but I'm speaking in the possibly vain hope that I can > find a way to carve out a few slices here and there. I at least found the time for this: http://www.oreillynet.com/pub/wlg/6935 -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://fourthought.com http://copia.ogbuji.net http://4Suite.org Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-xml.html Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/ Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html |
From: Todd B. <by...@cn...> - 2005-04-25 15:21:21
|
Any chance of having someone look at my patch for the default XUpdate=20 implementation on source forge? It fixes the temporary node issue. Here is the link. http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1019222&grou= p_id=3D75532&atid=3D544179 Todd Uche Ogbuji wrote: > On Sun, 2005-04-24 at 17:44 +0200, Per Nyfelt wrote: >=20 >>s=F6ndagen den 24 april 2005 16.11 skrev Uche Ogbuji: >=20 >=20 >>>>>Maybe create a separate "xupdate" project on SourceForge? >>>>> >>>>>Maybe get xupdate.org? >>>> >>>>If it grows big then yes but I do not see the need for that right now. >>> >>>Well, at the very least we should move Kimbro's use cases to the same >>>place as the specs. >> >>Yes, good idea. Since it seems you have some time to devote to this I l= ike to=20 >>propose you as committer on the project and also ability to update the = web=20 >>pages. Please let me know if I have understood you correctly and this i= s in=20 >>line with your ideas. >=20 >=20 > I don't have time, but I'm speaking in the possibly vain hope that I ca= n > find a way to carve out a few slices here and there. Go ahead and add > me as a committer. SF id is "uche". I'll do what I can. >=20 > If you contact Kimbro about the links, please also ask about permission > to copy his use-cases page. I'm quite sure I can at least muster time > to copy those files over. >=20 >=20 >=20 >>>I'd still like to know if I'm missing any implementations from my list >>> >>>(or if I have any stale info): >> >>Ozone also supports XUpdate. >=20 >=20 > Thanks. >=20 >=20 |
From: Per N. <per...@re...> - 2005-04-24 22:18:44
|
As per our rules for adding new developers I hereby propose that we grant Uche Ogbuji commit status on the XML:DB project. His primary focus is on Xupdate, where we currently completely lack active developers and are in great need of help. Here's my +1 Best regards, Per |