W3C home > Mailing lists > Public > public-xmlhypermedia@w3.org > August 2012

RE: use cases

From: Rushforth, Peter <Peter.Rushforth@NRCan-RNCan.gc.ca>
Date: Mon, 20 Aug 2012 17:37:14 +0000
To: David Carlisle <davidc@nag.co.uk>
CC: "public-xmlhypermedia@w3.org" <public-xmlhypermedia@w3.org>
Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF1AE31907@S-BSC-MBX4.nrn.nrcan.gc.ca>
Hi David,

> >
> > If that didn't come through, I will clean it up.
> >
> It was clear that that was the intention. My point was that 
> is going beyond Liam's proposal (which was a way of avoiding 
> explicitly declaring
> namespaces) to declaring documents that can not be 
> constructed using standard xml+namespace parsing. 

No, that was not the intention of Liam's proposal, and
per his earlier reply, the result of xml+namespace parsing and the
result of xml+automatic namespace processing would, as I see it,
be identical, although one would have to think about the
implications prior to a real-life specification.  Nor was it the
intention of any of my examples, which are meant to illustrate
the use, in particular, of @type and @rel, in a sort-of real-life 

> In the 
> standard xml namespace model (and the XDM model used by 
> XSLT/XPath/Xquery) you can have have unprefixed element names 
> in a namespace, but you can not have unprefixed attribute 
> names in a namespace.
> If you are defining an XML-variant that is not necessarily 
> bad but it needs to be highlighted more strongly, and there 
> would have to be a lot of extra specification saying what to 
> do with such things. 

This is not the intention of either example, although perhaps that
was what was being communicated.  I have re-written the automatic
namespaces example to not use the xml namespace, and I've tried to be
careful to avoid the implication of attributes without a prefix being in
a namespace - but maybe I've missed something:


> For example an XSLT identity 
> transformation would not be able to serialise the document as 
> XML 1.0 so the relevent specifications would need extending.

In the application/xml scenario side of things, an XSLT transformation 
could serialize a xml+autonamespaces document as xml+namespaces (that is
not the "identity" transformation though) or (in XSLT 2)as xml+automatic namespaces
(again not the identity transformation if the linked-to resource was included).

If you ran the identity transform on the xml+auto namespaces version of the main instance document,
you would get the same document back, with the same link(s) to the same auto namespace
document(s), which was/were not affected by the transformation.

> (Or alternatively the neo-xml parser would need to be 
> specified to construct attribute names including the xml 
> prefix, not just in the xml namespace).

Now a document of the NeoXML variety, of course, would need to be identified
somehow, in order to distinguish it from a simple XML 1.0 document.

On the web, that is obviously via the Content-Type header. Off the web, it depends on the

But since the link to the (XML namespace) autonamespace resource is virtual (ie specified by the
NeoXML media type specification but not physically present on the document node, which is naturally impossible anyway), a NeoXML parser could retrieve the appropriate linked resources and if all goes well, assign all nodes to the appropriate namespaces, yielding an XML data model for the application to use, if that was the intent of the NeoXML specification.  Of course, the NeoXML could take the stance of banishing all namespaces with the exception of xml:, which would then imply that the only autonamespace link that might have to be resolved would be the
virtual one to the XML namespace autonamespace representation, which could hopefully be at leasted cached and at best never requested, just understood.

Or, the NeoXML media type specification could take the approach that all names, including colon-names are local, and there are no special meanings to xmlns, xmlns:xxx etc.  Which could yield xml+namespace not-well formed instances, but which would allow treatment of xml+namespace documents by NeoXML applications, at least.  But all that would be up to the NeoXML specification, which is outside the scope of the proposal to add hypermedia vowels to the xml specification.  NeoXML is only an example of a potential use case for the vowels in the XML namespace.

Sorry for the long email.

Received on Monday, 20 August 2012 17:37:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:53 UTC