OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] PSVI in the instance



Wayne Steele wrote:

> I see the idea of an instance document "decorated" with the PSVI 
> contributions in an xml 1.0 readable way as having the most traction here.


Agreed.


> I propose the following requirements for such a beast:
> 
> 1. All exposed PSVI items should be accessible to an application through 
> typical "XML 1.0 + namespaces" APIs and techniques.


Yes, this is the starting point and should, IMO, remain the main objective.


> 
> 2. As far as possible, it should be Schema-Language agnostic, to promote 
> interoperability between XML schema, DTDs, Relax, etc.


Yes.


> 
> 3. Every single PSVI item does not need to be exposed this way, only the 
> most useful or important ones ( hit the 80/20 point).


Yes.


> 4. The structure of the instance document should not be excessively altered 
> by the "decorating" it with these PSVI items. Ideally, All elements and 
> attributes in the document would be unchanged, with new infoset 
> contributions added only in the form of "global attributes" (as suggested by 
> ERH ).


I don't think that this is achievable, at least not without compromizing 
  #1.

The main issue is that the content model of attributes is not extensible 
and that we will need extensible content to qualify the attributes in 
the instance document.

We could choose to workaround this by including, ala CSS, a markup 
within attributes something such as: 
psvi:attributes="{foo:(type='xs:interger'; default='5') 
bar:(type='my:type')}" ...

But this would be contrary to "should be accessible to an application 
through typical "XML 1.0 + namespaces" APIs and techniques" which, I 
think is more important.

I think we should relax this requirement and just say something such as:

4. The structure of the instance document should not be excessively 
altered by the "decorating" it with these PSVI items. The string value 
of all elements and attributes in the document must be unchanged, with 
new infoset contributions added only in the form of elements and 
attribute in a specific namespace.

> 
> 
> If these simple requirements are agreeable, the next step is to gain 
> consensus on:
> 
>    Which PSVI information should be exposed in this manner
> 
> and then on
> 
>    How should these infoset decorations be represented in the instance 
> document
> 
> 
> This is mostly orthogonal to the (very useful) idea of a "normalized schema" 
> - the only entanglement is if we wish to have xlinks from an instance 
> document into the normalized schema.


Yes, I think we can keep it orthogonal and that we should keep it 
orthogonal since the normalized schema will probably be much less schema 
agnostic than the document anotations.

I would anyway suggest to make it an objective:

5. These annotations should allow to define links between the instance 
document and an XML representation of the schema(s) used during the 
validation.

Another question we may want to discuss is the level of interoperability 
we may want to reach with DOM Level 3.

Full interoperability would mean that all the information needed by a 
DOM Level 3 parser could be drawn from an annotated document (and vice 
versa that an application could use a DOM Level 3 parser to serialize an 
annotated document).

I am not sure we want to go that far, but it's something worth discussing.

Also, I think we should define a minimum of "administrative stuff" such 
as defining a format for the spec (I would warmly suggest RDDL and can 
host it), finding a name and defining a list of editors (I would be 
happy to be lead editor).

About the name, I have though we could play with "XML, document, 
annotation, with, type, schema, information" and derive names such as 
xawti, xawsi, dawti or dawsi...

All ideas are welcome!

Eric


> 
> -Wayne Steele
> 
> 


-- 
Rendez-vous à Paris pour le Forum XML.
                    http://www.technoforum.fr/Pages/forumXML01/index.html
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org
------------------------------------------------------------------------