Gendal

The problem seems to be the following quote from the w3c schema 1.0 primer:



Since the sidl schema allows you to leave out tags as you see fit or include them as you see fit I don't see how the "choice" or "sequence" element constraints would apply at all. The all is exactly what I need, but with the restrictions imposed by 1.0 as I bolded above it of course doesn't work.

I assume there is another way to do it, or more likely I am just looking at it all wrong, but either way I am completly stumped.

Up at http://www.jrh.net/sidlschema.zip is an old work in progress (read: major hack) xslt and a generated xsd from the sidl.xml using the xslt. think I have the complex types set to use the choice restriction atm, which of course doesn't work at all. sequence doesn't work, and "all" is limited to the root level, any child derived "all" restrictions automatically revert to a sequence restriction. =(

Kraegar

Ok, failing newlines, can you fake em using some sort of row/column setup? Or even screenpieces with relative positions? (So they are in the same window, but the second isn't at a fixed x,y loc, but rather started immediately below the first)?

UniDyne

This is true - that's the way it's supposed to work.


The equivalent of the ? operator in a DTD. This is exactly the behaviour we are looking for. Hard to believe that this is only available for top-level elements... or is it?

What if we used sequence instead of choice?

Sounds exactly like what we want - with one exception: this is the equivalent of the * operator in a DTD, not ?. To correct this, we can simply set the sequence's maxOccurs attribute to 1. As far as I can tell, in most cases, this provides the same functionality that all does in top-level elements.

From everything that I've seen, using sequence is the only choice (no pun intended ). I think it's results will be right on. What were the problems you were having with sequence?

UniDyne

Yes. You simply have to group the text elements together. ScreenItem tags may be nested within other ScreenItem tags. So, create a ScreenItem and call it, say, MyText. Set the coordinates and size for that screen item for where you want the text to appear. Then, within that ScreenItem we call MyText, place ScreenItems for each text box you want to appear. Their coordinates will be relative to MyText instead of the window.

When you place this into the window, only place the MyText piece, not those other text fields you created - they have already been placed in MyText.

Hope this helps. Let me know.

Gendal

Well from how i understand it a sequence is a sequence, it does not support out of order elements. So 1, 2, 3, 4, 5, and 6 is valid, but 4, 2, 3, 5, 6, and 1 is not because they are out of order. Testing of the schema seems to bear this out, if I generate a sample from the schema using xmlspy it revalidates and looks fine, but soon as I change say the DrawTemplate to before the RelativePosition tag I get an unexpected child element. EQ of course completly ignores any order so I am at a loss of what to do.

Btw there are at least two errors in the uploaded file I found already while quickly reviewing my work. One, the generated element tags need at least a 0 or 1 min/max attribute added if there is no previos min/max specified in sidl.xml to follow, and two, elements with :item attributes should be translated as a string, and not the respective complexType.

UniDyne

What if we used xsd:group alone instead of placing a sequence or choice inside? My understanding is that group does not restrict ordering. If sequence restricts ordering and choice only allows us to use one element, why use them at all?