Proposals of master file referencing concepts with xml-model

[nkutsche]

During my discussions with @kosek and George Bina on the XML Prague 2020 we outlined three concepts how master file references could be expressed, extending or adapting the xml-model PI.

Note: The naming of the below proposed structures (PI name, pseudo-attribute or namespace) are just raw drafts or even placeholder. It would be another issue to find good and intuitive names for the new structures.

Note 2: The order of the proposals is not an indication of evaluation, but has a semantic logic: from the closest to the farthest away from the current specification.

As an own schematype namespace

Introduces a new schematype namespace that indicats that the referenced file in href is not a schema but the master file.

The master file is used to detect the associated schema(s). Multiple master files could be referenced by multiple xml-model PIs. Other schema associations can be added by additional xml-model PIs as before.

Example

<?xml-model href="path/to/master/file.xml" type="application/xml" schematypens="http://www.some-ns-url.com/indicating/that/this/is/a/pointer/to/a/master/file"?>

Positives

• This is very close to the current specification.
• Upwards and downwards compatible, as the pseudo-attribute schematypens of the current specification is extensible by other values.

Negatives

• There is a semantic gap between validation language reference and master file reference. We maybe misuse the same structure for a different purpose.
• The xml-model PI needs to be parsed to detect module files.

As an additional pseudo attribute

Introduces a new pseudo-attribute which references the master file. The xml-model PI with such pseudo attribute may have type, charset or title, but no other pseudo attribute.

The master file is used to detect the associated schema(s). Multiple master files could be referenced by multiple xml-model PIs or by a whitespace separated list of file references. Other schema associations can be added by additional xml-model PIs as before.

Example

<?xml-model master-href="path/to/master/file.xml"?>

Positives

• Close to the current specification
• Clear distinction between master file and schema reference

Negatives

• The xml-model PI needs to be parsed to detect module files.
• More logic in the xml-model PI needs to be respected (e.g. do not use master-herf and href in the same PI).

As an own PI

Introduces a new PI e.g. xml-master which references with a pseudo-attribute the master file.

The master file is used to detect the associated schema(s). Multiple master files could be referenced by multiple xml-master PIs or by a whitespace separated list of file references. Other schema associations can be added by additional xml-model PIs as before.

Example

<?xml-master href="path/to/master/file.xml"?>

Positives

• Clear distinction between master and schema reference.
• Simple identification of module files.
• The new PI could include more informations about the used embedding logic (e.g. XInlcude, XSLT, etc.).

Negatives

• As PIs have no namespaces, new names could lead to name conflicts.
• This proposal is the furthest from the current specification

[kosek]

Perhaps we should first discuss whether "master file" is orthogonal to associated schemas or not. What makes sense and what would user expect?

• Should different schema be used if validation starts at master file than on individual files?
• If validation starts on a master file should locally specified schema override schemas associated on master file?

To me it looks that most likely answer to these questions would be no so the latest Nico's proposal seems as a completely sufficient. As processing instructions starting with xml- are reserved there is no big risk of naming clashes. We can just contact someone at W3C and say that we are taking xml-something. Perhaps we would need to create spec for such new PI at W3C using Community Group process.

If we decide this route I suggest using PI that relates master file to xml-model, perhaps

<?xml-model-root href="path/to/master/file.xml"?>

[nkutsche]

Actually after re-thinking, I'm not sure if it would make sense to allow master file references in combination with individual schema associations.

What would such a combination mean? I just see two options:

1. Case: schema associations in module files applies also for the master file.
   -> In this case the master file would be valid or not depending on which module file is validated.
2. Case: schema associations in module files applies only for them self.
   -> In this case the master file could be valid, though the module files wouldn't be.

Both cases would lead to unstable validation results.

As consequence I would not permit to have both: master file reference and schema association.

I also don't see real use cases for such a validation designs, do you?

By the way: the current Oxygen master file implementation ignores the schema associations of the module files when a master file is validated.

Furthermore, I would also expect the following rules:

• A module file can refer to more than one master file.
• It should be allowed, that a referred master file has no own schema associations. In this case the validation engine needs to detect the schema by it self.
• If a module file points to a master file the master file have to include this module file. Otherwise it should be an error.

As processing instructions starting with xml- are reserved there is no big risk of naming clashes.

Where is this specified? And which tools are respecting this? If I start in Oxygen an XML document with <?xml-foo?> there is no error, should it? Only <?xml?> is forbidden.

But don't get me wrong. I can deal with a new PI. I also don't see a big risk of name conflicts - at least not bigger than it was when the <?xml-model?> PI itself was introduced. Beside of this, I agree with you, that it would be the best solution.

[kosek]

I also don't see real use cases for such a validation designs, do you?

