Context Sensitive Element Definitions in W3C XSD Schema?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Context Sensitive Element Definitions in W3C XSD Schema?

Steve Batides
Is this email address the equivalent of a forum post?

I know of know way to achieve this with the W3C schema rec 1.0 and I've always assumed it's impossible, but it's been such a pain for so long I thought I should at least ask if anyone knew of some clever way to achieve it. I havent read the 1.1 rec, but I believe it has some sort of context-based defns allowed. Unfortunately, I am not in a situation to be using 1.1 with any of our clients, so what I can do with 1.0 is all I have to work with.

Basically I need to define a hierarchical set of IF/ELSE/ELSEIF elements that can be used to contain children, and I need the children allowed to be whatever elements are allowed inside the *PARENT* of the IF. Because the IF/ELSE/ELSEIF can occur inside most elements in the schema, all of which have quite different content models, the only way that I know of to support these requirements is to allow IF/ELSE/ELSEIF to contain just about anything in the overall schema. That is bad for obvious reasons; it allows tons of stuff to be populated where it really has no business existing because the IF/ELSE/ELSEIF allows so much.

Does anyone know of any way to effectively have an element (in this case IF/ELSE/ELSEIF) mimic the content model of it's parent to support the requirements above, while only allowing elements that really "belong" as 'grandchildren'?
--

Regards,

steve...


--

Steve Batides

MOLTEK Inc.

mobile: 1-727-505-1473

vmail:     1-877-650-8479  x1002

[hidden email]

www.moltek.com


**THE CONTENT OF THIS EMAIL IS MOLTEK PROPRIETARY**

DISCLAIMER

Encryption and Viruses: This e-mail and any attachments may not have not been encrypted and therefore they may be liable to be compromised. Viruses and compromises of security are inherent risks in relation to e-mail and consequently it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.

Confidentiality Notice: The information contained within this is confidential and is intended for the named recipients only. If you are not one of the intended recipients as indicated in the TO, CC and BCC fields, please return it to this firm by e-mail quoting the name of the sender and the addressee. Please then delete it from your system.
Reply | Threaded
Open this post in threaded view
|

Re: Context Sensitive Element Definitions in W3C XSD Schema?

Michael Kay

On 24 Aug 2013, at 03:27, Steve Batides wrote:

Is this email address the equivalent of a forum post?

The list description is "Public discussion forum for implementors and users of W3C XML Schema", so yes, you can use it that way.

I know of know way to achieve this with the W3C schema rec 1.0 and I've always assumed it's impossible, but it's been such a pain for so long I thought I should at least ask if anyone knew of some clever way to achieve it. I havent read the 1.1 rec, but I believe it has some sort of context-based defns allowed. Unfortunately, I am not in a situation to be using 1.1 with any of our clients, so what I can do with 1.0 is all I have to work with.

Basically I need to define a hierarchical set of IF/ELSE/ELSEIF elements that can be used to contain children, and I need the children allowed to be whatever elements are allowed inside the *PARENT* of the IF. Because the IF/ELSE/ELSEIF can occur inside most elements in the schema, all of which have quite different content models, the only way that I know of to support these requirements is to allow IF/ELSE/ELSEIF to contain just about anything in the overall schema. That is bad for obvious reasons; it allows tons of stuff to be populated where it really has no business existing because the IF/ELSE/ELSEIF allows so much.

Does anyone know of any way to effectively have an element (in this case IF/ELSE/ELSEIF) mimic the content model of it's parent to support the requirements above, while only allowing elements that really "belong" as 'grandchildren'?

If you define these as local elements then their content model can depend on where they occur. For example you can define a type like this

<xs:complexType name="someType">
  <xs:choice>
    (something)
    <xs:element name="if" type="someType"/>
   ....

<xs:complexType name="someOtherType">
  <xs:choice>
    (something)
    <xs:element name="if" type="someOtherType"/>

Michael Kay
Saxonica

Reply | Threaded
Open this post in threaded view
|

