Stephan: Can we define our own type whose constraints are validated by the schema validator? If we define our own 'qualified name' will we be able to define it as such that the schema validator tests for the existence of used namespaces?

Stephan: Can we define our own type whose constraints are validated by the schema validator? If we define our own 'qualified name' will we be able to define it as such that the schema validator tests for the existence of used namespaces?

ID/IDREF

Contraints

Values of type ID must match the Name production. A name must not appear more than once in an XML document as a value of this type; i.e., ID values must uniquely identify the elements which bear them.

Validity constraint: One ID per Element Type

No element type may have more than one ID attribute specified.

Validity constraint: ID Attribute Default

An ID attribute must have a declared default of #IMPLIED or #REQUIRED.

Validity constraint: IDREF

Values of type IDREF must match the Name production, and values of type IDREFS must match Names; each Name must match the value of an ID attribute on some element in the XML document; i.e. IDREF values must match the value of some ID attribute.

Advantages

ID recognized by XML tools as an identifier type

There is a uniqueness constraint on prov:id values (scope global to document)

IDREF recognized by XML tools as a reference to an identified element

A prov:ref must match the prov:id of some identified element in the document

Disadvantages

lexical space is the same as the unqualified XML name (known as the xs:NCName datatype)

XLink 1.1's XLink Attribute Usage Patterns indicates that the xlink syntax could be even simpler where the xlink:type="simple" is optional when xlink:href is used. So the prov:entity link could be reduced to:

The use of IDREF for local references could be replaced uniformly with XLinks to local IDs:

<prov:generatedEntity xlink:href="#e2"/>

Analysis

ID/IDREF

Stephan: ID and IDREF are the native way to use identifiers in XML but introduce too many restrictions (no qnames, URIs, and identified records must exist in local document) for this to be an adopted solution by PROV-XML. I do not at this time recommend using ID/IDREF

QName

Stephan: While QName does have a few restrictions the PROV-DM Qualified Name does not ( "ex:001" is not allowed) I think it is the closest native-XML type to the PROV-DM qualified name. QName is understood by schema validators to be an optional namespace followed by a local name and validators will test for the existence a namespace defined in a QName value. I think this is a good restriction and matches the PROV-DM Qualified Name definition which states that PROV-DM Qualified Names can be mapped into an IRI by concatenating the IRI associated with the prefix and the local part.. At this time I recommend staying with QName.

anyURI

Stephan: anyURI values are not validated by parsers so they can contain pretty much anything. This means there is no guarantee they are a valid URI. Namespaces used in prov:id values are not recognized as namespaces and therefore their existence will not be tested for. Undefined namespaces will make it difficult to expand the identifier value into a IRI as stated in the PROV-DM Qualified Name definition. I do not at this time recommend using anyURI.

ID/IDREF, XLink, and XPointer

Stephan: TODO

Custom type

Stephan: Can we define our own type whose constraints are validated by the schema validator? If we define our own 'qualified name' will we be able to define it as such that the schema validator tests for the existence of used namespaces?