[ http://jira.jboss.com/jira/browse/JBAS-460?page=history ]
Adrian Brock updated JBAS-460:
------------------------------
Component: JMX
> Make *-service.xml 'validable'
> ------------------------------
>
> Key: JBAS-460
> URL: http://jira.jboss.com/jira/browse/JBAS-460
> Project: JBoss Application Server
> Type: Feature Request
> Components: JMX
> Versions: JBossAS-4.0.0 Final
> Reporter: SourceForge User
> Assignee: Scott M Stark
> Priority: Minor
>
>
> SourceForge Submitter: hanming .
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development
