gmane.text.xml.devel

Re: Common documentation standard across multiple XML schemas

G. Ken Holman — 2013-05-16T13:19:38

Thank you!  I have just tweaked the wording to see if this helps.


No, as I haven't yet had the need.


Forgive me for giving you the impression the XSLStyle scaffolding 
itself would be good for XSD ... I was simply trying to convey the 
architectural decision I made of standardizing a documentation 
scaffolding but not constraining the user's choice of vocabulary 
within the documentation.

One private flavour of XSLStyle stylesheets was used for US 
intelligence stylesheet documentation:  the stylesheets were 
formatting the vocabulary to produce PDF and HTML of intelligence 
documents, and I used the vocabulary itself to document the 
vocabulary's stylesheets.  This meant there was a recursive 
invocation of the stylesheets to produce the HTML documentation of themselves.

The other developers didn't need to learn DocBook ... they already 
knew the vocabulary we were working with.  The scaffolding approach 
turned out to be amazingly adaptable.

So it was just the approach I was trying to share with yo

Re: Common documentation standard across multiple XML schemas

George Cristian Bina — 2013-05-16T11:22:43

Hi Lech,

oXygen XML Editor provides support for generating documentation for XSLT 
and XSD - not yet for RNG I am afraid.
However, for XSLT the main idea was to document the structure itself and 
the user documentation can be written in different annotation formats: 
we define also an oXygen specific format that provides highlighting and 
links but we support also other languages including XSLStyle, a DocBook 
subset, a DITA subset, etc.
 From our experience with generating documentation the user 
documentation is a secondary concern and that can easily take different 
languages - the more difficult part is getting the 
schema/stylesheet/etc. structure and split that, generate diagrams where 
needed, link between different components, etc.

Here you can find additional information and some examples of how the 
generated documentation looks like:
*XSLT*
http://www.oxygenxml.com/xml_editor/xslt_documentation.html
DocBook to XHTML: 
http://www.oxygenxml.com/samples/xslt-documentation/docbook/docbook.html
DITA

Re: Common documentation standard across multiple XML schemas

Lech Rzedzicki — 2013-05-16T09:36:17

Thank you Ken - this is looking really good and not sure how how I missed
it - I will definitely give it a go.
May I suggest that you rephrase some of your description on
http://CraneSoftwrights.com/**resources/#xslstyle<http://cranesoftwrights.com/resources/#xslstyle>
so
that search engines pick up on "XSL documentation" keywords - in spite of
being very relevant, your page doesn't show up in top Google results.
Just curious, have you used this markup for anything other than XSL?
In general do you think that this is a good idea? Like I said I have some
reservations due to the fact that you're documenting different concepts in
Schemas and in XSL...

Lech


On 15 May 2013 20:13, G. Ken Holman <gkholman< at >cranesoftwrights.com> wrote:

Re: Recommended way to extend Schematron?

Dimitre Novatchev — 2013-05-16T04:45:51

You can use FXSL -- it provides trigonometric functions and is written
in pure XSLT (1.0 and 2.0).

On Tue, May 7, 2013 at 11:02 AM, Costello, Roger L. <costello< at >mitre.org> wrote:



--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's wor

Re: Recommended way to extend Schematron?

Rick Jelliffe — 2013-05-16T04:34:17

People have indeed used the extension functions that vendors provide (such
as functions in java: namespace)

I have seen people write xslt functions and embed them.

The cleanest way is to use a simple web service. E.g
   document(" http://localhost/maths?get-sin=0.6")
returning a single element with the result. More appealing if the
calculations are complex or cacheable of course. That is cross platform.

For assertion purposes, it may be that rather than testing
sin(X) > 0.5
it might better to test with arcsin 0.5
X > -30 and X < 30
or whatever. Do the lookup at coding time.

cheers
Rick
On May 8, 2013 4:02 AM, "Costello, Roger L." <costello< at >mitre.org> wrote:

Re: Common documentation standard across multiple XML schemas

