Bugs item #717680, was opened at 2003-04-08 11:24 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=717680&group_id=22866
Category: None Group: v4.0 >Status: Closed Resolution: None Priority: 5 Submitted By: Han Ming ONG (hanming) Assigned to: Nobody/Anonymous (nobody) Summary: Make *-service.xml 'validable' Initial Comment: A little while back, I reported this bug: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=715680&group_id=22866 It brought jboss-service_3_2.dtd closer to what David Jencks has in mind: "we do not have a dtd for *-service files because attributes can have xml element values. AFAIK the only way to cater to this is with namespaces and xml schema. We may need to do this for jboss 4. basically... <depends optional-attribute-name="foo">[object name or another mbean dd]</depends> and <depends-list optional-attribute-name="bar"> <depends-list-element>[o-n or mbean dd]</depends-list-element> <depends-list-element>[o-n or mbean dd]</depends-list-element> ... </depends-list>" jboss-service_3_2.dtd is as good a DTD as in reflecting what David has in mind but it has a major problem: it can never be used to validate any *-service.xml file. This is because XML 1.0 can never have this kind of construct (represented here as using DTD language, as opposed to Schema because it cannot be represented using the latter): <!ELEMENT depends (#PCDATA | mbean)> The closest that one can come up with is <!ELEMENT depends (#PCDATA | mbean)*> This is how XML 1.0 (may XML 1.1 changes it, I don't know) deal with a class of SGML problem known as the 'pernicious mixed content". Search Google for more details. http://www.w3.org/TR/REC-xml#sec-mixed-content Summary: --------------- I know it's too late to change anything for 3.2 but I have suggestions for 4.0 1. Don't use mixed content, if possible. It's easy to get it wrong in different level: API, parsing and writing of DTDs/Schemas. 2. The easiest local workaround for the element <depends> is to use Element wrapper pattern, e.g: <!ELEMENT depends-content (#PCDATA)> <!ELEMENT depends (depends-content | mbean)> But that might not be a good overall solution. 3. Bear in mind that XML Schema in designed to work with XML 1.0, hence the closest one can use Schema to constraint <depends> is: <xs:element name="depends"> <xs:complexType mixed="true"> <xs:choice> <xs:element ref="mbean"/> </xs:choice> <xs:attribute name="optional-attribute-name" type="xs:string"/> </xs:complexType> </xs:element> which is not really what David's original intention is. Thank you, Han Ming ---------------------------------------------------------------------- Comment By: Scott M Stark (starksm) Date: 2004-12-29 12:51 Message: Logged In: YES user_id=175228 All issues have been moved to http://jira.jboss.com. Existing issues have been moved. New issues will be closed with this canned reponse. ---------------------------------------------------------------------- Comment By: Han Ming ONG (hanming) Date: 2003-04-08 12:03 Message: Logged In: YES user_id=741972 1. What you have in mind is a choice contraint: either you want string content or you want Elements content. In general, to represent this kind of constraints in DTD/Schema, one would refer to in the XML lingo as "mixed content". It is a term that is used to refer to the potential mixing of String/Element. Whether it is actually mingled or not does not affect the semantics of the technical term "mixed content". Hope that is clear. The point is: it is not possible to contraint what you have in mind, using XML 1.0's DTD or XML Schema. Which makes the XML file not validable. 2. There is of course another problem that is clear to everyone, which is why I didn't bring it up: the use of "ANY". In this case, using CDATA would not solve the problem because CDATA just means string content that is not parsed (thus able to contain stuff like '<' etc). The parser and validator usually just takes the data and spits it back to higher level. This problem has to be solved eventually. This bug is not about it and I don't have a solution. Cheers. ---------------------------------------------------------------------- Comment By: David Jencks (d_jencks) Date: 2003-04-08 11:41 Message: Logged In: YES user_id=60525 I don't understand the problem you describe. There is no mixed content in the depends or depends-list-element elements that I can see. depends can have one object name or one embedded mbean config, and so can depends-list-element. If I misunderstand please give a concrete example of the mixed content. The problem I was originally referring to is not related to depends elements. You can have an mbean attribute of type Element (or dom4j element, in jboss 4). Since the structure of the element depends on what the mbean expects, the jboss service.dtd can't validate it. Do you know what happens if an element is wrapped in CDATA? Would this fix the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=717680&group_id=22866 ------------------------------------------------------- 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://productguide.itmanagersjournal.com/ _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
