Key / Keyref instead of ID / IDRef for limiting scope using Xpaths

[corymosiman12]

No description provided.

[markborkum]

@corymosiman12 Is this referring to https://www.w3.org/TR/xmlschema-1/#declare-key?

[corymosiman12]

Notes from email on 10/29:

Looking into how to constrain scope for IDREFs to appropriate elements. I don’t think it’s possible…but here’s what I found out:

• I believe it is not possible to limit scope using the xs:ID and xs:IDREF attribute types, however, I think it is possible using Identity Constraint Definitions
• Read through Section 3.11.2 here, specifically looking at the example
• This guy speaks a bit more to using key/keyref/unique in favor of ID/IDREF

[corymosiman12]

Hey @markborkum , yes. We wanted to explore the possibilities of this. Have you done this before? Our first step was going to try to implement this on a simpler system (refactoring the XSD), then test it by creating an XML model using it.

Thoughts / advice / warnings :) ?

[markborkum]

@corymosiman12 What is the intent/goal here? Which aspects of the schema would be affected by this issue?

[corymosiman12]

Intent is to improve constraint definition beyond IDs / IDRefs. My understanding of IDs / IDRefs is that they are global to the document, and XML validation only checks / ensures that an IDRef is made to an ID available in the XML doc, but is not doing this based on element 'type' (correct phrasing?). However, the inclusion of key / keyrefs appears to allow for constraining based on xpathing. Original scope of this question is exploratory, mainly to understand how this would affect the schema.

As a first question, have you already implemented this in schematron?

[markborkum]

@corymosiman12 To an extent, yes. https://github.com/pnnl/assetscore-schematron-docs/blob/master/docs/Audit_Template/New_York_City_Energy_Efficiency_Report.xml#L5-L130

[corymosiman12]

I see. @markborkum, do you see benefits to this still then? Major issues?

@nllong thoughts? Continue exploration?

[markborkum]

@corymosiman12 Depending on the goal, key/keyref may be worth exploring.

In the Audit Template Schematron document, we use XPath to validate id/idref links, where both the source and sink of the link are within the same scope. The general form is:

<sch:rule context="Scope[Source]">
  <sch:assert test="Source/@IDref/text() = Sink/@ID/text()">
    element 'Sink' not found within element 'Scope' for element 'Source'
  </sch:assert>
</sch:rule>

[nllong]

Let’s discuss briefly on the call tomorrow. Da: Mark Borkum <notifications@github.com> Risposta: BuildingSync/schema <reply@reply.github.com> Data: martedì novembre 5 2019 12:58 A: BuildingSync/schema <schema@noreply.github.com> Cc: Nicholas Long <Nicholas.Long@nrel.gov>, Mention <mention@noreply.github.com> Oggetto: Re: [BuildingSync/schema] Key / Keyref instead of ID / IDRef for limiting scope using Xpaths (#159) @corymosiman12<https://github.com/corymosiman12> Depending on the goal, key/keyref may be worth exploring. In the Audit Template Schematron document, we use XPath to validate id/idref links, where both the source and sink of the link are within the same scope. The general form is: <sch:rule context="Scope[Source]"> <sch:assert test="Source/@IDref/text() = Sink/@ID/text()"> element 'Sink' not found within element 'Scope' for element 'Source' </sch:assert> </sch:rule> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#159?email_source=notifications&email_token=AAORVGRI7XIR7PUMTK2ZJULQSHF6BA5CNFSM4JJGKUS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDEDYOQ#issuecomment-549993530>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAORVGULLBMWRXLDHAOVDQLQSHF6BANCNFSM4JJGKUSQ>.

[corymosiman12]

@markborkum I believe you said you looked into this more and found it dissatisfying - can you provide a recap / explanation to close out the discussion on this and then we can close this issue, as I believe we WILL NOT be going down this road?

[markborkum]

@corymosiman12 The main issue is the association of auc:Section[auc:SectionType='Whole building'] child elements with auc:Systems child elements. For example, the association of auc:ExteriorFloorId with auc:ExteriorFloor, which requires [at least] 3 rules:

1. If an auc:ExteriorFloorId element exists, then the referenced auc:ExteriorFloor element must exist.
2. If an auc:ExteriorFloor element exists, then an auc:ExteriorFloorId element that references it must exist.
3. Every auc:ExteriorFloor must be associated with exactly one auc:ExteriorFloorId.

Besides the difficulty of expressing 1, 2 and 3, there is also the issue that key/keyref XPaths are "restricted" to only parent/child syntax. They cannot, for example, use filter expressions. Hence, it is not possible to use key/keyref to refer to auc:Section[auc:SectionType='Whole building'] elements.

[corymosiman12]

I see - thanks. Closing this.