Next in thread →
Next in month →
Re: [dita] DITA XML Schema backwards compatibility and conformance
I think that it would be inappropriate for the normative schemas to be more restrictive than the DTDs since that could indeed break documents. Unless the current Toolkit is already validating those values (I'm pretty sure it's not) it would definitely come as a surprise to many users to have documents fail that did not fail before. If you were to provide <copyryear year="2001, 2007"> , the schemas would return an error at the moment. So it seems the consensus is to remove the gYear as the type in lieu of a string type. I think it would be appropriate to highlight the issue in the 1.2 spec and provide both an option in the Toolkit to validate the values and provide a variant version of the schemas (or some sort of switch) to turn on the validation, for the benefit of those users who do want to prepare for a time when these data types in particular will be validated. In DITA 1.2. I could provide two additional complexTypes for @year, @created, etc. If someone wanted to use those instead of the basic string datatype. If users wanted to the more restrictive datatypes they could specify the more specific <copyryear> using the xsi:type attribute. For example: <copyright year="1999, 2007" xsi:type="copyryear.iso8601.class/> where this particular complexType use xs:gYear for the @year. Kind regards, Eric Eric A. Sirois Staff Software Developer DB2 Universal Database - Information Development DITA Migration and Tools Development IBM Canada Ltd. - Toronto Software Lab Email: Phone:(905) 413-2841 Blue Pages (Internal) "Transparency and accessibility requirements dictate that public information and government transactions avoid depending on technologies that imply or impose a specific product or platform on businesses or citizens" - EU on XML-based office document formats. Eliot Kimber <> 03/31/2008 04:25 PM To cc Subject Re: [dita] DITA XML Schema backwards compatibility and conformance Eric Sirois wrote: > Does it make sense to have a conformance statement for ISO 8601? Should > XSDs help enforce the conformance statement in this case, knowing that > once DTDs validated documents would possibly be invalidated once the are > validated against XDSs? I think that it would be inappropriate for the normative schemas to be more restrictive than the DTDs since that could indeed break documents. Unless the current Toolkit is already validating those values (I'm pretty sure it's not) it would definitely come as a surprise to many users to have documents fail that did not fail before. One thing I will point out is that in some scenarios documents may go from being DTD-validated to being schema validated with no direct user involvement (for example, a CMS might export originally-DTD-based docs as schema-based docs or use schemas for internal validation). That means that a user who authored a DTD-validated document could have that same document fail somewhere else simply because it was rebound to a schema. I think it would be appropriate to highlight the issue in the 1.2 spec and provide both an option in the Toolkit to validate the values and provide a variant version of the schemas (or some sort of switch) to turn on the validation, for the benefit of those users who do want to prepare for a time when these data types in particular will be validated. I think that for interoperability it is appropriate to define a specific data type for dates, in particular, but I think we've already lost the opportunity to be as strict as we might like. Cheers, Eliot -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 610.631.6770 www.reallysi.com www.rsuitecms.com --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Next in thread →
Next in month →