search

BuildingSync / schema

BuildingSync® Schema
https://buildingsync.net
Other
23 stars 22 forks source link

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

Closed corymosiman12 closed 4 years ago

markborkum commented 4 years ago

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

corymosiman12 commented 4 years ago

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:

corymosiman12 commented 4 years ago

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 commented 4 years ago

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

corymosiman12 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

@nllong thoughts? Continue exploration?

markborkum commented 4 years ago

@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 commented 4 years ago

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)

@corymosiman12https://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:

element 'Sink' not found within element 'Scope' for element 'Source' — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
corymosiman12 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

I see - thanks. Closing this.