Re: xinclude removed from SCXML specification, but example still references it

Hi Jim,

Thanks for the quick reply.

I think it's not strictly necessary to include language in the
specification regarding xinclude, as this is indeed a facility which
is general to XML documents, and not specific to SCXML. However, in
practice, it might be useful to include a paragraph mentioning it, as
was done in the previous draft, for two reasons.

First, from an SCXML developer perspective, it would be useful to call
out xinclude as the canonical, or best-practice approach to physically
separating and combining SCXML files. This is useful, because
developers may not be aware of xinclude, and may be inclined to use
other approaches to achieve the same result. For example, I believe
that the canonical approach to physically separating docbook documents
is to use entity references:
http://www.sagehill.net/docbookxsl/Db5Entities.html#Db5EntitiesFile

Having come from a docbook background, I was aware of entity
references, but not xinclude, so it was useful to have the SCXML
specification explicitly call this out.

Second, from a specification implementer perspective, while it seems
most XML libraries include support for xinclude, documents must be
explicitly processed using an xinclude processor - they are not
processed transparently at parse-time like XML entities. What this
means is that a specification implementer must remember to activate
the xinclude processor before executing the document, which can be
easily overlooked. By explicitly mentioning xinclude in the
specification, it means scxml implementations may be more likely to
activate xinclude support, which may mean greater regularity across
implementations.

Thanks,

Jake

On Wed, Feb 22, 2012 at 10:56 AM, Jim Barnett
<Jim.Barnett@genesyslab.com> wrote:
> Jake,
>  The group's logic in removing the mention of  xinclude is that it is
> _automatically_ available in any XML-based language. We did explicitly
> call out xinclude in the drafts in which we removed <state src="">, just
> so that readers would have some sense of what to replace src=.. with.
> However we viewed that text as informative and, strictly speaking,
> unnecessary, so we removed it as we got closer to last call.  Does that
> make sense, or do you think that there are other reasons for mentioning
> xinclude?
>
> I'll look into example G.1 and try to clean it up for the next draft.
>
> - Jim
>
> -----Original Message-----
> From: Jacob Beard [mailto:jbeard4@cs.mcgill.ca]
> Sent: Wednesday, February 22, 2012 10:48 AM
> To: www-voice
> Subject: xinclude removed from SCXML specification, but example still
> references it
>
> Hi,
>
> I was just looking over the latest version of the SCXML specification,
> and I noticed that the language regarding referencing external SCXML
> files using xinclude had been removed. It looks like this was removed
> between the following drafts of the specification:
>
> http://www.w3.org/TR/2010/WD-scxml-20100513/
> http://www.w3.org/TR/2010/WD-scxml-20101216/
>
> The only problem is that the Language Overview example in Appendix G.1
> of the current draft appears to continue to make use of xinclude to
> include content from Test2Sub1.xml into Main.scxml:
> http://www.w3.org/TR/scxml/#N118AA
>
> Furthermore, I believe example G.1 may be incorrect, as it appears that
> the XML namespace prefix "xi" is never defined in Main.scxml.
>
> Please let me know if you have any questions. Thanks,
>
> Jake
>

Received on Wednesday, 22 February 2012 17:19:52 UTC