Re: Context Sensitive Element Definitions in W3C XSD Schema?

Steve Batides
Thanks Michael, you made it clear I needed to think a bit more comprehensively about what I put into my question. My apologies for that; I left out a key factor in my question.

I had thought about the solution you mentioned, and the possibility of creating an automated dev tool (presumably xslt) that would run through the schema and insert a local element declaration for the IF inside each element, mimicking the content model of the parent, such that I could run it whenever doing mods to the schema. The showstopper, as far as I know, was that the IF element is in a different namespace from the various elements of which it is a child. These IFs are used for a specific purpose during certain "phases" of XSLT that we run instance files through, and consequently they are defined in a specific namespace with other elements used for related types of parsing. As far as I could figure out, though I could be wrong, there is no way to create a local definition for an element in a different namespace from it's parent; is that right?

I know Im creating a seriously constrained problem, but that's why we've ignored it for so long and left in this undesirable allowance of the whole "kitchen sink" being insertable within these IF elements. It's a big enough issue that I've considered changing the namespaces, but that would be a backwards-incompatible change that would be unacceptable to all our clients with deployed systems. It would be nice to phase the namespace out, but we'd have to double-up on the IF elements allowed and probably confuse clients.



--

Regards,

steve...


--

Steve Batides

MOLTEK Inc.

mobile: 1-727-505-1473

vmail:     1-877-650-8479  x1002

[hidden email]

www.moltek.com


**THE CONTENT OF THIS EMAIL IS MOLTEK PROPRIETARY**

DISCLAIMER

Encryption and Viruses: This e-mail and any attachments may not have not been encrypted and therefore they may be liable to be compromised. Viruses and compromises of security are inherent risks in relation to e-mail and consequently it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.

Confidentiality Notice: The information contained within this is confidential and is intended for the named recipients only. If you are not one of the intended recipients as indicated in the TO, CC and BCC fields, please return it to this firm by e-mail quoting the name of the sender and the addressee. Please then delete it from your system.
Reply | Threaded
Open this post in threaded view
|

Re: Context Sensitive Element Definitions in W3C XSD Schema?

Michael Kay
> As far as I could figure out, though I could be wrong, there is no way to create a local definition for an element in a different namespace from it's parent; is that right?
>

I think you can do it using named model groups (xs:group). If a group contains element declarations, those will be local element declarations in the same namespace as the group, which can be a different namespace from the element or type that references the group.

Michael Kay
Saxonica


Reply | Threaded
Open this post in threaded view
|

Re: Context Sensitive Element Definitions in W3C XSD Schema?

Steve Batides
Michael,

It's non-intuitive (to me) that the namespace distinction can be achieved by wrapping the local declaration in a group declaration, but I guess it sort of makes sense after a bit of thought. I have only tested it with one editor, but I implemented one such group in the desired IF namespace but containing a "customized" local declaration of the IF element, and it works. I'll test a couple other validators later, but your suggestion was correct. Thanks VERY much; it's a bit of work to build the infrastructure XSLT to modify and maintain it, but I now have a solution that is going to do what we need. I should have found this forum years ago...



--

Regards,

steve...


--

Steve Batides

MOLTEK Inc.

mobile: 1-727-505-1473

vmail:     1-877-650-8479  x1002

[hidden email]

www.moltek.com


**THE CONTENT OF THIS EMAIL IS MOLTEK PROPRIETARY**

DISCLAIMER

Encryption and Viruses: This e-mail and any attachments may not have not been encrypted and therefore they may be liable to be compromised. Viruses and compromises of security are inherent risks in relation to e-mail and consequently it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.

Confidentiality Notice: The information contained within this is confidential and is intended for the named recipients only. If you are not one of the intended recipients as indicated in the TO, CC and BCC fields, please return it to this firm by e-mail quoting the name of the sender and the addressee. Please then delete it from your system.
Reply | Threaded
Open this post in threaded view
|

Re: Context Sensitive Element Definitions in W3C XSD Schema?