G. Ken Holman — 2013-05-15T19:13:37

In my XSLStyle approach for documenting XSLT stylesheets I 
standardized scaffolding and then offer the user to plug in under the 
scaffolding one of three vocabularies for the actual 
documentation:  DocBook, DITA or XHTML.

   http://CraneSoftwrights.com/resources/#xslstyle

I then have three XSLStyle stylesheets that have a common fragment to 
handle the scaffolding and tailored fragments for each of the three 
documentation vocabularies.  This produces a JavaDoc-like 
result.  One of my clients posted the stylesheet documentation of a 
system I wrote here:

   http://sportsmlt.svn.sourceforge.net/viewvc/sportsmlt/2.0/sportsmlt2.html

The XSLT with the embedded constructs is here:

http://sportsmlt.svn.sourceforge.net/viewvc/sportsmlt/2.0/sportsmlt2.xsl?view=markup

XSLT allows non-XSLT elements as children of the document element, 
and so the XSLStyle scaffolding lives there quite innocuously.  The 
scaffolding provides structure and section titling and business rules 
for validating properly-written do

Common documentation standard across multiple XML schemas

Lech Rzedzicki — 2013-05-15T18:59:27

We're considering developing in-house markup standard or a best practice
for inline XML documentation.
This would be used on XSL, RNG and XML instance documents in various
proprietary schemas.
Do you see an advantage in developing markup that would be consistent
across multiple XML schemas?
It would mean writing just one XSL to say produce HTML output of that
documentation, but as schema and stylesheets need to document different
things, I wonder how it might work in practice?
Has anyone taken on a similar initiative in the past?
What do you use to document your XML, do you just use XML comments?
If so do you follow some convention inside a'la javadoc?

If you were to recommend different documentation markup per schema - one
for RNG/RNC, one for XSL etc, what would you recommend?

Lech

Re: Recommended way to extend Schematron?

Jim Melton — 2013-05-08T20:37:19

Roger,

Being only slightly snarky (in my first 
suggestion), I can suggest three possibilities that may be worth consideration:

1) XQuery 1.0 is computationally complete and can 
be used to write functions that perform those 
calculations; under several implementations, it 
is possible to invoke those functions from XPath 2.0 expressions.

2) XPath 3.0 ("Coming Soon to a Theater Near 
You") has those particular functions built in, 
as well as even more mechanisms for defining them 
natively; there are several implementations of 
XPath 3.0 (and XQuery 3.0), even though we're 
still at the tail-end of the Candidate Recommendation stage.

3) EXPath is a community effort that has defined 
a number of useful functions to be invoked (using 
a different namespace than the standardized "fn:" 
namespace) from XPath; many XPath 2.0 
implementations recognize that namespace.

Hope this helps,
    Jim


At 5/7/2013 12:02 PM, Costello, Roger L. wrote:

=================================================================

Major updates to MicroXML articles

Uche Ogbuji — 2013-05-07T20:56:27

Hi folks.  Today IBM published updated versions of my introductory articles
on MicroXML

http://www.ibm.com/developerworks/library/x-microxml1/

Many changes throughout, but for example based on the current draft in
which namespace are completely banned.

http://www.ibm.com/developerworks/library/x-microxml2/index.html

Many changes throughout, and in particular uses James's microxml-js for
code examples rather John's MicroLark.

Re: Recommended way to extend Schematron?

George Cristian Bina — 2013-05-07T19:55:52

Hi Roger,

Here there are a couple of additional possibilities:

Skeleton and also our oXygen's Skeleton-based Schematron implementation 
have a parameter that allows foreign elements - that can be used to pass 
over XSLT code from your Schematron file to the generated stylesheet, 
for example if you define an xsl:function then that will go in the 
generated XSLT code and you should be able to call that from your XPath 
expressions.

Another option will be to handle a new queryBinding in the Schematron 
implementation that you use, for example the value for that can be xslt3 
to indicate that you want to use that and then you can access functions 
that are defined in XSLT 3.

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

