Oxygen XML Forum

The following suggestion would probably only cause minor implementation work , but a big improvement in Schema support when it comes to editing real-world document.

I actually checked for this feature again in v7 and it is seems to not be there.

I hope Oxygen is listening

FEATURE REQUEST:

Please, provide tag-insight and attribute-insight (completion) support in the following situation:

- Multiple namespaces are defined, document contains tags from these namespaces and, possibly, no namespace.
- A schema is known for some or all of those namespaces, maybe incl. the no namespace.
- The root tag may or may not belong to those schemata.
- Any single schema may be violated somewhere because "alien" elements and attributes are merged -- however, filtering all nodes of A SINGLE NAMESPACE would result in a valid document.
- Of course, completion is not expected for elements outside any schema.
- Of course, ID, IFREF is still possible but may be dropped in this situation.
- Consider attributes WITH namespace as an attribute w/o namespace within the schema defined by the namespace.
- Complete a namespace: entry not valid at some position by all available nodes within the corresponding schema.


IMPLEMENTATION NOTE:

This should be trivial to implement. Because EVERY element/attribute may easily be looked up in its schema (using its namespace), the completion can be done the same way as usual. As it comes to siblings:
- If you know the valid parent: Just proceed as usual.
- You dont: Just propose all nodes from the corresponding namespace which cannot be excluded.


REASON:

In real-world XML editing out there, the following is typically required:
(1) A document is written according to one schema (or no schema): Oxygen can do.
(2) The document is augmented to "include" fragmemts from another document: Oxygen must learn to support the included schema.
(3) The document is further augmented by added "annotations", either single elements or attributes: Oxygen must learn to support the schema of "alien" namespace elements/attributes.

Toy-world users of (1) may already use (and buy...) Oxygen, but users needing (2) or (3) wont buy.

Normally, editing of an XSLT document already requires (2), XSLT with inclusion of XHTML. You have recognized your failure and have added hard-wired support for this situation by adding a dialog to specify "inclusion schema for xslt". What a hack...

Just do it right and I'll ready to buy.

Regards,
Falk

Dear Falk,

oXygen supports validation against NRL (Namespace Routing Language) schemas. NRL is exactly for defining different parts of the document to be validated against different schemas. Your example is only a particular situation for NRL when the document partitions are determined only based on the namespace. As I said, currently we support only validation against an NRL schema but we plan to extend the support also to content completion in the future and that should add support for handling the situations you described.

Best Regards,
George

george wrote:oXygen supports validation against NRL (Namespace Routing Language) schemas.

Thank You for pointing me to this. Interesting, esp. how James Clark continues to pinpoint the failures of W3C when it comes to the real world...

george wrote:NRL is exactly for defining different parts of the document to be validated against different schemas.

Yeah.

george wrote:Your example is only a particular situation for NRL when the document partitions are determined only based on the namespace.

However, it is the 90% situation in which you absolutely need NO NRL to support the features I described. I guarantee you that no NRL schema will be written by users who want to edit a non-trivial document -- and you want to sell, don't you?

In the 90% situation (1:1 schema:namespace), it is plain ok to register the schema locations in oxygen's location dialog which does already exist. This is important as there is only up to one xsi:location attribute in the root node.

Therefore, all what I said should work WITHOUT an NRL schema around (oxygen could use and create it internally in a hidden manner, if this helps).

george wrote:As I said, currently we support only validation against an NRL schema but we plan to extend the support also to content completion in the future

As I said, content completion with mixed namespaces should work "out of the box" w/o having to create an NRL schema.

george wrote:that should add support for handling the situations you described.

I have observed again and again, that detailed feature specifications I have made in the past (notably to the YourKit profiler team) have not been fully understood or have not been forwarded to the developers in charge. This has led to product releases with disappointing feature implementions (same work, no market impact). Please make sure that your expression "that should add support for handling the situations you described" actually reads "that will add support for handling the situations you described." Otherwise, it won't...