Steve Batides
In reply to this post by Michael Kay
Michael,

It's non-intuitive (to me) that the namespace distinction can be achieved by wrapping the local declaration in a group declaration, but I guess it sort of makes sense after a bit of thought. I have only tested it with one editor, but I implemented one such group in the desired IF namespace but containing a "customized" local declaration of the IF element, and it works. I'll test a couple other validators later, but your suggestion was correct. Thanks VERY much; it's a bit of work to build the infrastructure XSLT to modify and maintain it, but I now have a solution that is going to do what we need. I should have found this forum years ago...



--

Regards,

steve...


--

Steve Batides

MOLTEK Inc.

mobile: 1-727-505-1473

vmail:     1-877-650-8479  x1002

[hidden email]

www.moltek.com


**THE CONTENT OF THIS EMAIL IS MOLTEK PROPRIETARY**

DISCLAIMER

Encryption and Viruses: This e-mail and any attachments may not have not been encrypted and therefore they may be liable to be compromised. Viruses and compromises of security are inherent risks in relation to e-mail and consequently it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.

Confidentiality Notice: The information contained within this is confidential and is intended for the named recipients only. If you are not one of the intended recipients as indicated in the TO, CC and BCC fields, please return it to this firm by e-mail quoting the name of the sender and the addressee. Please then delete it from your system.
Reply | Threaded
Open this post in threaded view
|

Re: Context Sensitive Element Definitions in W3C XSD Schema?

Steve Batides
Sorry, looks like my previous post didnt come through right; I should
have used plain text. Im resending so that it's on the list site for
reference by anyone else:

Michael,

That works...

It's non-intuitive (to me) that the namespace distinction can be
achieved by wrapping the local declaration in a group declaration, but I
guess it sort of makes sense after a bit of thought. I have only tested
it with one editor, but I implemented one such group in the desired IF
namespace but containing a "customized" local declaration of the IF
element, and it works. I'll test a couple other validators later, but
your suggestion was correct. Thanks *VERY *much; it's a bit of work to
build the infrastructure XSLT to modify and maintain it, but I now have
a solution that is going to do what we need. I should have found this
forum years ago...

Reply | Threaded
Open this post in threaded view
|

Re: Context Sensitive Element Definitions in W3C XSD Schema?

Michael Kay
In reply to this post by Steve Batides
Yes, very non-intuitive.

XSD 1.1 allows a targetNamespace attribute on a local xs:element, but only under very restricted circumstances. I argued for removing all restrictions and allowing it anywhere, but others wanted to keep a stronger relationship between schema modules and namespaces, so I didn't win that one.

Michael Kay
Saxonica

On 26 Aug 2013, at 00:51, Steve Batides wrote:

Michael,

It's non-intuitive (to me) that the namespace distinction can be achieved by wrapping the local declaration in a group declaration, but I guess it sort of makes sense after a bit of thought. I have only tested it with one editor, but I implemented one such group in the desired IF namespace but containing a "customized" local declaration of the IF element, and it works. I'll test a couple other validators later, but your suggestion was correct. Thanks VERY much; it's a bit of work to build the infrastructure XSLT to modify and maintain it, but I now have a solution that is going to do what we need. I should have found this forum years ago...



--

Regards,

steve...


--

Steve Batides

MOLTEK Inc.

mobile: 1-727-505-1473

vmail:     1-877-650-8479  x1002

[hidden email]

www.moltek.com


**THE CONTENT OF THIS EMAIL IS MOLTEK PROPRIETARY**

DISCLAIMER

Encryption and Viruses: This e-mail and any attachments may not have not been encrypted and therefore they may be liable to be compromised. Viruses and compromises of security are inherent risks in relation to e-mail and consequently it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.

Confidentiality Notice: The information contained within this is confidential and is intended for the named recipients only. If you are not one of the intended recipients as indicated in the TO, CC and BCC fields, please return it to this firm by e-mail quoting the name of the sender and the addressee. Please then delete it from your system.