在架构中定义 XML 元素长度的最佳实践是什么？
在架构中定义 XML 元素长度的最佳实践是什么？您是否应该强类型化元素，以便它们反映数据点最终持久性的字段长度，或者是否应该将它们保留为未定义，以便更好地适应字段长度在持久化时的未来潜在变化（并通过其他地方使用）一个系统）？是否有一个好的经验法则何时执行其中一个而不是另一个，例如对于公开暴露的模式而不是内部使用的强类型？
What are the best practices around defining XML element lengths in schema? Should you strongly type the elements so they reflect the field length of the ultimate persistance for the data point or should you leave them undefined so as to better adapt to potential future changes in the length of the field as it is persisted (and used elsewhere through a system)? Is there a good rule of thumb when to do one versus the other for example strongly type for publicly exposed schemas and not for internally used?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对我来说，你提出的经验法则听起来和其他任何东西一样合理。实际上，这将视具体情况而定，模式的使用者（业务人员、内部和外部开发人员等）需要就其使用达成一致。
面向外部的模式是您与使用该模式的人员（及其计算机系统）之间的合同。所以，是的，您应该尽可能多地使用模式来表达您对传入数据的期望 - 没有什么比得到一个充满 xs:any 元素的模式更糟糕的了！
如果元素的内容大于给定长度将导致错误，则将该信息放入架构中。
然而，在现实世界中，您经常会发现由于某种原因事情需要改变的情况。通过更宽松的限制来妥协内部模式将为您减轻一些痛苦。特别是当将大量外部模式映射到内部模式时，很常见的是由内部模式表示一组超级需求。当然，这确实意味着您的内部错误处理需要更加健壮。
The rule of thumb you have proposed sounds as reasonable as anything else to me. Really this will be a case by case matter, where the consumers of the schema (business people, internal and external developer etc...) need to agree upon its usage.
An externally facing schema is your contract with the people (and their computer systems) using this schema. So yes, you should as much as possible use the schema to express your expectations of incoming data - nothing is worse than being handed a schema which is riddled with xs:any elements!
If having the contents of an element greater than a given length will cause an error, then place that information in the schema.
However, in the real world you will often find situations where things need to change for one reason or another. Having the compromise of internal schemas with looser restrictions will save you some pain down the track. Particulally when mapping lots of external schemas to your internal schema it is very common to have a super set of requirements represented by the internal schema. Though of course that does mean that your internal error handling needs to be more robust.
我认为对字段长度施加限制有两个正当理由。
(a) 该限制在现实世界中确实存在 - 英国的车辆登记始终为 7 个字符
(b) 您希望保护某个软件免受其无法处理的输入数据的影响。个人姓名可以超过 40 个字符，但您的旧应用程序无法处理超过 40 个字符的字符，因此您希望防止出现更长的名称。
不要仅仅因为您认为应该有一个限制就强加一个限制。默认情况下，不应该有。我们不再生活在打孔卡的世界里。
I think there are two valid reasons for imposing a restriction on the length of a field.
(a) the restriction really exists in the real world - vehicle registrations in the UK are always 7 characters
(b) you want to protect a piece of software from input data that it can't handle. Personal names can exceed 40 characters, but you've got a legacy application that can't handle more than that, so you want to prevent longer names reaching it.
Don't impose a limit just because you think there should be one. By default, there shouldn't. We don't live in a world of punched cards any more.