No, but if we overload <?xml-model?> with master file functionality then some people could use this in a very creative ways. ;-)

A module file can refer to more than one master file.

OK. What is expectation then? Run validation against all master files?
Should we allow additional title pseudoattribute to allow naming of master files and selection in UI?

It should be allowed, that a referred master file has no own schema associations. In this case the validation engine needs to detect the schema by it self.

OK

If a module file points to a master file the master file have to include this module file. Otherwise it should be an error.

What about more complex scenarios master -> module -> submodule. If submodule references master should this be error as inclusion is indirect via submodule? I don't think so.

As processing instructions starting with xml- are reserved there is no big risk of naming clashes.

Where is this specified? And which tools are respecting this? If I start in Oxygen an XML document with <?xml-foo?> there is no error, should it? Only <?xml?> is forbidden.

See https://www.w3.org/XML/xml-V10-5e-errata -- we have lifted some restrictions on names starting with "xml" in XML Core WG. But for PI some limitations have been retained as namespaces can't be used in PI targets.

Using <?xml...?> is fine (but only since 2013) and tools shouldn't be reporting any errors. However if you are introducing new processing instruction starting with `<?xml then you should get approval from W3C. Perhaps creating community group that will publish specification for this new PI should be enough.

But don't get me wrong. I can deal with a new PI. I also don't see a big risk of name conflicts - at least not bigger than it was when the PI itself was introduced. Beside of this, I agree with you, that it would be the best solution.

So do you agree that introducing a new separate PI named <?xml-model-root is the best way to do this?

[nkutsche]

I also don't see real use cases for such a validation designs, do you?

No, but if we overload with master file functionality then some people could use > this in a very creative ways. ;-)

Well, sure. I think the question is: does it give more freedom for creativity or leads it to more confusions if someone makes something he/she didn't want to do.

A module file can refer to more than one master file.

OK. What is expectation then? Run validation against all master files?

Yes, at least this makes the current implementation of the Oxygen. And I think it makes sense.

Should we allow additional title pseudoattribute to allow naming of master files and selection in UI?

That's a good idea. It would be optional, right?

If a module file points to a master file the master file have to include this module file. Otherwise it should be an error.

What about more complex scenarios master -> module -> submodule. If submodule references master should this be error as inclusion is indirect via submodule? I don't think so.

Let me be more precise. I meant: If a module file points to a master file, the master file have to include this module file directly or indirectly. Otherwise it should be an error. Better?

By the way, speaking about the master -> module -> submodule scenarios: It should be allowed that the submodule file points to the module as a master file which points to the master file. There should be no differences to the case that the submodule points directly to the master file, should it?

See https://www.w3.org/XML/xml-V10-5e-errata -- we have lifted some restrictions on names starting with "xml" in XML Core WG. But for PI some limitations have been retained as namespaces can't be used in PI targets.

Okay, I never saw this errata and I'm a bit confused that these changes is not be merged with the original document. So it is very well hidden, but not my business and not subject of this issue.

So do you agree that introducing a new separate PI named <?xml-model-root is the best way to do this?

Yes I agree that an extra PI is the most clean way. I'm not sure if we brainstormed enough for the name. So let me drop some possible names:

<?xml-model-root
<?xml-model-master
<?xml-model-context
<?xml-model-ref

Any others?

[kosek]

Should we allow additional title pseudoattribute to allow naming of master files and selection in UI?

That's a good idea. It would be optional, right?

yes, optional

What about more complex scenarios master -> module -> submodule. If submodule references master should this be error as inclusion is indirect via submodule? I don't think so.

Let me be more precise. I meant: If a module file points to a master file, the master file have to include this module file directly or indirectly. Otherwise it should be an error. Better?

ok

So do you agree that introducing a new separate PI named <?xml-model-root is the best way to do this?
Yes I agree that an extra PI is the most clean way. I'm not sure if we brainstormed enough for the name. So let me drop some possible names:
<?xml-model-root
<?xml-model-master

We should not consider this name as we will be smashed by social justice wariors if we use it. ;-)

<?xml-model-context

This name sounds reasonable.

<?xml-model-ref

This looks misleading to me. I would think this is reference to xml-model not instance that should be validated by this xml-model.

So I see two candidates now -- <?xml-model-root and <?xml-model-context. Perhaps we should discuss this in a more wider audience now, maybe you can post proposal for this new PI on xml-dev mailing list. I don't think we have something better right now.

[martian-a]

For context, could you expand on what you mean by "master file"? How would you define the concept of a master file? How would you identify that this relationship exists between two files (master and subordinate) and how would you determine which should be identified as the master file and which the subordinate file? What is the intended effect of expressing this relationship?