parser for xml-data?

[Ron Bourret]

Charles Frankston wrote:

> rbourret at dvs1.informatik.tu-darmstadt.de wrote:
> 
> > One possibility is that something in your XML document, such 
> > as an attribute at 
> > the root, would refer to the XML document containing the 
> > XML-Data definition of 
> > your grammar:
> > 
> > <MyRoot Schema="MyRootSchema.xml">
> >    ...
> > 
> > Another (uglier) possibility is that you use namespaces: the 
> > XML-Data namespace 
> > and the namespace your XML-Data data defines.  I haven't 
> > looked enough at either 
> > the namespaces or XML-Data specs to be sure how this would 
> > work, but it seems 
> > the object structure might be something like:
> > 
> > ...
> > 
> 
> Namespaces are intended to what you're asking for.  I.e.:
> 
> 	<?xml:namespace ns="urn:mycompany:MyRootSchema"
> 	      prefix="myschema" src="http://something/MyRootSchema.xml"?>
> 
> I don't see why using a standardized solution is uglier than inventing your
> own namespace tag.  This does require you to namespace qualify your instance
> information.  I.e. the tags that come from the urn:mycompany:MyRootSchema
> would be something like <myschema:xyz>.

It looked ugly to me not because of using namespaces, but because I couldn't 
figure out which namespace owned the root tag.  My first guess was something 
like this, which I think is a bit ugly, not to mention invalid:

   Root object
      XML-Data root
         XML-data data...
      Your data root
         Your data...

I hadn't thought of your solution because I assumed namespace declarations 
pointed to DTDs, not to any general schema mechanism.  Several other questions / 
comments about namespaces:

1) How do you use multiple namespaces in a valid document?  That is, if you have 
two separate DTDs (schemas), neither of which references elements in the other, 
how do you build a single valid document with both of them?  Elements from the 
first DTD can't nest inside elements from the second DTD (because they aren't in 
the second DTD's grammar) and vice versa.  The example in section 3.1 of the 
namespaces spec is well-formed, but the spec doesn't explain how it can be 
valid.  Presumably, it doesn't match any of the DTDs presented as namespaces.

2) The src attribute in your namespace declaration does not point to a DTD; it 
points to an XML-Data file.  While the namespace spec does not prohibit this, I 
had simply assumed that the schema would be a DTD.  It would be nice if the 
namespace spec clarified that it does not impose any rules on the format of a 
namespace schema.  This is important for validating parsers, as it means that 
namespace declarations are dependent on the parser's ability to read the  
particular schema format that is used.  (And if a parser can read multiple 
schema formats, how does it know which one to use?)

3) Why is production [1] in the namespace spec:

  [1] NamespacePI ::= '<?xml:namespace' (S (PrefixDef | NSDef | SrcDef))+ '?>'

instead of:

  [1] NamespacePI ::= '<?xml:namespace' S PrefixDef S NSDef (S SrcDef)? '?>'

Is the ambiguity of the production, which needs to be qualified with the  
Required Parts constraint, worth the flexibility in the order of PrefixDef, 
NSDef, and SrcDef?  My opinion is no.

-- Ron Bourret

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)