How do we implement xsd:choice nodes? - xmlDraft - Products - SysOnyx Inc. - Message Board - Yuku

RSS
Email

0 Kudo

<< Previous Topic Next Topic >>

How do we implement xsd:choice nodes?

Author	Comment
Bryce K Nielsen	How do we implement xsd:choice nodes?	Lead	[-]
Posts: 230 (05/17/02 07:53:52) Administrator Reply Quote More My Recent Posts Message Me Connection Blocking Invite Ignore User's Posts	Tags : None A recent bug was reported via email about xsd:choice nodes. Currently, we haven't implemented xsd:choice yet. And if you have it in your schema, it's reported and an invalid child of the node it's under (such as complexType). It is not an invalid child, that's just how xmlArchitect processes the schema. When it comes across a node that we haven't implemented yet, it reports it as an invalid child. The main problem with xsd:choice is how do you represent that inside of the XMLTree? We are striving our best to make that tree show exactly what the XML document should look like, so we can't introduce a 'choice' node in the tree with children of the choice below it, because that node would never appear in the instance document. We're toying with the idea of having the parent node of the Choice element repeat itself and the children would be different, displaying the different choice children, such as: XMLSchema===========<xsd:element name="Orders"> <xsd:complexType> <xsd:sequence> <xsd:element name="Order"> <xsd:complexType> <xsd:choice> <xsd:element name="OrderType" type="xsd:string"/> <xsd:element name="PONum" type="xsd:string"/> <xsd:element name="Customer" type="xsd:string"/> <!-- etc.. ---- </xsd:choice> <xsd:choice> <xsd:element name="OrderType" type="xsd:string"/> <xsd:element name="OrderNum" type="xsd:string"/> <xsd:element name="Client" type="xsd:string"/> <!-- etc.. ---- </xsd:choice> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType></xsd:element>XMLTree========== Orders \|- Order (choice1) \|- OrderType \|- PONum \|- Customer \|- Order (choice2) \|- OrderType \|- OrderNum \|- Client As of this time, that's how we're thinking about implementing xsd:choice nodes. Would this be a viable solution? How else would you do it? Remember, we're trying our best to keep the XML tree exactly that, a representation of the XML, not of the XSD... -BKN
Unregistered(d)	xsd	#1	[-]
Posts: 0 (01/02/03 08:34:31) Reply Quote More My Recent Posts Message Me Connection Blocking Invite Ignore User's Posts	Hi, Just downloaded xmlArchitect, and the GUI is very much what I've been looking for for a while. Lots of possibilities. I don't really have an answer to your question, because I don't understand the idea behind the "xml tree". Why do you want to reflect the resulting xml in your tree? Why not, simply, use it to give a tree view of the xsd? Thats what I though it was when I started using the program. I tried to change a "sequence" to a "choice" and a "all" (as seen here: www.w3schools.com/schema/...cators.asp Both options break the validation in your program, thrus breaking the tree view. My prediction is that you'll get endless problems with the xml tree, if it breaks every time you are incapable of validating the xsd, thrus seriously limiting the usage of xmlArchitect. I can't not work on in xmlArchitect because there's nothing in the tree (except the root node). well, I can work on in xmlArchitect, but theres not point to it as it has just downgraded it self to an editor. (btw: it crashes fairly often for me) Yours Thomas Christensen
Bryce K Nielsen	Re: xsd	#2	[-]
Posts: 230 (01/02/03 14:04:44) Administrator Reply Quote More My Recent Posts Message Me Connection Blocking Invite Ignore User's Posts	For a lot of schemas out there, XSD isn't very easy to read and understand, particularly if you're not very experienced with the syntax. The XML Tree View is attempting to show what an Instance Document would look like for the given schema. Looking at a "sample" document for the given schema is a lot easier to understand for most. As to the current support of XSD, it's true that xmlArchitect is in beta, some features are not yet complete (such as xsd:choice and xsd:all nodes) and there are some bugs (crashings and whatnot). This doesn't mean you can't enter 'unsupported' nodes directly into the editor, xmlArchitect just doesn't know yet how to display these nodes in the TreeView. That's not to say support for these features won't be added, we just haven't gotten there yet What makes xmlArchitect stand out from the other XML Schema editors out there is the ability to view an instance document and create a schema for it. Direct manipulations within the instance document will update the Schema (and of course, visa-versa). As you've seen, with the current version of xmlArchitect this starts to break down a little bit when we get into some of the more advanced features of XML Schemas, but that's why we value User Feedback. With your input, we can steer xmlArchitect to answer the more complicated XSD problems in an intuitive manner. The main goal of xmlArchitect is to not show a treeview of the Schema, but rather a mockup of an Instance Document, but if you think a tree representation of the schema itself would be useful, then we may just add that. -BKN
slholmes	Re: How do we implement xsd:choice nodes?	#3	[-]
Posts: 11 (01/02/03 15:40:37) Reply Quote More My Recent Posts Message Me Connection Blocking Invite Ignore User's Posts	Appologies in advance for maybe speaking out of turn. I do have a background in developing user interfaces and I'd like to make some observations: I've looked at both xmlArchitect and xmlHack. I was particularly fascinated by the Tag Insight feature of xmlHack and it seems to me that if an XML editor has access to the XML schema, then it would follow that that editor could easily assist in the creation of XML instance documents. It follows then that xmlArchitect and xmlHack should merge to form a single powerful environment for the simultanteous development of XML schema and XML docs. I see the case for a tree view and a plain text view for both. And of course both editors are kept in sync. As for the actual question on choice: would it be possible to change the folder cell in the XML tree to a dropdown list? In this way, you only ever really show the one choice. Adding a new choice would be like an F2 function or something. Cheers!
Bryce K Nielsen	Re: xmlHack w/ xmlArchitect	#4	[-]
Posts: 230 (01/02/03 16:29:51) Administrator Reply Quote More My Recent Posts Message Me Connection Blocking Invite Ignore User's Posts	xmlHack and xmlArchitect are both simple tools that satisfy a very specific need. xmlHack is meant to be a simple text editor with some special XML features. xmlArchitect is meant to be a simple XML Schema editor with the ability to view and edit a mockup of an instance document for the currently loaded editor. Yes, there are some cross-features for these apps, and as we improve them they'll share a small set of commonality, but they won't ever be the same application for this reason: they are both small, simple tools that have their need. A lot of XML users are what we call "casual" XML users. They don't develop fulltime in XML, they use it to occassionaly suppliment their normal development, or their business demands that they occassionally view XML documents. These types of users need a simple tool that makes the occassional XML usage easier. The larger tools out there are too bloated with useless features, cost too much to justify their cost, and are simply annoying to use. xmlHack is pure, simple and easy. It's great for both the "casual" user as well as the more hardcore developer who prefers it when programs stay out of their way (i.e. the Notepad developer). So, xmlHack and xmlArchitect will always remain two applications, particularly since xmlArchitect is meant more for the XML Developer than the casual user (so it has more powerful features, etc). Mind you that doesn't mean we aren't going to improve xmlHack, with features like auto-loading TagInsight for locatable schemas, etc. -BKN
Bryce K Nielsen	Re: xmlHack's TagInsight	#5	[-]
Posts: 230 (01/02/03 16:36:20) Administrator Reply Quote More My Recent Posts Message Me Connection Blocking Invite Ignore User's Posts	BTW, until we do implement a 'import TagInsight' feature, you can manually add nodes through the Options page. A little tedious, true, but do it once and then forget about it, and from then on any document you open with that namespace will have the full TagInsight readily available. Future versions will have even more useful TagInsight features (such as dynamically knowing what nodes are available at the current level, ability to auto-import schemas without having to enter them into the TagInsight options page, etc). -BKN
Bryce K Nielsen	Re: How do we implement xsd:choice nodes?	#6	[-]
Posts: 230 (01/02/03 16:49:26) Administrator Reply Quote More My Recent Posts Message Me Connection Blocking Invite Ignore User's Posts	Back to the topic at hand, we'd tossed that idea around too, having a dropdown of the different possible nodes, but ended up not using it due to the overall design goal. We want the XML tree to look like an XML Document without needing any special mouse manipulation. To have a "choice dropdown" you wouldn't be able to properly see what the document allows without clicking around. So, either we replicate the different choices (as mentioned above), we create more nodes (which breaks the whole tree=instance and makes the tree more like the schema), or we just put all choices at the same level and just have a different icon/image from a "normal" or non-choice node. -BKN

<< Previous Topic Next Topic >>

Quick Reply