On 5/7/13 9:02 PM, Costello, Roger L. wrote:

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML impleme

Re: Recommended way to extend Schematron?

Simon St.Laurent — 2013-05-07T18:59:22

EXSLT used to be my answer, though I don't know if it's available in 
your context.

<http://www.exslt.org/math/>

Thanks,

RE: Recommended way to extend Schematron?

Rushforth, Peter — 2013-05-07T18:54:47

Hi Roger,

I recently had to do something similar.  I used the ExtensionFunction interface in saxon to define extensions based on java libraries, and was able to call them from XML schema 1.1 assert elements.  I was wondering about using "pure xpath" but I could not figure out a way to do the processing I needed to do on input coordinate lists.  So saxon extension functions helped me there.

Cheers,
Peter Rushforth
________________________________
From: Costello, Roger L. [costello< at >mitre.org]
Sent: May 7, 2013 2:02 PM
To: xml-dev< at >lists.xml.org
Subject: [xml-dev] Recommended way to extend Schematron?

Hi Folks,

Suppose my Schematron assertions need to do some math calculations – cosine, sine, tangent, etc.

I am using XPath 2.0 in my Schematron assertions. But XPath 2.0 doesn’t support functions for cosine, sine, tangent, etc.

What is the recommended way to extend Schematron?

/Roger

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated lis

Recommended way to extend Schematron?

Costello, Roger L. — 2013-05-07T18:02:09

Hi Folks,

Suppose my Schematron assertions need to do some math calculations - cosine, sine, tangent, etc.

I am using XPath 2.0 in my Schematron assertions. But XPath 2.0 doesn't support functions for cosine, sine, tangent, etc.

What is the recommended way to extend Schematron?

/Roger

Re: Musings on the fundamental nature of data

adasal — 2013-05-06T12:37:58

Kurt,
What a helpful and insightful post. Thank you.
For my own claa model itself is simply a mechanism for imposing a working
order upon reality in order to manipulate that reality in some
wayrification:-


The emphasis you are making is on a distinction between the linear and
non-linear.
How ever some concepts are intrinsically difficult to delimit (at what
point in cloud cover are we justified in saying it is cloudy?)
Whereas others we would apply all round, for instance water to an atom,
molecule, the solid, liquid and gas. Concept use per se, and so certain
forms of classification, does not seem to always hinge on the
linear/non-linear distinction.


Which, of course, is very complicated because the abstraction is not just
sequence but must include a notion of time interval as a relative quantity
(very difficult to establish in relation to thresholds I should think).
So here we are interested in when one thing ceases to continue to be that
sort of 'thing' and starts to be another sort of 'thing'. It has

Pseudo validation to extract Schematic information

Ihe Onwuka — 2013-05-06T11:16:12

I would like to tag an instance to  identifying occurences of schema
aggregates (e.g groups or complexTypes) within the instance.

I haven't got a schema to start with so plan A is to generate one with
Examplotron and then see if I can tag the instance with whatever aggregates
I get from it.

The big idea is pattern detection and for starters I take as  patterns
things that equate to some sort of schema aggregate.

Thought best to ask to see if I can get a head start on this. Happy to
follow pointers to research papers if there are any.

thanks.

Re: Musings on the fundamental nature of data

Kurt Cagle — 2013-05-05T18:49:40

Tim,

Man-made domains have the benefit that the variables that affect these
domains are usually reasonable transparent and discrete, whereas with
evolutionary systems, there are typically variables that can be maddeningly
difficult to qualify, let alone quantify, in part because phase transitions
in such systems are seldom discrete. Health classification systems provide
a good case in point - cancer is a systemic condition, there are many forms
of cancer that present in different ways, and cancers of one type may
induce cancers of another type, while there may be some cancers that would
never occur if other types of cancer are present. Modeling this requires a
significant number of time dependent variables, and the solutions are
almost always non-linear as well.

