Xsd Tridion“复杂架构”升级问题，带有“xlink:”和属性“ref”

我们正在升级一个目前用于将内容从第三方系统导入Tridion的应用程序。当前的CMS是Tridion2009，新实例将是Tridion2011 SP1HR1

我们遇到的挑战是我们无法得到一个复杂的模式来验证。我已经包括了一个2009年的工作示例，如下所示，这在SDL Tridion 2009中得到了验证。然而，当我试图通过Tridion2011中的CME创建相同的模式时，我在选择“验证”时出错，表明

“ref”属性的值无效='xlink:href'是一个 “ref”属性的值无效

我花了一些时间阅读这是一个传下来的复杂模式，已经有相当多的内容被压在上面了！你相信吗？我们不能仅仅停留在一个名称和类型中，或者以某种方式在本地定义这个“全局”参数——如果可以的话——这不是“不太好”的做法吗？。我相信这可以通过更新XML来解决，但这是我们无法修改的

任何评论/指点都会很棒！ 谢谢

更新： 为了继续，我们对xsd模式进行了更改：

<xs:attribute ref="xlink:href" use="required"/>
<xs:attribute ref="xlink:title" use="optional"/>

到

这实际上来自2011版的cm_lnk.xsd。 ref实际上应该是对xlink:href属性的引用，因此这可能仍然是不正确的-是否有人知道我们可能测试/监视的此更改存在任何陷阱

从CS更新 CS已表示，他们将与研发部一起对此进行调查，似乎已同意该方案在2009年是有效的，但现在在2011年无效。票证已经关闭，但我们有兴趣继续跟进，看看这是在2013年解决的还是作为一种不同的方法被接受的？

使用

而不是

很好，因为您打算无论如何引用cm_lnk.xsd，这只是意味着如果cm_lnk.xsd会改变，您也应该相应地改变模式。但这只是理论上的，因为cm_lnk.xsd模式永远不会改变它的定义

更有趣的是，您在2009版中提到了这一点，这表明2011版似乎无法处理您的导入

---

正如多米尼克已经提到的，我确实会为此提出一张CS票，这样它就可以被查看了。您的解决方案非常有效，但报告缺陷并允许在将来的版本中修复这些缺陷总是好的。

cm_lnk.xsd的架构位置正确吗？您好，Dominic，我尝试在Tridion 2009实例中不使用schemaLocation=cm_lnk.xsd，但它仍然有效-这是Tridion CME验证模式的一方。在Tridion 2011中，xlink命名空间通过“实例”导入。如果你添加这个而不是cm_lnk.xsd导入，会有帮助吗？恐怕不会。我将xsd:更改为xs:。我确实尝试过schemaLocation，如果没有其他东西的话，标记会自动关闭以进行测试。奇怪的是，从ref=到name=&type=的更改验证了-这是与Tridion XSD内联的，因此可能ref=只是不受支持，至少在计划的模式的上下文发起者中不受支持。另外-您能否确认您在哪里找到xlink名称空间导入的更新？我可以作为跨架构移动的一部分进行更新，并使用相同的文档/方法确保我们也检查其他项目。谢谢你对这个问题的回答！我的理解是ref需要引用范围内的类型。因此，我们寻找失败的导入。由于schemaLocation属性似乎不相关，我们必须假设该位置是由Tridion在代码中提供的。也许您应该提出一个CS问题，询问定位模式的算法，或者是否有跟踪定位过程的方法。您是否曾在2011年尝试创建一个全新的模式，并检查它如何定位xlink定义？我就是这么做的。非常感谢巴特和多米尼克。我将通过Tridion支持部门报告问题，我们可以继续实施解决方案。问题已报告给CS，响应。。。感谢您的反馈-因为它在2009年是有效的模式，现在在2011年无效，我们将就此联系研发部，以了解是否需要在2011年或2013年版本中解决其他问题。

<xs:attribute ref="xlink:href" use="required"/>
<xs:attribute ref="xlink:title" use="optional"/>

<xs:attribute name="href" type="xs:anyURI" use="required"/>
<xs:attribute name="title" type="xs:string" use="optional"/>