[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Problem with "not relevant": binding XForms events to elements and attributes missing in the model instance.
Team, This is an interesting use case that has come up on the public W3C list - that cannot be solved with Schema - but absolutely can be with CAM templates and the BusinessContextRules predicates. Enjoy, DW. -------------Forwarded Message----------------- From: INTERNET:w3c-xml-schema-ig@w3.org, INTERNET:w3c-xml-schema-ig@w3.org To: , INTERNET:w3c-xml-schema-ig@w3.org Date: 3/31/2004 8:34 AM RE: FW: Problem with "not relevant": binding XForms events to elements and attributes missing in the model instance. This posting is FYI to the Schema WG. Replies are on w3c-forms@w3.org > -----Original Message----- > From: David Ezell > Sent: Thursday, March 25, 2004 12:59 PM > To: 'w3c-forms@w3.org' > Subject: Problem with "not relevant": binding XForms events to elements and attributes missing in the model instance. > > Dear XForms WG: > Sorry if I should have sent this to the public list. I was unsure, so decided to proceed cautiously. > > There is a particular XForms 1.0 issue which is proving to be a big headache for my company: specifically, the problem is > that XForms 1.0 specifies that if the XForms processor attempts to bind to an element that doesn't exist in a specific model > instance, the processor is to treat that binding as "not relevant" even if the element is valid per the schema. Our servers > provide 1) schemas for validation and 2) schema-valid XML documents. Now we'd like to layer XForms applications on top > of that . The problem is that the binding might indeed be relevant per the schema, and based on some user action the missing > element might become present. > > An example: I'll stick with elements -- attributes are somewhat the same but more constrained. > > Here's an instance document, allowed to have one kind of fruit and an optional cake as party refreshments: > > <?xml version="1.0" encoding="UTF-8"?> > <partyMix> > <fruit> > <apple count="5"/> > </fruit> > <cake count="2"/> > </partyMix> > > Here's the schema for that document: > > <?xml version="1.0" encoding="UTF-8"?> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified" attributeFormDefault="unqualified"> > <xs:element name="partyMix"> > <xs:complexType> > <xs:sequence> > <xs:element ref="fruit" minOccurs="1"/> > <xs:element name="cake" minOccurs="0" type="countable"/> > </xs:sequence> > </xs:complexType> > </xs:element> > <xs:element name="fruit"> > <xs:complexType> > <xs:choice> > <xs:element ref="apple"/> > <xs:element ref="orange"/> > </xs:choice> > </xs:complexType> > </xs:element> > <xs:element name="apple" type="countable"/> > <xs:element name="orange" type="countable"/> > <xs:simpleType name="nonEmptyString"> > <xs:restriction base="xs:string"> > <xs:minLength value="5"/> > </xs:restriction> > </xs:simpleType> > <xs:complexType name="countable"> > <xs:simpleContent> > <xs:extension base="nonEmptyString"> > <xs:attribute name="count" use="required"/> > </xs:extension> > </xs:simpleContent> > </xs:complexType> > </xs:schema> > > Note that the "cake" element is optional, whereas the "fruit" element is required and must have a child which is one of "apple" or > "orange". Our developers claim that they have problems directing (i.e. binding) events to "orange" if only "apple" is there, and > similar problems with binding events to "cake" if "cake" is missing in the instance. (Note that though "orange" and "apple" are > identical in the example, "orange" could have other attributes or children making it non-identical.) > > We think this is an issue that the XForms working group must address very soon. One solution might be to construct a shadow > "hypothetical" document based on "what elements or attributes are possible" so that events can be bound, not relying on any > specific model instance. > > Other mitigating but less attractive ideas are: > 1) allow pre- and post-processing using XSLT. > 2) build in scripting hooks so that JavaScript can be called by the XForms processor at predetermined points. > > I'll note that the developers are using JavaScript to patch the problem in the short term, but it makes the whole business much > less maintainable. The fact that this scripting has to be done outside the purview of the REC (and therefore outside of the XForms processor) > damages interoperability. > > Please understand that we believe that this is a very serious problem, and not one that we can or should fix by redesigning our schemas. We > > believe that XForms should be able to accept and produce schema-valid (small 's') XML. > > As always, thanks in advance for your consideration. Please let me know if I'm missing something. > > Best regards, > David Ezell > National Association of Convenience Stores >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]