Building an ontology then requires effectively identifying areas of
consistent behavior within what is ultimately a piecewise discontinuous
membrane. This is true for any system which incorporates non-linear phase
transitions. The various phases of

Re: Musings on the fundamental nature of data

Timothy W. Cook — 2013-05-04T20:41:23


I fully support this assertion.

In some (most?) domains though these are not static views.

Specifically in the domain of healthcare (ignoring the fact that
domain experts prefer you to just suck the knowledge from their
brain).  When dealing with the healthcare record of a single person
over their lifetime, it is vitally important to capture 'data' in the
context that it was created combining the ontological, temporal and
spatial contexts along with the data into an artifact that can be
called information. Static data models do not work in this environment
because not only does time pass, the patient changes and is in various
geographical contexts. The science changes as well.  You cannot
migrate the data into new ontological contexts and still have it be
valid as it was captured.
This has led to the multi-level modelling approach using a generic
reference model and domain models that can vary over time.

I'm sure this can be helpful to other domains but man made domains do
not seem to be as complex as e

XSLT 3.0 Relax NG Schema

mozer — 2013-05-04T20:23:49

Dear XSLT Fans,

For people eager to start playing with bleeding edge XSLT 3.0

Relax NG
http://www.sharexml.com/x/get?k=NDGu7yBYGAUC

Relax NG Compact
http://www.sharexml.com/x/get?k=gfC5oPhTcGjx

Best regards,

Xmlizer

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe< at >lists.xml.org
subscribe: xml-dev-subscribe< at >lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[ann] A series of 3 webinars: "XSLT development with oXygen XML Editor"

George Cristian Bina — 2013-05-03T16:57:51

Hi all,

I am happy to invite you to attend our XSLT development webinars where 
we will show our 12 years of work (since 2001) to provide an IDE for 
developing XSLT stylesheets. XSLT is in fact the best supported 
XML-related technology in oXygen and we cover almost any aspect of XSLT 
development, bringing that to a level similar to what Java IDEs provide 
for Java.

The first webinar is scheduled for next Wednesday, May 8th, between 11 
AM and 12 PM EDT. In this first part we will cover the XSLT editing, 
XSLT validation, applying XSLT transformations and generating XSLT 
documentation for your stylesheets. See more details and register at
http://www.oxygenxml.com/events/2013/webinar_xslt_development_with_oXygen_Part1.html

The second webinar will be on June 5th, at the same time (11 AM to 12 PM 
EDT) and it will explore what it means to work with more complex 
stylesheets, where the logic is split across multiple modules. You will 
see the "master files" concept introduced by oXygen to facilitate the 
d

CSS selectors as superpowers

Simon St.Laurent — 2013-05-02T19:33:27

Continuing some of the discussion on flexible processing of markup, 
here's a piece I think is a key part of the stack.  Pattern matching, 
which can link presentation, behavior, and other information to documents.

<http://programming.oreilly.com/2013/05/css-selectors-as-superpowers.html>

If you hate CSS, you can read "a streamable subset of XPath" for it if 
you prefer - at least in the abstract. You can similarly read 
"markup-processing application" if the browser ain't your thing.

Markup is beautifully optimized for pattern matching approaches.

Thanks,

Re: XML's greatest cultural advantage over JSON

2013-05-02T14:43:30

PHP and Javascript  can transfer simple data in a very simple and
straightforward way with JSON.

<?php

$mydata = array("ok"=>true, "points"=>array( 0=>455.11,1=>552.4,2=>552.9));
echo json_encode($mydata);

?>

<script type="javascript">

...
.../* jquery ajax object call */...
success: function(data){

   if( data["ok"]){
         process( data["points"] );
  }
}

Its hard to beat this simplicity, and probably not even worth it.
Something even more simple than this is probably too simple.

JSON is the best tool in this domain,  simple data passing between a
server and a webbrownser.



--
--
ℱin del ℳensaje.

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe< at >lists.xml.org
subscribe: xml-dev-subscribe